Sexta-feira, um quarto para as seis da tarde

O WordPress lançou uma versão de segurança a 17 de julho de 2026 que cobre duas vulnerabilidades no núcleo. A equipa de investigação da Searchlight Cyber, que descobriu a mais grave das duas, deu-lhe o nome wp2shell. Os identificadores registados são CVE-2026-63030, uma confusão de rotas no endpoint de lotes da API REST combinada com injeção de SQL, e CVE-2026-60137, uma injeção de SQL alcançável através do parâmetro author__not_in do WP_Query.

Às 17:45 da tarde, hora da costa leste dos Estados Unidos, no próprio dia da correção, a Rapid7 publicou a sua análise e registou duas coisas. Os detalhes técnicos do exploit ainda não tinham sido publicados e não havia conhecimento de exploração confirmada publicamente. Quem leu essa avaliação na sexta-feira tinha todos os motivos para acreditar que dispunha de uma semana de trabalho normal para agendar a atualização.

Não dispunha. A PatchStack começou a reportar exploração de ambos os CVE pouco antes das 19:00 da costa leste nessa mesma noite, cerca de uma hora depois do retrato da Rapid7. Até domingo, 19 de julho, a VulnCheck tinha verificado mais de duas dúzias de exploits de prova de conceito distintos dirigidos à falha.

Duas falhas, e a vossa versão tem duas respostas diferentes

A maior parte da cobertura trata isto como um só acontecimento com um só nome. São duas vulnerabilidades com alcances diferentes, e essa diferença decide o que é mesmo preciso fazer. Enganarem-se em qualquer dos sentidos desperdiça um fim de semana ou deixa um buraco aberto.

O CVE-2026-63030, a cadeia de execução remota de código, afeta o WordPress da 6.9.0 à 6.9.4 e da 7.0.0 à 7.0.1. Está corrigido na 6.9.5 e na 7.0.2, e na linha beta 7.1 a partir da Beta 2. O CVE-2026-60137, a injeção de SQL no WP_Query, recua mais no tempo. Afeta da 6.8.0 à 6.8.5, além dos mesmos intervalos 6.9 e 7.0, e a correção para o ramo mais antigo é a 6.8.6.

A consequência prática é que um site parado na 6.8.x lê os títulos sobre o wp2shell, verifica se está no intervalo 6.9 ou 7.0, conclui que não está afetado e para por aí. Esse site não está exposto à cadeia completa de execução de código não autenticada, mas está exposto à injeção de SQL, e continua a ter de passar para a 6.8.6. As verificações de versão feitas contra o CVE errado são a forma mais provável de uma organização falhar isto esta semana.

A rede de segurança apanha justamente os sites que menos importam

Os responsáveis pelo WordPress reagiram a forçar atualizações nas instalações afetadas que tinham as atualizações automáticas ligadas. É a decisão certa e terá protegido um número muito grande de sites ao longo do fim de semana sem que ninguém lhes tocasse.

Reparem antes em quais os sites que não protegeu. As atualizações automáticas são desligadas de propósito, e as razões são sempre as mesmas: um processo de controlo de alterações, um plugin que se partiu numa versão menor anterior, um percurso de pré-produção para produção, um contrato de agência que atribui a responsabilidade das atualizações a uma pessoa, um regime de conformidade que proíbe alterações não revistas em produção. Cada uma destas razões assinala uma instalação que alguém considera importante ao ponto de a querer gerir.

Ou seja, a rede de segurança automática está inversamente correlacionada com a criticidade para o negócio. O blogue de fim de semana atualizou-se sozinho na noite de sexta. O portal de clientes, o sistema de reservas e o site que recebe pagamentos ficaram na versão vulnerável durante um fim de semana em que o código de ataque funcional passou de zero para mais de duas dúzias. Se a vossa organização desligou as atualizações automáticas como sinal de maturidade, foi este o fim de semana em que essa decisão se pagou.

O que a curva do fim de semana está mesmo a medir

O número útil aqui não é uma pontuação CVSS, e os fornecedores nem sequer estão totalmente de acordo quanto à gravidade. A Rapid7 regista CVSS 7.5 para a cadeia de execução remota, enquanto o aviso correspondente a trata como crítica, e a VulnCheck considera a injeção de SQL a mais crítica das duas. Discutir que número se põe no ticket é um mau uso do tempo que têm.

O número que conta é o intervalo entre o patch e a transformação em arma. Aqui mediu-se em horas até aos primeiros relatos de exploração e em cerca de dois dias até à disponibilidade pública alargada de exploits. É esse o nível de serviço real que o vosso processo de correção tem de cumprir, e quase nenhuma organização o cumpre com a política que tem escrita. Uma janela de remediação de trinta dias, comum nos referenciais de conformidade, não é uma política de correção para uma falha destas. É a descrição do tempo durante o qual estiveram expostos.

Há um segundo pormenor nos exploits mais recentes que fecha a saída do costume. A VulnCheck reporta que, até domingo, tinham surgido implementações adicionais de execução remota de código que contornam por completo a autenticação de administrador. As equipas que contavam apoiar-se em contas de administração endurecidas, páginas de login restritas ou segundo fator no wp-admin como controlo compensatório têm de perceber que essas medidas não estão no caminho deste ataque.

Quatro coisas que vale a pena fazer hoje

Primeiro, inventariar antes de aplicar o patch. Encontrem todas as instalações WordPress que a vossa organização tem de facto, incluindo os microsites de marketing, as páginas de campanha, o site da conferência de há dois anos e tudo o que uma agência que já saiu construiu. A instalação vulnerável quase nunca é a que consta do registo de ativos. É aquela de que ninguém se lembrava que continuava a servir tráfego.

Segundo, verifiquem cada uma contra o CVE certo. Tudo o que esteja na 6.8.x vai para a 6.8.6. Tudo o que esteja na 6.9.x vai para a 6.9.5. Tudo o que esteja na 7.0.x vai para a 7.0.2. Não deixem que um único pressuposto sobre intervalo de versões cubra o parque inteiro.

Terceiro, tratem qualquer instalação por corrigir que esteve virada para a internet durante o fim de semana como potencialmente comprometida e não apenas como vulnerável, e procurem as provas em vez de assumirem a ausência delas. Aplicar o patch fecha a porta. Não põe lá fora quem já está dentro. Quarto, e este é o que fica, escrevam qual foi o tempo real até à correção na vossa organização neste caso e comparem-no com o número que publicam na política. A distância entre esses dois valores é o que há para corrigir, porque a próxima vulnerabilidade do núcleo vai correr no mesmo relógio.

Leia a seguir: A correção do nginx saiu, o exploit chega em agosto  |  A ServiceNow corrigiu primeiro a nuvem dela, a sua casa só 103 dias depois