A CISA adicionou o WordPress Core ao catálogo de vulnerabilidades exploradas (KEV) em 21 de julho de 2026, depois de confirmar exploração ativa da falha CVE-2026-63030, conhecida como wp2shell. A vulnerabilidade, com CVSS 9,8, permite execução remota de código sem autenticação quando combinada com a injeção de SQL CVE-2026-60137, e atinge instalações das versões 6.9 e 7.0 ainda não atualizadas. A correção está nas versões 6.9.5 e 7.0.2, liberadas em 17 de julho, e a agência fixou um prazo de apenas três dias para a mitigação.

O WordPress sustenta uma fatia considerável da web pública, e código de exploração já está disponível. A janela entre a divulgação do patch e a entrada no KEV foi curta, o que torna a atualização urgente para qualquer administrador de site.

Mecanismo técnico do wp2shell

A vulnerabilidade CVE-2026-63030 consiste numa confusão de rota no endpoint batch da API REST do WordPress que, combinada com a injeção de SQL no parâmetro author__not_in da classe WP_Query (CVE-2026-60137), permite execução remota de código sem autenticação. Em vez de uma única porta de entrada, o atacante encadeia duas falhas: a primeira manipula o roteamento interno da API REST para alcançar um manipulador vulnerável, e a segunda injeta comandos SQL que terminam escapando para execução de código no servidor.

O NVD classifica o CVE-2026-63030 como 9,8 crítico, com vetor CVSS 3.1 AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H, sinalizando impacto total sobre confidencialidade, integridade e disponibilidade sem credenciais ou interação do usuário. O segundo componente, CVE-2026-60137, recebe nota 5,9 isoladamente, mas é a peça que torna o ataque viável quando o ambiente também apresenta a confusão de rota.

A exploração não exige credenciais válidas nem interação de um usuário autenticado: basta que a instalação esteja acessível pela internet e rodando uma versão vulnerável. Por isso, sites expostos publicamente — portais institucionais, blogs corporativos e lojas — estão no grupo de maior risco, especialmente aqueles com autoatualização desativada ou bloqueada por plugins de cache e fluxos de deploy personalizados.

Versões afetadas e correção

O WordPress liberou a versão 7.0.2 em 17 de julho de 2026 como um lançamento de segurança que corrige uma vulnerabilidade crítica e uma de alta gravidade, e a equipe ativou a atualização forçada via sistema de autoatualização para sites em versões afetadas. Instalações compatíveis devem ter recebido o patch de forma automática.

Versão Status Correção
6.8.0 a 6.8.5 Afetada (apenas CVE-2026-60137) 6.8.6
6.9.0 a 6.9.4 Afetada (ambas as CVEs) 6.9.5
7.0.0 e 7.0.1 Afetada (ambas as CVEs) 7.0.2
Anteriores a 6.8 Não afetadas

Versões anteriores à 6.8 não são afetadas por nenhuma das duas falhas. O backport 6.8.6 fecha apenas a injeção de SQL, pois a confusão de rota da API REST só existe a partir da linha 6.9. Quem opera a 6.8 deve aplicar a 6.8.6; quem está na 6.9 ou 7.0 deve ir direto para 6.9.5 ou 7.0.2.

Como verificar seu site

Mesmo com a atualização automática, equipes de segurança devem confirmar a aplicação do patch e procurar indícios de acesso não autorizado anteriores à correção. Essa verificação é central porque a entrada no KEV exige avaliar se o sistema já estava comprometido antes do patch.

  1. Confirme a versão do WordPress em cada site; instâncias entre 6.8.0 e 7.0.1 precisam estar em 6.8.6, 6.9.5 ou 7.0.2.
  2. Revise usuários administradores recém-criados, plugins desconhecidos e arquivos PHP alterados na pasta wp-content.
  3. Analise logs de acesso em busca de requisições anômalas aos endpoints batch da API REST nos últimos 30 dias.
  4. Verifique a integridade do banco de dados quanto a contas, tokens e permissões modificadas.
  5. Scanners como o OpenVAS ajudam a localizar instalações não corrigidas em ambientes com vários ativos.

Exploração ativa em larga escala

Provas de conceito públicas já circulam para o wp2shell, e pesquisadores registram varreduras em massa procurando instalações WordPress não corrigidas para encadear as duas falhas e implantar web shells. O EPSS aponta 77% de probabilidade de exploração nos próximos 30 dias, e relatos de campo descrevem atacantes instalando plugins maliciosos após obter acesso.

O padrão lembra outras falhas críticas de execução remota que entraram recentemente no KEV, como a falha de RCE no Langflow, em que a janela entre o patch e a exploração ativa coube em poucos dias. A diferença do WordPress é a escala: cada site desatualizado vira um alvo viável para automação.

Depois de obter execução de código, os atacantes costumam criar contas de administrador ocultas, injetar plugins maliciosos que recriam acesso mesmo após a atualização e roubar credenciais de banco de dados. Por isso, apenas aplicar o patch não elimina um comprometimento já existente; é preciso caçar persistência e redefinir credenciais privilegiadas.

Fontes