Em 17 de julho de 2026, o WordPress soltou versões de emergência em todos os ramos do núcleo que ainda têm suporte. Em poucos dias, uma única rede de honeypots registrou dezenas de milhares de tentativas de exploração e mais de uma centena de contas de administrador plantadas como backdoor em sites comprometidos.
A vulnerabilidade se chama wp2shell: dois bugs encadeados no núcleo do WordPress, sem plugin nenhum envolvido, que deixam um visitante anônimo executar código numa instalação padrão. Se você está entre o WordPress 6.9.0 e o 7.0.1 sem a 7.0.2 ou a 6.9.5 aplicada, esta é a tarefa mais urgente do seu dia.
O que é o wp2shell, exatamente?
wp2shell é o nome que os pesquisadores deram a uma cadeia de exploração que junta o CVE-2026-63030 e o CVE-2026-60137, dois bugs registrados separadamente no núcleo do WordPress que, juntos, permitem execução remota de código sem autenticação. Nenhum dos dois, sozinho, compromete o site inteiro.
Encadeados, compromete.
O primeiro bug está no endpoint de lote da REST API, a rota que deixa uma requisição HTTP agrupar várias sub-requisições. Um erro de parsing ali confunde um contador interno, e uma sub-requisição posterior acaba rodando no handler errado, com verificações de permissão mais frouxas do que deveria.
Esse desencontro leva ao segundo bug: um parâmetro da WP_Query, a classe que monta a maioria das consultas ao banco do WordPress, que pula a própria sanitização quando recebe uma string em vez do array que espera. Junte os dois e uma requisição anônima injeta SQL e executa PHP no servidor.
Tudo isso fica no núcleo do WordPress. Não é plugin, não é tema, não é nem construtor de páginas. Uma instalação padrão, com zero plugins e zero personalização, pode ser explorada por inteiro.
As versões afetadas se dividem por ramo:
- WordPress 6.8.0 a 6.8.5: só a SQL injection, corrigida na 6.8.6
- WordPress 6.9.0 a 6.9.4: a cadeia completa, corrigida na 6.9.5
- WordPress 7.0.0 a 7.0.1: a cadeia completa, corrigida na 7.0.2
- WordPress 7.1 beta2: já traz as duas correções
Versões anteriores à 6.8 não estão expostas a nenhum dos dois bugs.
O tamanho do perigo depende de qual registro você consulta. O próprio comunicado do WordPress classifica a cadeia como crítica, e os rastreadores públicos de CVE discordam entre si: uns dão 7.5, outros põem a injeção acima de 9. O fato é que execução de código sem autenticação no núcleo, com exploit público funcionando, não precisa de nota CVSS nenhuma pra justificar urgência.
Como corrigir
Atualize hoje pra 7.0.2, 6.9.5 ou 6.8.6, conforme o ramo em que você está. Essa única ação fecha as duas vulnerabilidades e dispensa todos os paliativos abaixo.
Confira a versão no wp-admin, em Painel e depois Atualizações, ou rode wp core version no WP-CLI. Se aparecer algo entre 6.9.0 e 6.9.4 ou entre 7.0.0 e 7.0.1, você está exposto à cadeia completa agora.
O WordPress empurrou essa correção pelo mecanismo de atualização automática forçada, o que normalmente faz os sites afetados se atualizarem sozinhos em poucas horas, mesmo com as atualizações automáticas comuns desligadas. Não parta do princípio de que chegou em todos os sites pelos quais você responde. Hospedagem que desativa atualização automática do núcleo, ou plugin de segurança que bloqueia conexões de saída pros servidores de atualização do WordPress, não recebeu. Você precisa entrar em cada um e conferir.
Desta vez, pule a disciplina de testar em staging primeiro, que eu normalmente recomendo pras atualizações de rotina. Esse fluxo existe pra pegar conflito de plugin antes que chegue na produção. Um RCE sem autenticação com exploit público funcionando muda a conta: corrija a produção na hora e confira depois se nada quebrou, e não o contrário.
Cuida de vários sites de clientes e não consegue corrigir todos em uma hora? Comece pelos sites abertos na internet que usam a REST pública e deixe por último os ambientes de staging protegidos por senha.
Se você não consegue corrigir agora
Se a correção precisa esperar umas horas, porque você depende do suporte da hospedagem ou precisa testar uma integração com WooCommerce antes, existem paliativos. Nenhum substitui a atualização.
No seu WAF ou proxy reverso, bloqueie as requisições pra /wp-json/batch/v1 e pro equivalente em query string, ?rest_route=/batch/v1. Bloquear só um deixa a porta aberta pelo outro. Se o site está atrás do Cloudflare, confirme que o conjunto de regras gerenciadas que cobre essa cadeia está ativo. O conjunto de regras do Wordfence cobre o mesmo padrão, se é isso que você já usa.
Desativar a REST API inteira, com um plugin como o Disable WP REST API, bloqueia a rota vulnerável junto com tudo o que depende da REST: o editor de blocos, as senhas de aplicação, o app de celular e a maioria dos plugins feitos depois de 2018. Então trate isso como freio de emergência por algumas horas.
Vale ainda mais numa loja WooCommerce, onde as renovações de assinatura e os webhooks dos gateways de pagamento dependem dessa mesma API. Já escrevi sobre o que acontece quando essa camada se comporta mal por motivos que não têm nada a ver com isso.
Como saber se você já foi atingido
Antes de dar a história por encerrada só porque a atualização deu certo, confira se um atacante não chegou antes. Código de exploit público circula desde 18 de julho, e a varredura em massa começou em poucos dias.
Comece pelo wp-content/mu-plugins/. Plugins de uso obrigatório carregam sozinhos e nunca aparecem na tela de Plugins do wp-admin, o que faz dessa pasta o lugar preferido pra largar um backdoor que cria a própria conta de administrador. Se tiver ali um arquivo que você não colocou, tire um print e puxe os logs do servidor em volta do horário de criação antes de mexer em qualquer coisa.
Se você tem WP-CLI, rode:
wp core verify-checksums
Toda linha acusando um arquivo que não bate com o checksum é um arquivo diferente da versão oficial do WordPress, e merece ser aberto na hora.
Depois procure o tipo de código que um webshell costuma esconder:
grep -RilE "eval\(|base64_decode\(|shell_exec\(|passthru\(|assert\(" \
wp-content/uploads wp-content/plugins
Resultado aqui não quer dizer comprometimento automático, já que alguns plugins legítimos usam base64 por motivos banais, mas é uma lista pra ler linha por linha.
Por fim, abra Usuários no wp-admin atrás de qualquer administrador que você não reconheça, e procure em wp-content/plugins uma pasta que você não instalou, principalmente uma com nome parecido com ferramenta de segurança. Houve campanhas que disfarçaram um painel de ataque completo como plugin legítimo de varredura de segurança.
Por que manter o WordPress atualizado não é opcional
O WordPress roda uma fatia enorme da web, e ferramenta automatizada de varredura não diferencia blog de hobby de loja corporativa. Ela varre faixas de endereço, não faz julgamento. Uma vulnerabilidade de núcleo com prova de conceito pública é sondada dias depois da divulgação, às vezes horas. O wp2shell foi da divulgação ao exploit público e à exploração observada em umas 48 horas.
O detalhe incômodo: o endpoint REST de lote existe desde a 5.6, em 2020, mas o bug de confusão de rota só entrou no núcleo com a 6.9, em dezembro de 2025. Todo site exposto à cadeia completa rodava uma versão com menos de oito meses.
Manter-se atualizado ainda é o que fecha isso mais rápido, porque a correção sai no mesmo número de versão que você já deveria estar rodando. Já mostrei como é um ritmo de atualização de verdade pra camada de plugins e temas. As versões de segurança do núcleo merecem a mesma disciplina, só que num relógio bem mais rápido.
Como é uma pilha de segurança WordPress bem blindada
Corrigir o wp2shell fecha uma porta específica. Uma instalação WordPress tem várias outras, e a maioria das invasões entra por configuração, e não por zero-day. É por isso que segurança e manutenção WordPress é trabalho contínuo.
Comece pela aplicação. O firewall do Wordfence roda no nível do WordPress e pega padrões de ataque como este antes mesmo de existir um patch no núcleo, porque olha o comportamento da requisição, e não o número da versão. Use junto com o WAF do Cloudflare: a camada da CDN barra o lixo óbvio antes de chegar ao seu servidor, e a camada da aplicação pega o que é específico de WordPress.
Exija autenticação em dois fatores em toda conta com acesso de publicação ou de administrador. O Wordfence e o WP 2FA fazem isso sem muita configuração.
Nos arquivos, coloque define('DISALLOW_FILE_EDIT', true); no wp-config.php. Isso tira do wp-admin o editor de plugins e temas, um caminho a menos pra uma sessão de administrador roubada largar código pelo painel. Tranque o próprio wp-config.php com permissão 440 ou 400, onde a hospedagem deixar, porque esse arquivo guarda as credenciais do banco em texto puro.
No banco, o usuário com que o WordPress se conecta raramente precisa do privilégio FILE, e tirar esse privilégio fecha uma categoria inteira de cadeias que vão de SQL injection a execução de código, inclusive o mecanismo que essa vulnerabilidade usou. Peça pra hospedagem ou pro seu DBA conferir as permissões da conta.
Se você não usa XML-RPC (e a maioria dos sites não usa, a não ser que publique por app de celular ou por um serviço como o IFTTT), desative no servidor.
Mais uma coisa: sites com cache de objeto persistente, Redis ou Memcached, ficaram menos expostos à metade de execução de código dessa cadeia, segundo o próprio relato do Cloudflare sobre o incidente. Isso é efeito colateral da arquitetura de cache, e não recurso de segurança, então não trate como substituto da correção. Uma camada de cache bem montada merece estar na sua pilha de qualquer jeito, por motivos que não têm nada a ver com segurança.
Onde isso te deixa
Está rodando WordPress entre 6.9.0 e 7.0.1? Pare aqui e atualize pra 7.0.2 ou 6.9.5 primeiro. Está na 6.8.x? Atualize pra 6.8.6 pela correção da SQL injection, mesmo que nunca tenha estado exposto à metade do RCE. Já atualizou? Gaste vinte minutos olhando os mu-plugins e rodando a verificação de checksum mesmo assim. Atualizado e limpo não são a mesma coisa.
O wp2shell não vai ser a última vulnerabilidade de núcleo a transformar uma instalação padrão num risco da noite pro dia. Quem sai bem são os sites onde atualizar é hábito, e não uma tarefa que alguém lembra no meio do pânico.
Se você responde por sites WordPress de clientes e quer alguém conferindo isso antes que vire emergência de madrugada, isso é trabalho contínuo de segurança em WordPress. Me manda uma mensagem.