O que o wp2shell realmente faz

Quando Adam Kues, da Assetnote, enviou um pedido forjado a uma instalação normal do WordPress, o servidor executou o código dele. Sem conta, sem palavra-passe, sem plugin, sem qualquer definição invulgar. Os investigadores chamaram à cadeia wp2shell, o WordPress atribuiu-lhe CVE-2026-63030 e ambas as partes a classificaram como crítica.

O exploit encadeia duas fraquezas na rota em lote da REST API: uma confusão de encaminhamento que permite a um chamador não autenticado alcançar caminhos de código que deviam estar protegidos, e uma injeção de SQL acessível através dela. Encadeadas, transformam um pedido HTTP anónimo em execução de código, o pior desfecho que uma falha web pode ter.

Porque a correção automática não é a meta

O WordPress lançou 6.9.5 e 7.0.2 a 17 de julho de 2026 e, dada a gravidade, forçou as atualizações nos sites afetados em vez de esperar por um clique do proprietário. É a decisão certa e a maioria dos sites está agora fechada. Também esconde a pergunta mais difícil.

Uma falha sem autenticação significa que qualquer pessoa na internet a podia usar antes de si corrigir, e instalar a correção não reverte isso. Se o seu site estava acessível e por corrigir durante a janela de exposição, a atualização retirou a porta mas não o que já tinha entrado: um utilizador administrador infiltrado, uma tarefa agendada, uma webshell na pasta de carregamentos.

Porque quase todos os proprietários estão abrangidos

Isto vivia no núcleo, o software que cada site WordPress executa, por isso a exposição não dependia de um plugin ou tema de nicho. O WordPress move perto de 40 por cento da web, e por isso uma única falha do núcleo desta classe é um evento em massa e não um caso isolado.

As versões 6.9.0 a 6.9.4 e 7.0.0 a 7.0.1 eram vulneráveis ao wp2shell. A segunda falha, uma injeção de SQL no parâmetro author__not_in do WP_Query com CVSS 9.1, recua até à 6.8, por isso um site que saltou atualizações durante alguns meses carregava a maior das duas janelas de exposição.

No que as regras da UE o transformam

Para uma empresa europeia a falha não é apenas técnica. Se houver dados pessoais por trás desse site, o RGPD dá-lhe 72 horas para notificar a sua autoridade de controlo assim que tomar conhecimento de uma violação, e 'não podemos descartar' está mais perto desse conhecimento do que do sossego.

Para entidades essenciais e importantes ao abrigo da NIS2, um incidente desta gravidade aciona o seu próprio relógio de alerta precoce e notificação, e os reguladores esperam cada vez mais provas de deteção, não apenas um registo da correção. Uma atualização automática forçada é uma defesa que não escolheu; se depois verificou a existência de comprometimento é o que fica no seu registo.

A verificação que tem de acontecer agora

Confirme que o site está em 6.9.5 ou 7.0.2 e depois trate a janela de exposição como o verdadeiro trabalho. Reveja contas de administrador e palavras-passe de aplicação criadas em julho, inspecione tarefas agendadas e ficheiros PHP alterados há pouco, e retire os registos do servidor web em busca de pedidos POST invulgares à REST API em torno da data de divulgação.

Se usa WordPress gerido, peça ao seu alojamento por escrito quando chegou a correção e se viu tentativas de exploração contra o seu site. A resposta honesta a 'fomos atingidos' raramente é imediata, mas os proprietários que perguntam esta semana são os que não estarão a explicar uma violação silenciosa no próximo trimestre.

Leia a seguir: Um edifício inutilizado custa mais do que um resgate  |  A sua sandbox foi atacada um mês antes do aviso