O WordPress corrigiu uma falha de cross-site scripting refletido em pré-autenticação, no formulário de login, que afeta todas as versões do sistema de gerenciamento de conteúdo. Sob condições adicionais, o bug pode ser encadeado até execução de código em PHP no servidor.
Identificada como CVE-2026-64638, com pontuação CVSS 8,9, a vulnerabilidade é classificada como de alta severidade e não exige privilégios do invasor. Segundo a pwn.ai, responsável por descobrir a falha e compartilhar os detalhes técnicos, o XSS na página de login pode ser executado sem conta e sem interação adicional da vítima, desde que a requisição maliciosa seja enviada.
O caminho até a execução de código é mais difícil. A cadeia demonstrada exige que a vítima já esteja logada como Administrador de site único, que faça um clique comum em uma página controlada pelo invasor e que várias funcionalidades e condições de implantação do WordPress estejam alinhadas.
O problema foi corrigido em 6 de agosto, no WordPress 7.0.3, com ajustes retroportados até a linha 4.7. O WordPress recomenda a atualização imediata, e os sites com atualizações automáticas em segundo plano devem receber a versão de segurança automaticamente. Versões anteriores à 4.7 continuam afetadas, mas ficaram fora do escopo atual de retroportação do projeto. Segundo a W3Techs, o WordPress responde por 41,2% de todos os sites da internet.
A pwn.ai, que chama a cadeia de ataque de XSS2Shell, disse que seu sistema autônomo descobriu e reproduziu a sequência de vulnerabilidades depois de usar como ponto de partida a pesquisa de 2022 de Paulos Yibelo sobre Same Origin Method Execution, ou SOME.
A empresa afirmou que o trabalho levou quase quatro dias, usando modelos de código aberto e um fluxo de trabalho com múltiplos agentes. Segundo a pwn.ai, a cadeia foi reproduzida em 26 de julho e comunicada ao WordPress no dia seguinte.
A falha começa na forma como o WordPress trata o nome de usuário após uma tentativa de login malsucedida. De acordo com os pesquisadores, o valor passa por sanitize_user() e wp_strip_all_tags(), que depende da função strip_tags() do PHP. Uma sequência parecida com uma tag, com espaço em branco logo após o símbolo < de abertura, pode sobreviver a esse analisador como texto. Depois, o WordPress passa o valor por wp_kses_post(), cujo analisador separado interpreta a mesma entrada como HTML permitido. O resultado são elementos DOM ativos controlados pelo invasor na página de login com falha.
Esses elementos interagem então com o próprio user-profile.js do WordPress, um script de gerenciamento de perfil que também é carregado na página de login porque ela lida com redefinições de senha.
Alguns elementos de perfil esperados pelo script não existem nessa página. Dois campos ausentes passam a ser undefined, o que permite que uma comparação de igualdade seja satisfeita, enquanto a variável ajaxurl, que também seria undefined, pode ser sobrescrita com um elemento DOM injetado. Isso conduz o JavaScript do próprio WordPress a uma requisição REST de mesma origem escolhida pelo invasor.
Os pesquisadores usam o suporte JSONP do REST do WordPress para transformar essa requisição em JavaScript executado na origem do site. Em implantações nas quais requisições REST anônimas retornam HTTP 401, o parâmetro _envelope=1 pode embrulhar a negativa em uma resposta externa HTTP 200, permitindo que o jQuery continue processando o retorno como script.
Os pesquisadores também constataram nos testes que uma política de segurança de conteúdo baseada em nonce, com strict-dynamic, não bloqueou a cadeia demonstrada.
A passagem do XSS para a execução de código em PHP se apoia na técnica SOME apresentada anteriormente por Yibelo, que usa uma cadeia de propriedades JSONP permitida para invocar um método em outra janela do navegador.
Na demonstração da pwn.ai, o XSS com origem no WordPress aciona o controle nativo de aprovação de Senhas de Aplicação dentro da sessão de um Administrador autenticado. Em seguida, o WordPress cria uma credencial de API e a redireciona para uma success_url HTTPS escolhida pelo invasor.
As Senhas de Aplicação são credenciais revogáveis, destinadas ao acesso via API, portanto a cadeia não precisa roubar a senha principal do administrador. Os pesquisadores usaram a credencial para acesso autenticado ao REST e publicaram uma página do WordPress contendo JavaScript de mesma origem. Quando a sessão preservada do administrador abriu essa página, o script obteve o nonce de upload de plugins do WordPress e enviou um arquivo ZIP fornecido pelo invasor. A partir daí, o PHP poderia ser solicitado diretamente do plugin extraído. O plugin não precisava ser ativado.
A evidência em produção fornecida vai apenas até o XSS. Separadamente, os pesquisadores reproduziram o XSS na página de login, sem cookies, em duas implantações do WordPress 7.0.2 com perfis novos do Chrome, sem cookies ou credenciais do WordPress.
Eles não tentaram criar Senhas de Aplicação, enviar arquivos, manter persistência ou executar 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.
Assim, o alcance em todas as versões se aplica ao XSS subjacente, e não automaticamente a essa rota específica de execução em PHP. A escalada demonstrada exige Senhas de Aplicação, introduzidas no WordPress 5.6 e normalmente usadas sobre HTTPS. Ela também depende das permissões usuais de Administrator para unfiltered_html e upload_plugins, além de armazenamento de plugins gravável.
A implantação também precisa não contar com endurecimentos que bloqueiem modificações de arquivos ou a execução direta de PHP a partir de diretórios de plugins inativos. Desativar as Senhas de Aplicação quebraria essa escalada específica, mas não corrigiria o XSS subjacente.
Os pesquisadores disseram que uma execução bem-sucedida de PHP exporia as credenciais do banco de dados do WordPress em wp-config.php, permitiria a criação persistente de administradores e a alteração de conteúdo, revelaria arquivos e segredos legíveis pelo worker de PHP e possibilitaria comandos do sistema operacional com os privilégios desse worker.
O WordPress creditou a equipe da pwn.ai pela descoberta e pela divulgação responsável da vulnerabilidade. Até 7 de agosto, o comunicado do projeto não relatava exploração em ambiente real.
Publicidade
Tenha acesso aos melhores hackers éticos do mercado através de um serviço personalizado, especializado e adaptado para o seu negócio. Guardsi: qualidade, confiança e especialidade em segurança ofensiva de quem já protegeu centenas de empresas. Saiba mais...