wp2shell: um request, RCE no WordPress — e o que fazer se você demorou pra atualizar

Na noite de sexta-feira, 17 de julho de 2026, o WordPress publicou as versões 6.9.5 e 7.0.2. Antes do domingo, honeypots já contavam dezenas de milhares de tentativas de exploração. Na terça, 21, os dois CVEs entraram no catálogo KEV da CISA — o carimbo oficial de "está sendo usado contra alvos reais agora".

O apelido é wp2shell. E ele é diferente da enxurrada de vulnerabilidades de plugin que a gente comenta todo mês.

Por que essa é diferente

Quase toda falha grave de WordPress dos últimos anos veio de plugin ou tema de terceiro. A resposta padrão — "eu uso poucos plugins, e todos populares" — funcionava razoavelmente bem.

O wp2shell não é plugin. É o core, instalação limpa, zero plugins, e o atacante não precisa de conta nenhuma. Nas palavras de Ben Marr, engenheiro de segurança da Intruder:

"Este exploit utiliza uma cadeia de vulnerabilidades em duas partes para conseguir execução de código não autenticada em uma instalação padrão do WordPress com uma única requisição HTTP."

A cadeia tem dois elos:

• CVE-2026-63030 — confusão de rota no endpoint de batch da REST API (/wp-json/batch/v1), que faz o WordPress executar uma rota interna como se a requisição já estivesse autenticada. É o furo de autenticação.
• CVE-2026-60137 — SQL injection no parâmetro author__not_in do WP_Query. É a alavanca: com a autenticação contornada, o atacante alcança o banco.

Junte os dois e você tem leitura do banco (hashes de senha, e-mails, wp_options) e, em seguida, upload de plugin malicioso — ou seja, PHP arbitrário rodando no seu servidor.

Detalhe que quase ninguém comenta: a cadeia foi encontrada com auxílio de IA. A Searchlight Cyber levou pouco mais de 10 horas de análise assistida por modelo para achar o caminho. Guarde esse número — ele volta no post sobre a janela entre o patch e o exploit em massa.

Quem está vulnerável

O time do WordPress.org acionou atualização forçada pelo sistema de auto-update para versões afetadas. Isso salvou uma quantidade enorme de sites — e não salvou justamente os que costumam ser críticos: instalações com auto-update desligado, versão travada por compatibilidade de tema, ou hospedagem que congela o core "pra não quebrar nada".

Se você é agência e trava versão de propósito, você está exatamente no grupo que ficou de fora do resgate automático.

O tamanho do estrago

Os números que saíram até agora:

• A Wiz estimou que, na data da publicação, 60% das organizações que usam WordPress tinham pelo menos uma instância vulnerável — e 25% tinham servidor vulnerável exposto à internet.
• A watchTowr registrou dezenas de milhares de tentativas vindas de 13 endereços IP únicos (Suíça, Alemanha, Reino Unido, Indonésia, Lituânia, Holanda e Singapura). Poucos IPs, volume industrial: é varredura automatizada, não ataque direcionado.
• A VulnCheck contou mais de duas dúzias de PoCs públicos distintos já no domingo, dia 19.
• Pesquisadores documentaram mais de 100 contas de administrador criadas em sites comprometidos.

E o achado mais desagradável: um web shell de 150 KB disfarçado de plugin de segurança chamado "CMSmap", descrito como uma plataforma de ataque completa — acesso ao banco, varredura de portas e módulos de escalação de privilégio. Não é um eval($_POST) de duas linhas. É ferramenta de operador.

Atualizar não encerra o assunto

Esta é a parte que mais gente erra.

Se o seu site foi explorado antes de você atualizar, o patch fecha a porta — mas o intruso já está dentro. A conta admin criada no dia 18 continua funcionando no dia 30. O plugin falso continua no disco. A chave de API que estava no wp-config.php já foi lida.

Atualizar é o passo 1 de 4, não o único.

Passo a passo pra checar hoje

1. Confirme a versão instalada

No painel: Painel → Atualizações. Se estiver abaixo de 6.9.5 (linha 6.9) ou 7.0.2 (linha 7.0), atualize antes de continuar lendo.

Por fora, sem entrar no painel:

curl -s https://seusite.com.br/ | grep -i 'name="generator"'
curl -s https://seusite.com.br/readme.html | grep -i 'Versão\|Version'

Se algum desses devolver a versão, o atacante também consegue lê-la — e é assim que a varredura em massa escolhe alvo.

2. Procure conta de administrador que você não criou

Usuários → Todos → Administrador. Olhe data de registro e e-mail. As contas plantadas em campanhas automatizadas costumam ter nome plausível e e-mail em domínio descartável.

Via WP-CLI, que é mais rápido em parque grande:

wp user list --role=administrator --fields=ID,user_login,user_email,user_registered

Qualquer conta registrada a partir de 17 de julho de 2026 que você não reconheça é suspeita até prova em contrário.

3. Procure plugin que você não instalou

Plugins → Instalados, incluindo os inativos. Atenção especial a qualquer coisa com cara de ferramenta de segurança que você não lembra de ter instalado — "CMSmap" é o nome relatado nesta campanha, mas o nome é a parte mais fácil de trocar.

