wp2shell: RCE Crítica no Núcleo do WordPress

Neste artigo do Blog Dolutech, vamos analisar em profundidade a vulnerabilidade que a comunidade de segurança já apelidou de wp2shell: uma cadeia de execução remota de código pré-autenticação que atinge o núcleo do WordPress e que, segundo estimativas do setor, pode afetar mais de 500 milhões de instalações no mundo. O caso é considerado um dos incidentes mais graves já registrados na plataforma, justamente porque não depende de plugins vulneráveis, temas mal configurados ou credenciais roubadas. Basta uma instalação padrão, sem qualquer personalização, exposta à internet.

A Dolutech acompanha o caso desde a divulgação, ocorrida em 17 de julho de 2026, e neste artigo reunimos o que se sabe até o momento sobre o mecanismo técnico da falha, as versões afetadas, o estado da exploração ativa, indicadores de comprometimento e, principalmente, o passo a passo de mitigação para administradores que não conseguem atualizar imediatamente.

O que é o wp2shell (CVE-2026-63030 e CVE-2026-60137)

wp2shell não é uma vulnerabilidade isolada, mas sim uma cadeia formada por duas falhas distintas no núcleo do WordPress que, combinadas, resultam em execução remota de código por um atacante não autenticado. O nome foi cunhado pela equipe da Searchlight Cyber, por meio de sua unidade de gestão de superfície de ataque, a Assetnote, responsável pela descoberta e pelo relato responsável do problema ao time de segurança do WordPress através do programa da HackerOne.

As duas peças da cadeia são:

• CVE-2026-63030: uma falha de confusão de rota no endpoint em lote da API REST (WP_REST_Server::serve_batch_request_v1()), classificada como CWE-436 e presente desde a introdução do endpoint em lote na versão 6.9. Essa é a porta de entrada da cadeia, avaliada como Crítica pelo aviso oficial no GitHub Security Advisory.
• CVE-2026-60137: uma injeção SQL no parâmetro author__not_in da classe WP_Query, o componente interno responsável por praticamente todas as consultas ao banco de dados que o WordPress executa. Essa falha recebeu pontuação CVSS 9.1, classificação Crítica, e atinge um alcance de versões maior, retroagindo até o ramo 6.8.

Isoladamente, cada uma das duas falhas já seria motivo de preocupação. A injeção SQL, sozinha, permite a um atacante extrair dados sensíveis do banco. Já a confusão de rota na API em lote, isolada, tem alcance mais limitado. O problema é que, encadeadas, elas permitem que um atacante anônimo, sem login, sem plugin instalado e sem qualquer configuração especial, assuma o controle total do servidor.

Como funciona a cadeia de exploração

Para que nossos leitores técnicos entendam a mecânica real do ataque, vale detalhar como as duas falhas se conectam na prática.

A injeção SQL em WP_Query

O ponto de partida é o parâmetro author__not_in, usado internamente para excluir determinados autores de uma consulta de posts. A sanitização esperada, feita por meio de uma verificação is_array(), falha quando o parâmetro chega como string em vez de array. Isso abre espaço para que um valor malicioso seja interpretado diretamente pela consulta SQL, permitindo leitura arbitrária do banco de dados, incluindo tabelas de usuários e hashes de senha de administradores.

A confusão de rota na API REST em lote

O endpoint /wp-json/batch/v1, disponível por padrão desde a versão 5.6 do WordPress (lançada em 2020), permite agrupar várias chamadas à API REST em uma única requisição HTTP. A falha de confusão de rota (route confusion) faz com que o despachante de lote interprete de forma incorreta o contexto de autenticação e o roteamento de sub-requisições internas, permitindo que uma requisição malformada alcance caminhos de código que não deveriam estar acessíveis a um usuário anônimo.

Da injeção SQL à execução remota de código

Quando as duas falhas são combinadas, o atacante consegue usar o endpoint em lote para acionar consultas internas vulneráveis ao author__not_in, sem precisar de autenticação. A partir daí, a cadeia técnica completa até a execução de código no servidor foi propositalmente omitida pelos pesquisadores que descobriram o problema, justamente para reduzir o tempo de exposição de sites que ainda não aplicaram a correção. Ainda assim, um proof-of-concept público já demonstra a etapa de injeção SQL isolada, capaz de ler o banco de dados e extrair hashes de senha, o que por si só já representa risco crítico mesmo antes de qualquer avanço para execução de código.

