Uma vulnerabilidade descoberta no núcleo do WordPress colocou administradores de sites em alerta. Identificada como CVE-2026-63030 e apelidada de WP2Shell, a falha pode ser combinada com outro problema de segurança para permitir a execução remota de código em servidores vulneráveis.
O risco chama atenção porque o ataque não depende de um plugin comprometido, de credenciais válidas ou da interação de um usuário. A cadeia divulgada pelos pesquisadores pode atingir uma instalação padrão do WordPress, diretamente por meio da API REST do sistema.
O WordPress publicou atualizações emergenciais em 17 de julho de 2026 e recomendou que os responsáveis pelos sites atualizassem suas instalações imediatamente. A gravidade também levou o projeto a habilitar atualizações automáticas forçadas para versões afetadas.
A vulnerabilidade está no núcleo do WordPress
Grande parte das vulnerabilidades associadas ao WordPress costuma ser encontrada em plugins ou temas de terceiros. No caso da WP2Shell, o problema está no próprio núcleo da plataforma.
A CVE-2026-63030 afeta o endpoint de processamento em lote da API REST do WordPress. A falha provoca uma confusão na forma como determinadas rotas são interpretadas, permitindo que uma solicitação seja processada de maneira diferente do comportamento esperado pelos controles de segurança.
Isoladamente, esse problema não explica toda a gravidade do ataque. O cenário mais perigoso aparece quando a CVE-2026-63030 é combinada com a CVE-2026-60137, uma vulnerabilidade de injeção de SQL relacionada ao parâmetro author__not_in utilizado pelo componente WP_Query.
A segunda falha permite interferir em consultas realizadas no banco de dados. Inicialmente, a exploração dessa injeção de SQL estaria limitada a usuários autenticados. A confusão de rotas da CVE-2026-63030, porém, consegue contornar essa barreira e tornar a cadeia acessível para um invasor sem autenticação.
Como a WP2Shell pode ser explorada
A API REST permite que aplicações externas se comuniquem com o WordPress. Ela é usada por recursos legítimos da plataforma, integrações, editores e diferentes ferramentas de gerenciamento.
O problema está no endpoint responsável por processar várias requisições em lote. Ao manipular esse fluxo, um invasor pode alcançar a consulta vulnerável no WP_Query sem precisar estar conectado ao painel administrativo.
A injeção de SQL pode ser usada para acessar informações armazenadas no banco de dados, incluindo dados relacionados aos usuários do site. Os primeiros caminhos de exploração estudados envolviam a obtenção do hash da senha de uma conta administrativa, a tentativa de quebra dessa senha e o posterior acesso ao painel.
Depois de conseguir privilégios administrativos, o invasor poderia modificar temas, instalar plugins maliciosos, criar novas contas ou enviar uma webshell ao servidor.
Pesquisadores também desenvolveram caminhos capazes de alcançar execução de código sem depender da quebra da senha ou de uma autenticação posterior. A VulnCheck informou que, até 19 de julho, havia validado mais de duas dezenas de provas de conceito diferentes relacionadas à WP2Shell.
O ataque exige algum plugin vulnerável?
Não. Segundo a Searchlight Cyber, responsável pela descoberta da CVE-2026-63030, a cadeia pode ser explorada contra uma instalação padrão do WordPress, sem plugins adicionais.
Também não é necessário que o invasor possua uma conta ou convença alguém a abrir um arquivo ou acessar um endereço malicioso. O ataque pode partir diretamente da internet contra o endpoint vulnerável.
A Cloudflare acrescentou uma condição técnica importante: o caminho conhecido de execução remota de código pode ser alcançado quando a instalação não utiliza um cache persistente de objetos. Esse é um cenário comum em muitos sites WordPress, principalmente em ambientes menores ou hospedagens com configurações mais simples.
Quais versões do WordPress estão vulneráveis?
A CVE-2026-63030 afeta o WordPress nas versões 6.9.0 até 6.9.4 e 7.0.0 até 7.0.1. As correções foram incluídas nas versões 6.9.5 e 7.0.2.
A versão de testes 7.1 também recebeu a correção a partir da Beta 2.
A situação da linha 6.8 é diferente. Ela não é afetada pela confusão de rotas identificada como CVE-2026-63030, mas contém a injeção de SQL CVE-2026-60137 entre as versões 6.8.0 e 6.8.5. Nesse caso, a correção foi publicada no WordPress 6.8.6.
Versões anteriores ao WordPress 6.8 não são afetadas pelas duas vulnerabilidades divulgadas nessa atualização.
Por que a vulnerabilidade é considerada crítica?
A classificação crítica está relacionada à possibilidade de comprometimento completo do site sem autenticação.
Uma execução remota de código permite que comandos ou arquivos controlados pelo atacante sejam executados no servidor. Dependendo das permissões concedidas ao processo do WordPress e da configuração da hospedagem, o invasor pode obter acesso a arquivos, banco de dados, credenciais e outros recursos presentes no ambiente.
O ataque pode resultar na alteração do conteúdo do site, criação de administradores ocultos, roubo de dados, redirecionamento de visitantes, distribuição de malware ou instalação de mecanismos de persistência.
Em servidores que hospedam vários sites na mesma conta ou compartilham credenciais e diretórios, o impacto pode ultrapassar uma única instalação do WordPress.
O GitHub classificou o advisory como crítico. No NVD, a WPScan atribuiu pontuação CVSS 9.8, enquanto a avaliação da CISA registrou 7.5. O próprio NVD ainda não havia publicado uma avaliação independente no momento da divulgação.
Existem ataques acontecendo na internet?
No momento inicial da divulgação, ainda não havia confirmação pública clara de exploração em larga escala. Esse cenário mudou rapidamente com a publicação e validação de diferentes provas de conceito.
A VulnCheck relatou o surgimento de informações sobre possíveis atividades reais e confirmou mais de duas dezenas de implementações de prova de conceito. A empresa também observou que o alcance exato das primeiras atividades detectadas ainda não estava completamente esclarecido.
A disponibilidade de códigos públicos reduz o esforço necessário para que criminosos automatizem varreduras em busca de sites desatualizados. Isso torna especialmente perigoso manter uma instalação vulnerável exposta, mesmo que ela não armazene informações consideradas sensíveis.
Sites comprometidos também podem ser utilizados como infraestrutura para phishing, distribuição de malware, fraude, mineração de criptomoedas ou ataques contra terceiros.
Como corrigir a WP2Shell
A principal medida de proteção é atualizar o WordPress. Instalações da linha 6.9 devem utilizar a versão 6.9.5 ou posterior. Ambientes da linha 7.0 devem utilizar a versão 7.0.2 ou posterior.
Quem ainda utiliza a linha 6.8 deve instalar a versão 6.8.6 para corrigir a CVE-2026-60137, mesmo que essa linha não esteja exposta à cadeia completa da WP2Shell.
Embora o WordPress tenha ativado atualizações automáticas forçadas para versões afetadas, os administradores não devem assumir que a correção foi aplicada corretamente. Falhas de permissão, configurações da hospedagem, alterações no núcleo e bloqueios de conexão podem impedir a atualização automática.
É necessário acessar o painel administrativo ou verificar os arquivos da instalação para confirmar a versão realmente utilizada pelo site.
Antes da atualização, também é recomendável criar um backup completo dos arquivos e do banco de dados. O backup deve ser armazenado fora do servidor principal e testado para garantir que possa ser restaurado caso ocorra algum problema.
O WAF substitui a atualização?
Não. Regras de Web Application Firewall podem reduzir a exposição, mas não corrigem o código vulnerável.
A Cloudflare informou ter implantado regras para bloquear tentativas associadas às duas vulnerabilidades, inclusive para clientes do plano gratuito quando o tráfego do site passa pelo proxy e pelo WAF da empresa.
Os administradores devem verificar se as regras estão realmente ativas e configuradas para bloquear, e não apenas registrar, as solicitações maliciosas.
Quando a atualização imediata não for possível, uma mitigação temporária consiste em bloquear o acesso anônimo aos caminhos /wp-json/batch/v1 e ?rest_route=/batch/v1. Essa medida pode afetar integrações e recursos legítimos do site, por isso deve ser usada apenas até que a atualização possa ser instalada.
Sites atualizados ainda precisam ser verificados
Atualizar o WordPress impede novas tentativas contra a vulnerabilidade, mas não remove alterações realizadas antes da aplicação da correção.
Administradores que mantiveram versões vulneráveis expostas devem revisar os registros do servidor e do WAF em busca de requisições suspeitas direcionadas aos endpoints de processamento em lote da API REST.
Também é importante verificar contas administrativas desconhecidas, plugins instalados recentemente, alterações em temas, tarefas agendadas, arquivos PHP adicionados ou modificados e conexões externas incomuns.
As credenciais administrativas, do banco de dados, da hospedagem e de serviços relacionados devem ser trocadas quando houver qualquer indício de comprometimento. Em situações suspeitas, a análise não deve se limitar ao painel do WordPress, pois uma webshell pode permanecer ativa mesmo depois da atualização.
Falhas no WordPress exigem resposta rápida
A WP2Shell mostra como duas vulnerabilidades com funções diferentes podem formar uma cadeia de ataque muito mais grave.
A CVE-2026-63030 abre um caminho pela API REST, enquanto a CVE-2026-60137 permite interferir nas consultas ao banco de dados. Quando combinadas, elas podem levar à execução remota de código sem autenticação em versões vulneráveis do WordPress.
Como já existem diferentes provas de conceito públicas, adiar a atualização aumenta o período em que o site permanece exposto a varreduras e ataques automatizados.
A correção deve ser tratada como prioridade, acompanhada da confirmação da versão instalada e de uma verificação cuidadosa para identificar possíveis sinais de comprometimento anterior.