Confira também o diretório direto no servidor, porque plugin malicioso costuma se esconder do listado:

ls -la wp-content/plugins/
ls -la wp-content/mu-plugins/
find wp-content/uploads/ -name "*.php"

Arquivo .php dentro de wp-content/uploads/ é anomalia em praticamente 100% dos casos. Não deveria existir nenhum.

4. Olhe o que roda sozinho

wp cron event list

Backdoor bom se reinstala. Uma tarefa agendada que baixa e executa código é o jeito mais comum de sobreviver à limpeza.

5. Rotacione o que vazou

Se houver qualquer indício de comprometimento, trate como vazado: senhas de todos os administradores, AUTH_KEY e demais salts do wp-config.php, senha do banco, chaves de API de gateway de pagamento, SMTP e integrações.

Trocar senha de admin e parar por aí é o erro clássico. O SQL injection lê o banco inteiro.

E se eu achar alguma coisa?

Ordem que funciona:

1. Tire um backup do estado comprometido antes de limpar. Ele é a sua evidência — e se a limpeza der errado, é o seu retorno.
2. Restaure a partir de backup anterior a 17 de julho de 2026, se você tiver um confiável. Limpeza manual de site com web shell de 150 KB é aposta ruim.
3. Reinstale o core, os plugins e os temas a partir da fonte oficial em vez de "remover o arquivo estranho".
4. Só então rotacione as credenciais — se rotacionar antes de expulsar o intruso, você entrega as novas.

Se o site chegou a servir spam ou redirecionar visitante, veja também como saber se meu site foi hackeado: tem a parte de blocklist do Google, que costuma ser o que dói no faturamento.

Onde o Sentinela entra

Vou separar em duas listas, porque a segunda importa tanto quanto a primeira.

O que a gente enxerga (de fora, sem plugin, sem acesso ao seu servidor)

• Versão do core exposta em meta generator, readme.html e ?ver= dos assets — e o cruzamento automático dessa versão com o banco de CVEs do WordPress, sincronizado diariamente do feed da Wordfence Intelligence.
• Versão desatualizada com a diferença explícita: "detectado 6.9.2, atual 7.0.2".
• O endpoint /wp-json/batch/v1 — a superfície exata do CVE-2026-63030. A gente registra como informativo (está ligado por padrão desde o WP 5.6, então não é anomalia por si só) e ele entra no inventário. Quando um CVE atinge essa rota, saber quem a expõe deixa de ser curiosidade.
• /wp-json/wp/v2/users aberto e /?author=1 revelando login — o mesmo enumerar de usuários que a campanha usou pra colher credenciais.
• Sintoma de comprometimento na página: JavaScript ofuscado, iframe externo injetado, spam escondido, redirecionamento e cloaking (a probe pede a home duas vezes, uma delas como Googlebot, e compara — é assim que se pega o site que só mostra spam pro buscador).
• wp-content/debug.log, wp-admin/install.php e listagem de diretório em uploads/ acessíveis.
• Diferença entre auditorias: o que mudou de uma varredura pra outra, incluindo plugin que apareceu do nada.

O que a gente não enxerga

O Sentinela é observador externo. Ele não instala plugin, não pede FTP e não entra no seu wp-admin. Consequência direta:

• Ele não vê a conta de administrador criada dentro do WordPress. Nenhuma ferramenta que olha de fora vê. Os passos 2, 3 e 4 do checklist acima são manuais mesmo — não existe atalho honesto.
• Ele não lê arquivos do servidor, então o .php plantado em uploads/ só aparece se estiver linkado ou se o diretório permitir listagem.
• Ele detecta o resultado de um comprometimento (spam, redirect, cloaking), não o arquivo PHP em si.

Quem promete "detectamos qualquer backdoor" olhando só de fora está vendendo o que não tem.

O que fica de lição

Três coisas:

A superfície mínima ainda é a defesa mais barata. Versão escondida, enumeração de usuário fechada, .php bloqueado em uploads/ — nada disso impede o wp2shell, mas encarece cada etapa seguinte do atacante. O checklist de WordPress seguro tem os dez itens.

Auto-update ligado deixou de ser opcional. A atualização forçada do WordPress.org foi o que segurou o número de vítimas. Se a sua justificativa pra travar versão é "quebra o tema", o custo dessa decisão acabou de ficar visível.

Saber a versão de cada site, hoje, vale mais que qualquer relatório trimestral. Quem tinha inventário respondeu "estes 6 dos 40" em minutos. Quem não tinha passou o fim de semana abrindo painel por painel.

Se você quer ver o que um visitante anônimo consegue descobrir do seu WordPress agora — versão, plugins, endpoints abertos, CVEs correspondentes — coloque o domínio aqui. A conta Free é grátis pra sempre e o primeiro relatório sai em cerca de 10 minutos.

Fontes

• WordPress wp2shell Exploitation Grows as Public Exploit Fuels Mass Scanning — The Hacker News
• Exploitation in the Wild of wp2shell — Wiz
• wp2shell: WordPress Core Pre-Auth RCE FAQ — Tenable
• WP2Shell Vulnerabilities: CVE-2026-60137 and CVE-2026-63030 — VulnCheck
• Hackers are exploiting recently patched WordPress bugs — TechCrunch