Segundo análise da Cloudflare, a cadeia completa depende também da ausência de um cache de objetos persistente, como Redis ou Memcached, no ambiente WordPress. Sites que já utilizam esse tipo de cache por outros motivos de performance acabam, incidentalmente, dificultando um dos passos da exploração, mas isso não deve ser tratado como mitigação suficiente e não substitui a atualização.

Quem está em risco: versões afetadas

A exposição varia de acordo com o ramo de versão em uso. É importante que administradores não tratem “estar em uma versão antiga” como sinônimo automático de vulnerabilidade à cadeia completa, já que o alcance das duas CVEs não é idêntico.

Ou seja: instalações no ramo 6.8 estão expostas apenas à injeção SQL, um problema sério, mas sem o vetor de execução remota de código. Já os ramos 6.9 e 7.0 reúnem as duas falhas e estão vulneráveis à cadeia completa do wp2shell, o cenário mais crítico.

Dada a gravidade, a equipe do WordPress tomou uma medida pouco comum: forçou a atualização automática em instalações elegíveis, mesmo naquelas que haviam desativado esse recurso manualmente. Ainda assim, nós reforçamos: administradores não devem presumir que a atualização forçada funcionou. É fundamental confirmar manualmente a versão instalada no painel administrativo ou via linha de comando.

Exploração ativa e panorama de ameaças

Até a publicação deste artigo, não havia confirmação pública de um exploit funcional para a cadeia completa até execução de código, já que os detalhes técnicos permanecem parcialmente retidos pelos pesquisadores. Isso não significa ausência de risco: a empresa de segurança PatchStack relatou sinais de possível exploração já na noite de divulgação, em 17 de julho de 2026, embora sem clareza sobre o que exatamente estava sendo observado nos ambientes monitorados. Além disso, um proof-of-concept público já demonstra a etapa isolada de injeção SQL, o suficiente para comprometer a confidencialidade de dados sensíveis.

A Dolutech recomenda cautela com a narrativa de “ainda não há exploração confirmada”. Historicamente, falhas críticas no núcleo do WordPress, sistema que move mais de 40% de todos os sites da internet, costumam ser armadas rapidamente assim que o patch é disponibilizado publicamente, já que atacantes podem comparar as versões corrigida e vulnerável para reconstruir o caminho de exploração. Grupos dedicados à automação de varredura e compromisso em massa de sites WordPress, como o cluster rastreado sob o nome WP-SHELLSTORM, já demonstraram em campanhas anteriores a capacidade de armar rapidamente vulnerabilidades recém-divulgadas em plugins e, em menor escala, no núcleo da plataforma, para distribuir web shells persistentes em escala industrial. Não há, até o momento, atribuição confirmada entre esse grupo específico e o wp2shell, mas o padrão de comportamento do ecossistema de crimeware voltado a WordPress reforça a urgência da correção.

Mapeamento MITRE ATT&CK

Para equipes de detecção e resposta, mapeamos a cadeia de exploração do wp2shell às táticas e técnicas do MITRE ATT&CK, útil para orientar regras de SIEM e playbooks de resposta a incidentes.

Indicadores de Comprometimento (IoC)

É importante um alerta claro aqui: como os pesquisadores da Searchlight Cyber optaram por reter os detalhes técnicos completos da etapa de execução remota de código, não existem, até o momento da publicação deste artigo, indicadores de comprometimento oficiais e específicos para a cadeia completa do wp2shell. Qualquer lista de IoCs neste estágio deve ser tratada como orientação geral de monitoramento, e não como uma assinatura definitiva de comprometimento por essa falha específica.

Dito isso, com base no vetor conhecido e em padrões observados em campanhas de web shell contra WordPress, recomendamos monitorar:

Caso sua equipe identifique qualquer um desses sinais combinados com uma versão vulnerável do WordPress, trate o incidente como comprometimento confirmado até prova em contrário, isole o servidor, preserve logs e inicie o processo de resposta a incidentes.

