Uma falha no WordPress: o formulário de login entrega o servidor
Uma falha do WordPress apelidada de XSS2Shell transforma uma tentativa de login malsucedida em código PHP rodando no servidor. Registrada como CVE-2026-64638, ela marca 8,9 na escala CVSS. Começa com um nome de usuário digitado no formulário público de acesso e termina, nas condições certas, com um plugin do atacante descompactado dentro da sua instalação. O WordPress lançou a correção na versão 7.0.3 em 6 de agosto de 2026 e a retroportou até o ramo 4.7. O código de exploração público apareceu em poucos dias.
Como funciona a cadeia XSS2Shell
O ponto de entrada é a mensagem de erro do login. Envie um nome de usuário que não existe e o WordPress devolve o texto impresso na página. Esse reflexo deveria ser inofensivo, e no caminho há dois sanitizadores distintos. O bypass encontrado pela equipe da pwn.ai explora uma divergência entre eles: strip_tags() não trata como tag uma construção precedida por espaço, então uma carga no formato < area id=ajaxurl> passa intacta, enquanto wp_kses_post() depois lê a mesma cadeia como HTML válido e a renderiza como elemento real na página.
A parte engenhosa é o que esse elemento faz. Não é um script. É um nó do DOM com nome que colide com uma variável JavaScript que o WordPress deixa indefinida naquela tela, uma técnica chamada DOM clobbering. Um script administrativo do núcleo procura ajaxurl, encontra o elemento do atacante em vez de nada e aponta uma requisição para onde o atacante quis. Dali a cadeia percorre o próprio código confiável do site: um endpoint REST com suporte a JSONP executa o JavaScript do atacante na origem do próprio site, um truque de execução de método entre janelas alcança a sessão de um administrador logado e aprova ali um Application Password, e essa credencial dá acesso REST autenticado.
O último passo não precisa de nenhum bug exótico. O Application Password roubado carrega privilégios de administrador, então o atacante simplesmente usa a API para enviar um plugin: um arquivo ZIP com PHP dentro. Numa instalação de site único o administrador ainda tem por padrão o direito a HTML sem filtro, e é isso que torna possível o passo intermediário de publicar uma página cheia de JavaScript. A partir daí o código não está mais no navegador. Ele roda com os privilégios do worker PHP, ao lado das credenciais do banco de dados.
Do que o atacante realmente precisa
É aqui que a manchete e a realidade se separam. A metade de cross-site scripting realmente não exige conta nem senha, e é isso que torna a falha pré-autenticação. Já a metade de execução remota de código não dispara sozinha. Um administrador precisa estar logado no site alvo e precisa abrir um link controlado pelo atacante. Nenhum aviso aparece, nenhuma confirmação é pedida e a vítima não vê nada estranho, mas a visita tem de acontecer.
Na prática a barreira é baixa. Administradores de sites clicam o dia inteiro em links de chamados de suporte, formulários de contato, avisos de comentários e e-mails de fornecedores, muitas vezes na mesma sessão de navegador em que o painel está aberto. Ler "exige interação do usuário" como conforto é exatamente o caminho pelo qual uma cadeia dessas fica um mês sem correção.
Quais versões são afetadas
Todas as versões do WordPress da 4.7 até a 7.0.2 inclusive são vulneráveis. Esse ramo saiu em dezembro de 2016, e por isso a faixa afetada cobre praticamente qualquer instalação que ainda receba atualizações. O WordPress publicou no mesmo dia correções em toda a árvore suportada, da 7.0.3 passando por 6.9.6 e 6.8.7 e chegando até a 4.7.34. Tudo que roda em 4.6 ou anterior não recebe nenhuma atualização de segurança e deve ser tratado como permanentemente exposto.
A XSS2Shell foi um dos doze problemas fechados nessa versão. Entre os demais estão cross-site scripting armazenado nos blocos Post Date e Post Content, nas configurações de emoji e na edição rápida, uma exposição de informação que revelava comentários de posts protegidos por senha, um contorno do fluxo de confirmação de e-mail, uma injeção de CSS pelo filtro de atributos seguros, uma elevação de privilégio em redes multisite com registro aberto, uma server-side request forgery na validação de URL que alcançava faixas link-local, e uma enumeração de slugs de posts. Mesmo sem a cadeia principal, essa lista já é motivo para atualizar hoje.
O que fazer agora
- Atualizar imediatamente: ir para a 7.0.3 ou para a versão corrigida do seu ramo. As atualizações automáticas em segundo plano instalam por padrão as versões menores de segurança, mas confirme o número em vez de presumir.
- Auditar os Application Passwords: abrir o perfil de cada administrador e revogar qualquer credencial que você não reconheça. É o rastro que a cadeia deixa, e ele sobrevive a uma troca de senha.
- Revisar usuários, plugins e arquivos: procurar contas de administrador que você não criou e plugins que apareceram sem entrada correspondente no seu próprio histórico de mudanças.
- Não abrir o painel de qualquer lugar: manter a sessão de administração num perfil de navegador separado do usado para e-mail e chamados remove exatamente a condição de que este ataque depende.
- Restringir a tela de login: o reflexo mora no wp-login.php. Limitar quem chega até ela, por lista de IPs, autenticação HTTP ou regra de firewall, encolhe a superfície para o próximo bug no mesmo arquivo.
Por que isso importa além dos donos de sites
Uma instalação WordPress comprometida raramente é o objetivo do atacante. Ela é um veículo de entrega, e o tráfego que serve é confiável justamente porque o domínio é legítimo. Vimos o mesmo padrão quando um script de publicidade passou a reescrever endereços de carteiras cripto em milhares de sites comuns, e a mesma ideia está por trás dos ataques em nível de navegador que pegam carona numa sessão autenticada que a vítima já tem aberta. Para um leitor, e não um administrador, a defesa prática está na camada de rede: filtragem de DNS e listas de bloqueio impedem que a carga de segundo estágio carregue mesmo quando o site que a entrega é um que você visita há anos. É um argumento direto a favor de ferramentas de privacidade que bloqueiam já na resolução, e vale dizer com franqueza que nenhuma delas corrige o seu próprio servidor. Isso só a atualização faz.
