wp2shell: falha crítica no núcleo do WordPress permite RCE sem autenticação em milhões de sites
Uma vulnerabilidade crítica no núcleo do WordPress, apelidada de “wp2shell”, abriu a porta para execução remota de código (RCE) sem qualquer tipo de autenticação em instalações que utilizam versões recentes da plataforma. A falha, identificada por pesquisadores da Searchlight Cyber, afeta especificamente o WordPress 6.9.0 a 6.9.4 e 7.0.0 a 7.0.1, colocando em risco milhões de sites ao redor do mundo.
O ponto mais alarmante é que o ataque não exige qualquer condição prévia: um invasor anônimo pode explorar a brecha em uma instalação padrão do WordPress, mesmo sem plugins adicionais instalados ou configurações personalizadas. Em um cenário em que mais de 500 milhões de sites dependem do WordPress, o impacto potencial é massivo.
Como a falha wp2shell funciona
Segundo a descrição da Searchlight Cyber, a exploração da wp2shell não é resultado de um único bug, mas sim do encadeamento de duas vulnerabilidades independentes que, combinadas, permitem RCE antes de qualquer autenticação:
1. CVE-2026-63030 – Falha de confusão de rota em lote na API REST
Introduzida a partir da versão 6.9, essa falha está ligada ao recurso de requisições em lote da API REST. Um atacante consegue manipular a forma como as rotas são processadas, burlando validações de permissão ou atingindo endpoints que, em teoria, deveriam estar protegidos.
2. CVE-2026-60137 – Injeção SQL no parâmetro `author__not_in` do `WP_Query`
Presente a partir do WordPress 6.8, essa vulnerabilidade permite que dados maliciosos injetados no parâmetro `author__not_in` sejam enviados diretamente para o banco de dados sem a devida sanitização. Isso abre espaço para manipular consultas SQL, extraindo informações sensíveis ou preparando terreno para ações mais destrutivas, como a própria RCE.
A combinação dessas duas falhas afeta, de forma completa, apenas as linhas 6.9.x e 7.0.x do WordPress, justamente porque a vulnerabilidade na API REST só passou a existir a partir da versão 6.9. Em outras palavras, a injeção SQL por si só já é preocupante, mas é a presença simultânea da falha na API que torna possível o cenário de execução remota de código sem autenticação.
O que a RCE permite na prática
Quando um invasor consegue execução remota de código no servidor, ele basicamente passa a ter a capacidade de rodar comandos como se fosse um usuário com acesso direto à máquina. Isso pode incluir:
– Envio e execução de webshells para manter acesso persistente;
– Criação de novos usuários administrativos no WordPress;
– Modificação de temas e plugins para inclusão de backdoors;
– Roubo de credenciais, dados pessoais e informações de pagamento;
– Utilização do servidor comprometido em campanhas de spam, phishing ou ataques a outros sistemas.
Em ambientes de hospedagem compartilhada, o risco é ainda maior, pois um comprometimento pode servir de ponte para tentar atacar outros sites no mesmo servidor.
Versões afetadas em detalhes
De forma resumida, o cenário fica assim:
– CVE-2026-60137 (SQL Injection em `author__not_in`)
– Afeta: WordPress 6.8 e versões posteriores.
– CVE-2026-63030 (confusão de rota em lote na API REST)
– Introduzida no WordPress 6.9.
– Cadeia completa de ataque wp2shell (RCE sem autenticação)
– Afeta: WordPress 6.9.0 a 6.9.4 e 7.0.0 a 7.0.1.
Instalações em versões anteriores a 6.8 não têm a falha específica no parâmetro `author__not_in`, mas isso não significa que estejam “seguras” no sentido amplo: apenas não são vulneráveis a essa cadeia exata de ataque. Manter versões antigas é, em si, um grande risco de segurança por outros motivos.
Recomendações de correção imediata
A medida mais importante para mitigar a falha wp2shell é a atualização do WordPress para uma versão corrigida. A orientação é clara:
– Atualizar para WordPress 7.0.2 ou superior, ou
– Atualizar para WordPress 6.9.5 na linha 6.9, caso não seja possível migrar para 7.x imediatamente.
Essas versões trazem correções tanto para a vulnerabilidade da API REST quanto para a injeção SQL em `author__not_in`, interrompendo a cadeia de ataque que possibilita o RCE.
Antes de atualizar, é essencial:
– Fazer um backup completo (arquivos + banco de dados);
– Verificar compatibilidade de temas e plugins;
– Testar a atualização em ambiente de homologação, se possível, para evitar indisponibilidades em produção.
Medidas temporárias de contenção
Para administradores que, por questões técnicas ou de negócio, não conseguem aplicar a atualização de imediato, a Searchlight Cyber sugere medidas emergenciais:
– Bloquear acesso anônimo à API REST
É possível restringir o uso da API REST a usuários autenticados ou a determinados IPs, por meio de plugins de segurança ou regras customizadas.
– Bloquear rotas específicas da API REST
Bloquear o acesso aos caminhos `/wp-json/batch/v1` e `?rest_route=/batch/v1` no nível de WAF ou servidor web reduz a superfície de ataque ligada à falha de confusão de rota em lote.
No entanto, essas medidas podem afetar funcionalidades legítimas do site, como integrações com aplicações externas, plugins que usam intensivamente a API REST ou recursos de headless WordPress. Por isso, devem ser vistas como paliativos, não como solução definitiva.
Como verificar se o site está vulnerável
Para facilitar a identificação de instalações vulneráveis, a Searchlight Cyber disponibilizou uma ferramenta pública chamada wp2shell, que permite checar se um site roda versões de WordPress afetadas e se determinados vetores de ataque estão expostos.
Embora os detalhes técnicos completos da exploração não tenham sido divulgados para evitar ataques em massa antes da correção, a ferramenta se propõe a:
– Identificar a versão exata do WordPress;
– Verificar a presença de rotas críticas da API REST;
– Checar parâmetros vulneráveis associados ao `WP_Query`.
Administradores podem utilizar essa verificação como complemento à própria auditoria interna, validando se suas medidas de proteção foram aplicadas corretamente.
Como saber se o seu site já foi comprometido
Além de atualizar e bloquear rotas, é importante verificar se algum invasor já explorou a falha. Alguns sinais comuns de comprometimento:
– Presença de arquivos estranhos em diretórios como `wp-content/uploads`, `wp-includes` ou na raiz do site;
– Modificações não autorizadas em arquivos de tema (`functions.php`, `header.php`, etc.) ou de plugins;
– Usuários administrativos desconhecidos no painel;
– Redirecionamentos inesperados, páginas de spam ou conteúdo injetado;
– Aumento repentino e não explicado no uso de CPU, memória ou tráfego de rede.
Ferramentas de varredura de malware específicas para WordPress podem ajudar a identificar alterações maliciosas em arquivos e no banco de dados.
Boas práticas de hardening para WordPress
A falha wp2shell reforça a necessidade de tratar WordPress como um sistema crítico de informação, não apenas como uma ferramenta de blog ou site institucional. Além da atualização, é recomendável:
– Ativar atualizações automáticas para versões de segurança;
– Usar plugins de segurança com firewall de aplicação, detecção de anomalias e limitação de tentativas de login;
– Restringir acesso ao painel administrativo por IP ou VPN;
– Utilizar senhas fortes e autenticação em dois fatores para contas administrativas;
– Separar o usuário do banco de dados com permissões mínimas necessárias;
– Manter backup automatizado e testado regularmente;
– Monitorar logs de acessos e erros do servidor e do próprio WordPress.
Essas medidas não impedem que vulnerabilidades futuras sejam descobertas, mas reduzem drasticamente o impacto de um possível comprometimento.
Resposta a incidentes: o que fazer se você suspeita de invasão
Caso haja suspeita de que a wp2shell (ou qualquer outra falha) já tenha sido explorada:
1. Isolar o ambiente
– Se possível, colocar o site em modo de manutenção ou restringir o acesso temporariamente.
2. Preservar evidências
– Fazer cópia dos arquivos e do banco de dados antes de qualquer limpeza, para análise posterior.
3. Atualizar imediatamente
– Aplicar os patches de segurança do WordPress e de todos os plugins e temas.
4. Varredura completa
– Utilizar ferramentas de segurança para identificar webshells, scripts maliciosos e alterações suspeitas.
5. Alterar todas as credenciais
– Senhas de painel, FTP/SSH, banco de dados, painel de hospedagem e, se necessário, chaves de API de integrações externas.
6. Revisar logs e ajustar defesas
– Analisar como o ataque entrou, ajustar WAF, regras de firewall e endurecer a configuração do servidor.
Por que detalhes técnicos foram retidos
A decisão da Searchlight Cyber de não divulgar, neste momento, todos os detalhes técnicos da exploração da wp2shell segue uma prática comum em segurança: o chamado “divulgamento responsável”. O objetivo é dar tempo para que administradores:
– Apliquem as atualizações de segurança;
– Implementem medidas de contenção;
– Verifiquem possíveis indícios de comprometimento.
Somente após uma janela razoável de correção é que detalhes mais profundos costumam ser liberados, inclusive para uso da comunidade de pesquisa em segurança na criação de novas defesas.
Em resumo
A vulnerabilidade wp2shell expõe um ponto sensível do ecossistema WordPress: mesmo instalações “puras”, sem plugins, podem estar sujeitas a falhas graves no próprio núcleo. A única forma segura de mitigar o risco é:
– Atualizar o WordPress para versões corrigidas (7.0.2 ou 6.9.5 em diante);
– Adotar, quando necessário, bloqueios temporários na API REST;
– Utilizar ferramentas de verificação e monitoramento;
– Reforçar práticas permanentes de segurança e resposta a incidentes.
Ignorar a atualização ou depender apenas de paliativos aumenta significativamente a chance de que um ataque remoto transforme o seu site em um ponto de partida para fraudes, roubo de dados ou novas campanhas maliciosas.