~ O Blog de 1999 ~

O que aconteceu de facto

A 17 de julho de 2026, a equipa de segurança do WordPress lançou a 7.0.2. Corrigia duas falhas, uma classificada como crítica e outra como alta, e foi grave o suficiente para o WordPress.org ligar as atualizações automáticas forçadas em todas as versões afetadas. Trabalho com WordPress há muito tempo e nunca tinha visto o core fazer isto.

Depois chegaram os avisos. A GoDaddy publicou o seu e aplicou a correção à força em todas as linhas suportadas da hospedagem gerida. A InMotion publicou o seu. A cPanel colocou um artigo de suporte para os seus clientes. Alojamentos que nunca falam de segurança do core estavam de repente a enviar email a toda a lista de clientes sobre isto, o que diz mais sobre a gravidade do que qualquer número de CVSS.

As duas falhas, em linguagem simples

Adam Kues, da Searchlight Cyber, encontrou a cadeia e chamou-lhe wp2shell. Nenhuma das metades é um takeover sozinha. Encadeadas, são tão más quanto uma vulnerabilidade web pode ser: um atacante anónimo, um pedido HTTP, sem login, sem plugin, sem nada de invulgar na tua configuração.

CVE-2026-63030 é um bug de confusão de rotas no endpoint de batch da REST API, em /wp-json/batch/v1. O batch existe para um cliente poder juntar vários pedidos à API num só. Ele valida esses pedidos numa passagem e despacha-os noutra, mantendo rotas correspondidas e resultados de validação em duas listas paralelas. Envia um item deliberadamente malformado e as listas ficam desalinhadas. O WordPress passa então a validar um item com as regras escritas para outro e entrega-o ao handler errado. Foi classificada com 9,8 em 10.

CVE-2026-60137 é uma injeção de SQL. O core não sanitiza corretamente o parâmetro author__not_in do WP_Query quando recebe input não confiável. Sozinha, é uma injeção SELECT de leitura atrás de uma verificação de permissões que nenhum visitante anónimo passa. A confusão de rotas é o que a leva para a frente dessa verificação.

Juntas, dão injeção de SQL sem autenticação numa instalação limpa. A partir daí, o exploit público é um trabalho genuinamente elegante: forja dados que o próprio WordPress depois usa, plantando um changeset do personalizador que refere o utilizador 1, e isso termina numa conta de administrador nova. Assim que o atacante tem um admin, carregar uma webshell é rotina.

Sem plugin. Sem conta. Sem configuração especial. Um único pedido HTTP anónimo contra uma instalação padrão chegava.

Quem estava afetado

• 6.9.0 a 6.9.4 e 7.0.0 a 7.0.1: a cadeia completa de execução remota de código.
• 6.8.0 a 6.8.5: apenas a metade da injeção de SQL, que não é a cadeia completa.
• Qualquer coisa abaixo da 6.8: não afetada. O código vulnerável chegou na 6.8 e na 6.9, e a Patchstack confirmou ao ler o código fonte de várias versões que os ramos mais antigos simplesmente não o contêm. Se um site anterior à 6.8 foi comprometido nessa semana, foi por outra porta.
• 7.1 beta 1: afetada, corrigida na beta 2.

As correções saíram na 7.0.2, 6.9.5 e 6.8.6.

A que velocidade passou de correção a arma

A Patchstack viu tudo isto em direto. A correção chegou ao trunk do WordPress cerca de 90 minutos antes de a 7.0.2 ser marcada para lançamento. Esse commit é a divulgação, quer alguém lhe chame isso ou não, porque qualquer pessoa que siga o desenvolvimento do core consegue fazer o diff. As primeiras tentativas reais de exploração chegaram aos sensores da Patchstack cerca de 90 minutos depois do lançamento, três horas depois do commit.

Os números a seguir são absurdos. A Patchstack bloqueou mais de 65.000 tentativas vindas de mais de 1.500 IPs distintos, e essas regras só se ativam em sites com uma versão genuinamente vulnerável, logo todas foram contra um alvo por atualizar. A Wordfence bloqueou mais de 11 milhões só para os clientes premium. Os sistemas que seguem a campanha contaram mais de 45 milhões de tentativas na primeira semana, vindas de quase 150.000 fontes distintas, cerca de vinte vezes a escala do Drupalgeddon. A CrowdSec registou 62.802 IPs atacantes distintos numa única janela de 15 dias, o valor mais alto de qualquer CVE que segue.

