O WordPress corrigiu uma falha de XSS (cross-site scripting, ou scripting entre sites) refletido pré-autenticação em sua tela de login que afeta todas as versões do sistema de gerenciamento de conteúdo (CMS, na sigla em inglês). A pwn.ai demonstrou como a falha pode ser encadeada em execução de código PHP no servidor quando um administrador autenticado interage com uma página controlada pelo atacante.
Catalogada como CVE-2026-64638 (Vulnerabilidades e Exposições Comuns, com pontuação CVSS - Sistema Comum de Pontuação de Vulnerabilidades - de 8,9), a vulnerabilidade de alta gravidade não exige privilégios do atacante. Segundo a pwn.ai, que descobriu a falha e compartilhou detalhes técnicos com o The Hacker News, o XSS na página de login não requer autenticação. Assim que um nome de usuário craftado chega à página de erro de login, o JavaScript resultante é executado no navegador do visitante sem qualquer interação adicional naquela página.
O caminho até a execução de código exige uma vítima já autenticada como administradora e interação explícita com uma página controlada pelo atacante. Na demonstração da pwn.ai, essa interação é um clique comum.
Os pesquisadores disseram ao The Hacker News que o ataque funciona contra instalações padrão do WordPress e não exige configurações incomuns de hospedagem ou implantação. Os pesquisadores afirmaram que possuem múltiplos caminhos do XSS até a execução de código, incluindo variantes que instalam um plugin ou enviam um arquivo ZIP arbitrário.
O próprio aviso do WordPress adota uma visão mais cautelosa sobre a explotabilidade, observando que a escalada para RCE (execução remota de código) envolve condições fora do controle do atacante e exige engenharia social bem-sucedida, além de interação explícita da vítima.
O problema foi corrigido em 6 de agosto no WordPress 7.0.3, com correções retroportadas até a branch 4.7. O WordPress recomenda atualizar imediatamente, e sites que suportam atualizações automáticas em segundo plano devem receber a versão de segurança automaticamente. Versões anteriores à 4.7 permanecem afetadas, mas ficam fora do alcance atual de retroportação do projeto.
Os pesquisadores, que batizaram a cadeia de ataque de XSS2Shell, afirmaram que seu sistema autônomo descobriu e reproduziu a cadeia de vulnerabilidades após receber como ponto de partida a pesquisa de 2022 de Paulos Yibelo sobre SOME (Execução de Método de Mesma Origem, na sigla em inglês).
A empresa disse que o trabalho levou cerca de quatro dias usando modelos de código aberto e um fluxo multiagente. Segundo ela, a cadeia foi reproduzida em 26 de julho e reportada ao WordPress no dia seguinte.
A falha começa na forma como o WordPress trata o nome de usuário em um login mal-sucedido. Segundo os pesquisadores, o valor passa por sanitize_user() e wp_strip_all_tags(), que depende da função strip_tags() do PHP. Uma string semelhante a uma tag, contendo espaço em branco após o < de abertura, pode sobreviver a esse parser como texto. Mais adiante, o WordPress passa o valor por wp_kses_post(), cujo parser separado interpreta a mesma entrada como HTML permitido. O resultado são elementos DOM (Modelo de Objeto de Documento) vivos, controlados pelo atacante, na página de login mal-sucedido.
Esses elementos então interagem com o user-profile.js do próprio WordPress, um script de gerenciamento de perfil que também é carregado na página de login porque a página lida com redefinições de senha.
Alguns elementos de perfil que o script espera estão ausentes ali: dois campos de input que faltam são resolvidos como undefined, permitindo que uma verificação de igualdade seja aprovada, enquanto a variável ajaxurl, caso contrário indefinida, pode ser sobrescrita com um elemento DOM injetado. Isso direciona o próprio JavaScript do WordPress para uma requisição REST de mesma origem escolhida pelo atacante.
Os pesquisadores usam o suporte a JSONP (JSON com Padding) do REST do WordPress para transformar essa requisição em JavaScript executando na origem do site. Para implantações em que requisições REST anônimas retornam HTTP 401, o parâmetro _envelope=1 pode encapsular a recusa em uma resposta HTTP 200 externa, permitindo que o jQuery continue processando a resposta como script.
Os pesquisadores também descobriram em seus testes que uma CSP (Política de Segurança de Conteúdo) baseada em nonce com strict-dynamic não bloqueou o caminho demonstrado.
O caminho do XSS até a execução de PHP se baseia na técnica SOME anterior de Yibelo, que utiliza uma cadeia de propriedades JSONP permitidas para invocar um método em outra janela do navegador.
Um dos caminhos demonstrados pela pwn.ai usa o XSS na origem do WordPress para invocar o controle nativo de aprovação de Senhas de Aplicativo dentro da sessão de uma administradora autenticada. O WordPress então cria uma credencial de API e a redireciona para uma success_url em HTTPS escolhida pelo atacante.
As Senhas de Aplicativo são credenciais revogáveis destinadas ao acesso por API, de modo que esse caminho não precisa roubar a senha principal da administradora. Os pesquisadores usaram a credencial para acesso REST autenticado a fim de publicar uma página do WordPress contendo JavaScript de mesma origem. Quando a sessão da administradora retida abria essa página, seu script obtinha o nonce de upload de plugin do WordPress e enviava um arquivo ZIP fornecido pelo atacante. O PHP podia então ser solicitado diretamente a partir do plugin extraído. O plugin não precisou ser ativado.
As evidências de produção fornecidas ao The Hacker News param no XSS. Os pesquisadores reproduziram separadamente o XSS na página de login sem cookies em duas implantações do WordPress 7.0.2, em perfis novos do Chrome, sem cookies ou credenciais do WordPress.
Eles não tentaram a criação de Senha de Aplicativo, upload de arquivos, persistência ou execução de PHP nesses sistemas. A cadeia completa de execução de PHP foi demonstrada separadamente em uma instalação local limpa do WordPress 7.0.2.
Os pesquisadores afirmaram que medidas conhecidas de endurecimento do WordPress não devem ser tratadas como mitigação completa para o XSS subjacente, e que a aplicação da atualização de segurança é obrigatória.
Uma execução de PHP bem-sucedida exporia as credenciais do banco de dados do WordPress no wp-config.php, permitiria a criação persistente de administradores e alterações de conteúdo, exporia arquivos e segredos legíveis pelo worker do PHP, e possibilitaria a execução de comandos do sistema operacional com os privilégios desse worker.
O WordPress creditou a equipe da pwn.ai pela descoberta e divulgação responsável da vulnerabilidade. Em 7 de agosto, o aviso do projeto não relatava exploração em ambiente real.
