Vulnerabilidade XSS no WordPress que pode escalar o PHP e a urgência do adesivo já

O WordPress publicou em 6 de agosto um adesivo que corrige uma vulnerabilidade cross-site scripting (XSS) refletido no ecrã de acesso que, segundo a descoberta pública, pode chegar a acadear-se até execução de código PHP em determinadas condições. A falha foi relatada pela empresa pwn.ai e registrada como CVE-2026-64638 (pontuação CVSS 8.9). O WordPress incluiu a correção na versão 7.0.3 e a aplicou retroactivamente até o ramo 4.7; as instalações com atualizações automáticas habilitadas devem receber o adesivo sem intervenção do administrador. A referência do CVE na base de dados NVD pode ser consultada: https://nvd.nist.gov/vuln/detail/CVE-2026-64638, e o anúncio oficial de segurança do WordPress em sua categoria de notícias: https://wordpress.org/news/category/security/.

O confirmado por pwn.ai é que o XSS é do tipo reflectido e acessível da página de login sem autenticação: um nome de usuário especialmente formado enviado em uma tentativa de acesso falhada pode chegar ao usuário final dentro da página de erro e executar JavaScript no navegador. Esse JavaScript, de acordo com a empresa, pode se encadear com outros comportamentos do WordPress para provocar pedidos same-origin que permitam controle adicional dentro da sessão do site. WordPress, em sua assessoria pública, descreve uma avaliação mais cautelosa: a escalada desde esse XSS até executar código no servidor (RCE) exige condições externas ao controle do atacante, em particular, interação e aprovação explícita de um administrador, e portanto requer sucesso em engenharia social além da vulnerabilidade inicial.

Tecnicamente, a falha surge por um conflito entre diferentes filtros que o WordPress aplica ao valor do nome de usuário após uma tentativa fracassada de acesso. De forma simplificada e comprovada pelos pesquisadores, o dado passa por sanitize_user() e por wp_strip_all_tags() (que usa a função PHP strip_tags()). Textos que parecem marcas HTML mas contêm espaços imediatamente após o sinal "<" podem sobreviver a esse primeiro processado como texto. Mais abaixo, o WordPress aplica wp_kses_post (), cujo parser interpreta essa mesma entrada como HTML permitido, o que resulta na inserção de elementos DOM controlados pelo atacante na página de erro de login. Esses itens acabam interagindo com o user- profile.js, um programa de gestão de perfil carregado na página de login pelo manejo de restauração de senhas; a ausência de certos campos esperados nesse contexto deixa variáveis em estado undefined e permite que um elemento injetado sobrecreva, por exemplo, ajaxurl, redigindo a lógica JavaScript para uma petição REST selecionada pelo atacante. pwn.ai também demonstrou como aproveitar a compatibilidade com o JSONP na API REST do WordPress para converter a resposta em código JavaScript executado com a origem do site. Em ambientes onde a API responde 401 para pedidos anônimas, o parâmetro _envelope=1 pode envolver essa negação com 200 externo e fazer com que jQuery processe a resposta como script.

Os pesquisadores denominaram seu texto XSS2Shell e descrevem múltiplas rotas para execução em PHP. Uma das demonstrações reproduzidas por pwn.ai usa o XSS para invocar a interface nativa de aprovação do Application Passwords dentro de uma sessão já autenticada com papel Administrador. Essa interface cria uma credencial API e redeirige a um URL de sucesso controlado pelo atacante; com a credencial criada, o atacante pode publicar uma página que contém JavaScript same-origin e, quando um administrador autenticado a abrir, esse programa obtém o nonce para subir plugins e realiza a subida de um arquivo ZIP que contém código PHP. No teste de conceito de pwn.ai o código PHP pôde ser solicitado diretamente do plugin extraído sem necessidade de ativar o plugin. Importante: pwn.ai separou os passos em testes distintos: a reprodução do XSS em servidores remotos foi realizada em instalações WordPress 7.0.2 sem cookies de sessão, enquanto a demonstração completa que chega a execução do PHP foi feita em um ambiente local limpo.

O que está confirmado: Existe um XSS refletido na página de login sem necessidade de autenticação e o WordPress publicou um adesivo em 6 de agosto. pwn.ai reproduziu localmente a cadeia completa até PHP execution e demonstrou a exploração do caminho de Application Passwords em laboratório. O WordPress reconheceu o achado, acreditou a equipe e emitiu a atualização de segurança; ao fechar a evidência pública (7 de agosto) não havia relatos verificados de exploração na natureza.

O que é estimativa ou ainda incerto: O grau em que esta cadeia está sendo explorada ativamente contra sites em produção não está confirmado; a escalada para RCE requer a interação de um administrador autenticado e, segundo o WordPress, elementos de engenharia social que estão fora do controle técnico do atacante. A eficácia de mitigações parciais (por exemplo, políticas CSP complexas ou certos hardenings) foi testada pelos pesquisadores em alguns cenários e descobriram que uma política CSP baseada em nonce com strict-dynamic não impediu a demonstração, mas o comportamento pode variar segundo plugins, configurações e versões do servidor.

Quem afeta? Praticamente qualquer instalação do WordPress que não tenha aplicado a atualização: os pesquisadores asseguram que a cadeia funciona contra instalações por defeito e não requer configurações de hospedagem incomuns. As instalações anteriores ao ramo 4.7 ficam fora do suporte de backports e, portanto, continuam expostas se não forem atualizadas ou adesivos manualmente.

Consequências concretas de uma exploração completa seriam graves: obtenção de credenciais armazenadas em wp-config.php, criação persistente de contas administrativas, subida e execução de código PHP, modificação ou remoção de conteúdo e exposição de arquivos ou segredos acessíveis pelo processo PHP. O alcance real de danos depende do contexto do servidor (privilegios do worker PHP, medidas de filesystem, disponibilidade de backups e controles de integridade).

Medidas práticas e específicas a aplicar pelos gestores actuais: atualizar para WordPress 7.0.3 ou outra versão que inclua a correção; se a actualização não for possível imediatamente, minimizar a exposição do ficheiro de acesso: proteger o wp- login.php com autenticação de HTTP adicional ou restringir o seu acesso por IP, activar um WAF com regras que bloqueiem injeções em parâmetros de login, desactivar a edição de plugins/temas do dashboard, revogar a Application Passwords recentemente criadas e auditar a lista de credenciais. Após a atualização, revisar o site procurando novas contas administrativas ou modificações de plugins/themes e verificar integridade de arquivos e presença de arquivos ZIP ou plugins não legítimos. Se suspeitar de compromisso, mude as chaves de salts em wp- config.php, restaure desde backups limpos e considere uma auditoria forense. Activar 2FA e limitar o uso de contas com privilégios elevados reduz a janela de exploração por engenharia social.

Finalmente, mantenha cópias de segurança fora do servidor production e active atualizações automáticas quando possível; o WordPress indica que sites com atualizações em segundo plano devem receber automaticamente o release. Dado que a exploração completa descrita por pwn.ai requer interação adicional com um administrador, a combinação de adesivos imediatos, controles de acesso ao login e práticas fortes de segurança operacional é a defesa mais eficaz.

O achado ilustra como vulnerabilidades aparentemente de apresentação (XSS em uma página de erro) podem se tornar vetores críticos quando interagem com lógica existente e APIs do mesmo site. A recomendação técnica e prática é inequívoca: aplicar a atualização oficial sem demora e rever administradores e credenciais expostos.