Um ponto que nós da Dolutech consideramos essencial reforçar: a ausência de IoCs oficiais não é sinônimo de ausência de risco. É justamente nas primeiras horas ou dias após a divulgação de uma cadeia crítica como essa que a maior parte das explorações automatizadas ocorre, já que scanners de vulnerabilidade e ferramentas de varredura em massa são reconfigurados rapidamente para testar o novo padrão de requisição assim que a comunidade de segurança começa a discutir o caso publicamente. Equipes de blue team devem considerar aumentar temporariamente o nível de log do servidor web e do WAF para capturar qualquer requisição direcionada ao endpoint em lote, mesmo que a assinatura completa do ataque ainda não seja pública.

Mapeamento de superfície de ataque e ferramentas de verificação

Além do monitoramento reativo, existem hoje ferramentas específicas para verificar a exposição da sua instalação ao wp2shell antes mesmo de aplicar a correção. A própria Searchlight Cyber disponibilizou um verificador público, que permite testar se uma instância está vulnerável sem executar a cadeia completa de exploração. Plataformas de gestão de exposição, como Rapid7 Exposure Command, InsightVM e Nexpose, também passaram a incluir verificações autenticadas específicas para a CVE-2026-63030 em seus conteúdos de varredura.

Para organizações que administram um portfólio grande de sites WordPress, seja uma agência, um provedor de hospedagem ou uma empresa com múltiplas propriedades digitais, a Dolutech recomenda tratar este incidente como gatilho para um inventário completo: liste todas as instalações WordPress sob sua responsabilidade, incluindo ambientes de desenvolvimento, homologação, sites institucionais secundários e instâncias esquecidas em subdomínios, e confirme a versão de cada uma individualmente. Uma atualização bem-sucedida em um site não garante que as demais instâncias do mesmo cliente ou da mesma infraestrutura tenham sido corrigidas.

Mitigação e correção

Solução definitiva: atualizar o WordPress

Não existe mitigação temporária que substitua a atualização. A correção definitiva é migrar para a versão corrigida do seu ramo:

# Verificar a versão atual via WP-CLI
wp core version

# Atualizar para a versão mais recente corrigida
wp core update

# Confirmar que a atualização foi aplicada
wp core version

Se sua instalação estiver no ramo 6.8, atualize para 6.8.6 ou posterior. Se estiver em 6.9 ou 7.0, o destino é 6.9.5 ou 7.0.2, respectivamente. Não presuma que a atualização automática forçada pelo WordPress.org já resolveu o problema: verifique manualmente cada instalação, incluindo ambientes de homologação, subdomínios esquecidos e sites de clientes sob sua gestão.

Mitigação temporária via WAF

Para ambientes onde a atualização imediata não é viável, por exemplo, sites com customizações extensas que exigem testes antes do deploy em produção, a mitigação recomendada é bloquear o acesso anônimo ao endpoint vulnerável na camada de firewall de aplicação web. Um exemplo de regra em Nginx, para ambientes que utilizam esse servidor como proxy reverso:

# Bloqueia acesso anônimo ao endpoint batch da REST API
location /wp-json/batch/v1 {
    if ($http_authorization = "") {
        return 403;
    }
}

# Bloqueia a rota alternativa via query string
if ($arg_rest_route = "/batch/v1") {
    return 403;
}

A Cloudflare já disponibilizou regras de WAF emergenciais para todos os seus clientes, incluindo o plano gratuito, cobrindo especificamente esse padrão de requisição. Se você utiliza soluções de firewall e prevenção de intrusão de código aberto, como BunkerWeb ou CrowdSec, o mesmo princípio se aplica: configure uma regra customizada para negar requisições não autenticadas ao caminho /wp-json/batch/v1 e ao parâmetro rest_route=/batch/v1, e adicione o padrão de exploração às suas listas de bloqueio comportamental, já que ambas as ferramentas suportam cenários de bloqueio baseado em assinatura e em comportamento de tráfego.

Plugin de mitigação temporária

Outra alternativa é adicionar uma camada de bloqueio diretamente na aplicação, via um plugin simples que rejeita requisições não autenticadas ao endpoint em lote. Veja um exemplo funcional:

<?php
/**
 * Plugin Name: Bloqueio Temporário - Batch API Não Autenticada
 * Description: Rejeita requisições anônimas ao endpoint REST batch/v1 enquanto o núcleo não é atualizado.
 * Version: 1.0.0
 */

defined( 'ABSPATH' ) || exit;