A maior parte desse tráfego eram scanners a bater às portas com AND (1=1) e OR SLEEP(5). Três endereços IP foram diretos à cadeia completa e começaram a criar contas de administrador.

A CISA acrescentou os dois CVEs ao catálogo de Vulnerabilidades Exploradas Conhecidas a 21 de julho, quatro dias depois da correção, com prazo de remediação a cair no dia 24.

A parte de que quase ninguém fala

Uma firewall não era a rede de segurança que parecia, pelo menos nos primeiros dias. O WordPress lê a variável rest_route do corpo do POST antes de olhar para a query string. Ou seja, um atacante pode enviar um simples POST / com toda a carga no corpo e o caminho /batch/v1 nunca aparece no URL. A Patchstack descobriu que quase todas as regras lançadas nas primeiras horas após a divulgação, incluindo as suas próprias versões iniciais, inspecionavam apenas o URL e deixavam isso passar na perfeição. Confirmaram ataques reais com exatamente essa forma a partir das 17:00 UTC de 21 de julho.

A regra prática dessa semana: se a tua lista de bloqueio não cobria tanto /wp-json/batch/v1 como rest_route=/batch/v1, não estavas a bloquear o ataque, estavas a bloquear a versão fácil dele.

Porque é que isto ainda vale a pena ler em setembro

Porque o verão nunca acalmou. A 7.0.3, a 6 de agosto, trazia mais doze correções de segurança, incluindo um XSS refletido pré-autenticação no ecrã de login com potencial para execução de código PHP. A 7.0.4, a 12 de agosto, corrigia uma execução remota de código autenticada a nível de autor através do carregamento de um ficheiro malicioso em sites que usam Imagick e Ghostscript. A 17 de setembro, a 7.1.1 trouxe onze correções de segurança e 36 correções de bugs. A 22 de setembro, a 7.1.2 corrigiu uma falha crítica em que a resolução de templates de página podia ir buscar um ficheiro PHP local legível fora do tema ativo e, se as pré-condições se alinhassem, executá-lo.

O core teve um ano difícil. O wp2shell foi o mais barulhento, mas não foi o último, e não vai ser o último.

O que fazer no teu próprio site

• Confirma a versão. Não assumas. Uma atualização forçada nunca chega a um site cujo alojamento a desative, a um site com sistema de ficheiros só de leitura, ou ao site que alguém entregou a um freelancer há dois anos e esqueceu. As atualizações automáticas também saltam versões principais e podem falhar em silêncio. Enquanto escrevo, o lançamento atual é a 7.1.2. Se estás preso a um ramo mais antigo, as versões atualizadas aí são a 7.0.6, a 6.9.9 e a 6.8.10.
• Se não consegues mesmo atualizar hoje, bloqueia tanto /wp-json/batch/v1 como rest_route=/batch/v1, ou corta o acesso não autenticado à REST API por completo. Todos os fornecedores que publicaram estas mitigações chamaram-lhes medida de emergência, não correção. Trata-as assim e remove-as depois de estares atualizado.
• Procura restos. As contas de administrador criadas nesta campanha usavam nomes começados por w2s_ ou wp2_ seguidos de doze caracteres hexadecimais, muitas vezes com emails em webmaster.com ou hackerone.ltd. Verifica se há contas de administrador que não criaste, plugins que não instalaste e ficheiros PHP perdidos em wp-content/uploads/.
• Deixa as atualizações automáticas ligadas. A verdade incómoda é que os sites que passaram julho bem foram os que já estavam atualizados quando os scanners chegaram. Noventa minutos não dão para marcar uma janela de manutenção.

A conclusão a que volto sempre

O Kues encontrou esta cadeia com o GPT-5.6 Sol Ultra, em cerca de dez horas de trabalho e uns 25 dólares de computação. Os intermediários de exploits pagam alegadamente até 500.000 dólares por uma execução remota de código no core do WordPress. Essa diferença é a história toda da segurança em 2026: encontrar falhas graves é barato agora, e a distância entre uma correção e um exploit a funcionar mede-se em horas.

Não consegues correr mais depressa do que isso com boas intenções. Consegues manter a versão em dia, vigiar a tua lista de administradores e confirmar que a atualização que achas que aconteceu aconteceu mesmo. Eu verifico os meus todas as segundas. Leva noventa segundos, e é o melhor retorno que tenho de quaisquer noventa segundos na semana.