Uma cadeia de duas vulnerabilidades críticas no núcleo do WordPress, batizada wp2shell, está a ser explorada em massa desde o fim de semana de 18-19 de julho de 2026. O WordPress já corrigiu as falhas e ativou atualizações automáticas forçadas — mas, para além de atualizar, há uma pergunta que muitos administradores esquecem: o que acontece aos visitantes de um site já comprometido? A resposta é que um site atacado se transforma num veículo de distribuição de burlas, roubo de credenciais, malware e redirecionamentos maliciosos.
Resposta rápida: wp2shell (CVE-2026-63030 + CVE-2026-60137) é uma cadeia de execução remota de código (RCE) sem autenticação no núcleo do WordPress, divulgada a 17 de julho de 2026 pela Searchlight Cyber. Afeta as versões 6.9.0 a 6.9.4 e 7.0.0 a 7.0.1; a série 6.8 é afetada apenas pela componente de injeção de SQL. As correções estão nas versões 7.0.2 e 6.9.5 (e 6.8.6 para a parte SQL). A prioridade é atualizar imediatamente — mas quem já foi comprometido tem de assumir que o site pode estar a atacar os próprios visitantes.
O que é o wp2shell e porque é tão grave
O wp2shell combina duas falhas distintas. A primeira, CVE-2026-63030, é uma confusão de rotas no endpoint de processamento em lote da REST API (batch-route confusion), introduzida no WordPress 6.9. A segunda, CVE-2026-60137, é uma injeção de SQL no parâmetro author__not_in do WP_Query. Encadeadas, permitem que um atacante anónimo, sem qualquer credencial, execute código no servidor.
O que torna esta falha excecional é residir no próprio núcleo do WordPress — não num plugin de terceiros. Como sublinhou a Searchlight Cyber, o ataque “não tem pré-condições e pode ser explorado por um utilizador anónimo numa instalação normal do WordPress, sem plugins”. A Wordfence descreveu-a como a primeira RCE crítica não autenticada no núcleo do WordPress em quase uma década. Com uma base instalada estimada em mais de 500 milhões de sites, o alcance potencial é enorme.
O advisory do GitHub classifica a cadeia como crítica, embora o CVSS atribuído à componente de confusão de rotas seja de 7,5. A falha foi descoberta pelo investigador Adam Kues, da equipa Assetnote da Searchlight Cyber, com recurso a um modelo de linguagem (LLM) durante a investigação — um detalhe que se tornou tema paralelo neste episódio.
Que versões estão afetadas
É essencial perceber o alcance exato, porque há confusão a circular:
- Cadeia RCE completa: WordPress 6.9.0 a 6.9.4 e 7.0.0 a 7.0.1.
- Apenas a injeção de SQL (CVE-2026-60137): ramo 6.8 (6.8.0 a 6.8.5), corrigido na 6.8.6.
- Correções da cadeia completa: versões 7.0.2 e 6.9.5, lançadas a 17 de julho.
- Instalações anteriores à 6.8: não afetadas por esta cadeia (podem ter outros problemas não relacionados).
O WordPress ativou atualizações automáticas forçadas para as versões suportadas — uma medida rara, que a própria organização raramente toma. Ainda assim, os administradores não devem presumir que a correção foi aplicada: as atualizações forçadas podem falhar em sites com as atualizações automáticas desativadas. É indispensável confirmar a versão em wp-admin, no painel “Numa vista de olhos”, ou no ficheiro readme.html.
A exploração massiva já começou
Ao contrário de outras divulgações em que há uma janela de calma, aqui a exploração foi quase imediata. Jake Knott, investigador principal da watchTowr, descreveu que, já nas primeiras horas de sábado (UTC), a exploração bem-sucedida estava em curso — inicialmente com código público para exfiltrar credenciais em hash, e depois com execução de código à medida que mais detalhes se tornaram públicos.
Dados da Wiz Research indicam que 60% das organizações que usam WordPress tinham pelo menos uma instância vulnerável no momento da publicação dos CVE, e 25% expunham um servidor vulnerável à Internet. Esses valores caíram para cerca de 50% e 10% nas 24 horas seguintes, à medida que as equipas aplicaram as correções. A Wiz observou atacantes a realizar inclusão de ficheiros locais para exfiltrar credenciais de base de dados, a autenticar-se no painel de administração e a carregar webshells em PHP para garantir acesso persistente.
O que acontece aos visitantes de um site comprometido
Aqui está o ponto que muitos administradores esquecem. Uma vez comprometido, o site deixa de ser apenas um problema do proprietário e passa a ser uma ameaça para quem o visita. Os cenários mais comuns após um ataque deste tipo incluem:
- Redirecionamentos maliciosos: o visitante é enviado, sem perceber, para páginas de burla, lojas falsas ou sites de phishing.
- Roubo de credenciais: formulários de login legítimos são adulterados para capturar utilizadores e palavras-passe, ou são injetadas páginas falsas.
- Distribuição de malware: descarregamentos automáticos (“drive-by downloads”) ou pedidos para instalar falsas atualizações.
- Skimming de dados de pagamento: em sites de comércio eletrónico, scripts injetados capturam os dados do cartão introduzidos no checkout.
- Publicidade e SEO maliciosos: injeção de conteúdo e ligações que prejudicam a reputação e o posicionamento do site.
Para o visitante, o mais insidioso é que tudo isto acontece a partir de um endereço em que confia. O cadeado HTTPS continua presente, o domínio é o correto — e, ainda assim, a página está a servir conteúdo controlado por terceiros.
Como saber se o seu site foi comprometido
Atualizar corrige a falha, mas não remove um atacante que já lá esteja. Quem esteve exposto deve procurar sinais de comprometimento: novas contas de administrador não reconhecidas, plugins ou ficheiros estranhos, e palavras-passe de aplicação criadas sem autorização. Do lado do tráfego, os indicadores de compromisso identificados pela Wiz incluem pedidos ao endpoint /wp-json/batch/v1 (ou ?rest_route=/batch/v1), respostas HTTP 207/200 (Multi-Status) a esses pedidos, e user-agents que contenham as cadeias “wp2shell” ou “rezwp2shell”.
Para quem não pode atualizar de imediato, a mitigação temporária recomendada é bloquear o acesso anónimo ao endpoint /wp-json/batch/v1 num firewall de aplicação web (WAF). A Cloudflare, por exemplo, já implementou regras de proteção — mas convém não converter mitigações parciais em falsa sensação de segurança: a única resolução definitiva é atualizar o núcleo.
Porque é que isto importa em Portugal
O WordPress domina o alojamento de sites em Portugal — de pequenos negócios e autarquias a media e comércio eletrónico. Uma falha no núcleo, explorável sem plugins e sem autenticação, coloca em risco um universo vastíssimo de sites nacionais, muitos deles geridos por organizações sem equipa de segurança dedicada. Para as entidades abrangidas pelo Regime Jurídico da Cibersegurança (Decreto-Lei n.º 125/2025, que transpõe a NIS2), um site comprometido que distribua malware aos visitantes pode configurar um incidente com obrigações de notificação ao CNCS.
As prioridades práticas são três: confirmar (não presumir) que o WordPress está na versão 7.0.2, 6.9.5 ou 6.8.6; inventariar todas as instalações, incluindo sites de teste, campanhas e subdomínios esquecidos, que são os que mais frequentemente ficam por atualizar; e, em caso de exposição, procurar sinais de comprometimento e vigiar os registos nas 48 a 72 horas seguintes. Um site que serve os seus visitantes é também responsável por não os transformar em vítimas.
Esta informação tem caráter noticioso e baseia-se em dados divulgados publicamente pela Searchlight Cyber, Wiz Research, watchTowr, Rapid7 e Tenable, bem como nos avisos de segurança do próprio WordPress.