add_filter( 'rest_pre_dispatch', function ( $result, $server, $request ) {
    $route = $request->get_route();

    if ( strpos( $route, '/batch/v1' ) !== false && ! is_user_logged_in() ) {
        return new WP_Error(
            'rest_forbidden_batch',
            'Acesso não autenticado ao endpoint batch está temporariamente bloqueado por motivo de segurança.',
            array( 'status' => 403 )
        );
    }

    return $result;
}, 10, 3 );

Essa é uma medida emergencial e pode impactar integrações legítimas que dependem do endpoint em lote sem autenticação. Trate-a como paliativo, não como substituto da atualização do núcleo.

Se houver suspeita de comprometimento

Caso existam indícios de que o site já foi comprometido antes da aplicação da correção, a atualização do núcleo, sozinha, não remove um backdoor eventualmente instalado. Nesse cenário, recomendamos:

1. Restaurar a partir de um backup limpo e verificado, anterior à janela de exposição.
2. Rotacionar credenciais de banco de dados, hospedagem e usuários administradores.
3. Regenerar as chaves e salts de segurança do WordPress (wp-config.php).
4. Revogar sessões ativas de todos os usuários.
5. Aplicar a atualização do núcleo antes de reconectar o site à internet.
6. Realizar uma varredura completa em busca de web shells e arquivos modificados fora do ciclo normal de deploy.

Conformidade regulatória

O impacto potencial do wp2shell não se limita à disponibilidade do site: como a cadeia permite leitura do banco de dados e, no cenário mais grave, execução de código, ela pode resultar em exposição de dados pessoais armazenados na instalação, o que aciona obrigações regulatórias tanto no Brasil quanto na União Europeia e em Portugal.

No Brasil, sites que processam dados pessoais de usuários, como cadastros, formulários de contato ou dados de e-commerce, estão sujeitos à Lei Geral de Proteção de Dados (LGPD). Em caso de incidente de segurança que resulte em risco relevante aos titulares dos dados, a organização controladora deve avaliar a necessidade de comunicação à Autoridade Nacional de Proteção de Dados (ANPD) e, dependendo da gravidade, aos próprios titulares afetados.

Na Europa e em Portugal, o mesmo tipo de incidente pode acionar múltiplas obrigações simultâneas: o Regulamento Geral sobre a Proteção de Dados (GDPR), a diretiva NIS2 para operadores de serviços essenciais e importantes, e o DORA para entidades do setor financeiro. Empresas portuguesas devem também considerar a comunicação ao Centro Nacional de Cibersegurança (CNCS) e ao CERT.PT em cenários de incidente com potencial impacto relevante. Nós reforçamos que os prazos de notificação nesses regimes costumam ser curtos, geralmente contados em horas após a confirmação do incidente, o que torna a detecção precoce, discutida na seção de indicadores de comprometimento acima, ainda mais crítica.

Conclusão

O wp2shell é um lembrete de que mesmo o núcleo de um sistema tão maduro e amplamente auditado quanto o WordPress pode abrigar falhas críticas quando duas fraquezas aparentemente independentes se encontram. A combinação de confusão de rota na API REST com uma injeção SQL profunda na classe mais usada do sistema resultou em um dos cenários mais perigosos que a plataforma pode enfrentar: execução remota de código sem qualquer necessidade de autenticação, em instalações completamente padrão.

Neste artigo do Blog Dolutech, nosso objetivo foi reunir o estado atual do conhecimento público sobre a falha, os passos técnicos de mitigação e o contexto regulatório para que administradores e equipes de segurança no Brasil, em Portugal e no restante do mundo lusófono possam agir com prioridade máxima. A recomendação final da Dolutech é direta: atualize agora. Se não for possível atualizar imediatamente, bloqueie o endpoint vulnerável na camada de WAF enquanto o patch é validado em homologação. E, acima de tudo, não presuma que a atualização automática já resolveu o problema até confirmar manualmente cada instalação sob sua responsabilidade.

Lucas Catão de Moraes

Amante por tecnologia Especialista em Cibersegurança e Big Data, Formado em Administração de Infraestrutura de Redes, Pós-Graduado em Ciências de Dados e Big Data Analytics e Machine Learning, Com MBA em Segurança da Informação, Escritor do livro ” Cibersegurança: Protegendo a sua Reputação Digital”.