wp2shell WordPress RCE: Como Corrigir e Verificar Backdoors
Em 17 de julho de 2026, o WordPress lançou versões de emergência em todas as ramificações suportadas do core. Dentro de dias, apenas uma rede de honeypot registrou dezenas de milhares de tentativas de exploração e mais de uma centena de contas admin de backdoor plantadas em sites comprometidos.
A vulnerabilidade é chamada wp2shell: dois bugs encadeados no WordPress core, sem plugins envolvidos, que permitem a um visitante anônimo executar código em uma instalação padrão. Se você está no WordPress 6.9.0 até 7.0.1 sem 7.0.2 ou 6.9.5 aplicado, esta é a tarefa mais urgente de hoje.
O que é wp2shell, exatamente?
wp2shell é o nome que pesquisadores deram a uma cadeia de exploração combinando CVE-2026-63030 e CVE-2026-60137, dois bugs rastreados separadamente no WordPress core que juntos atingem execução remota de código não autenticada. Nenhum bug sozinho é um comprometimento completo.
Mas quando encadeados, eles são um problema.
O primeiro bug vive no endpoint em lote da REST API, a rota que permite que uma solicitação HTTP agrupe várias sub-solicitações juntas. Um erro de análise lá confunde um contador interno, então uma sub-solicitação posterior acaba sendo executada sob o manipulador errado com verificações de permissão mais frouxas do que deveria ter.
Esse desajuste atinge o segundo bug: um parâmetro em WP_Query, a classe que constrói a maioria das consultas de banco de dados do WordPress, que pula sua própria sanitização quando recebe uma string em vez do array que espera. Encadeie os dois e uma solicitação anônima injeta SQL e executa PHP no servidor.
Isso fica inteiramente no WordPress core. Não é um plugin, nem um tema, nem mesmo um construtor de páginas. Agora, uma instalação padrão, com zero plugins e zero configuração personalizada, é totalmente explorável.
Os intervalos afetados dividem-se por ramificação:
- WordPress 6.8.0 a 6.8.5: apenas a SQL injection, corrigida em 6.8.6
- WordPress 6.9.0 a 6.9.4: a cadeia completa, corrigida em 6.9.5
- WordPress 7.0.0 a 7.0.1: a cadeia completa, corrigida em 7.0.2
- WordPress 7.1 beta2: ambas as correções já incluídas
Versões anteriores ao 6.8 não são expostas a nenhum dos dois bugs.
O quão perigoso isto é depende de qual registro você verificar. O próprio advisory do WordPress chama a cadeia de crítica, enquanto os rastreadores de CVE públicos discordam entre si, alguns listando 7.5, outros pontuando a injeção acima de 9. O fato é: execução de código não autenticado no core com um exploit público funcionando não precisa de uma pontuação CVSS para justificar urgência.
Como você corrige isto
Atualize para WordPress 7.0.2, 6.9.5 ou 6.8.6, conforme a ramificação em que você está, hoje. Essa ação única fecha ambas as vulnerabilidades e remove a necessidade de qualquer workaround abaixo.
Verifique sua versão no wp-admin em Dashboard, depois Updates, ou execute wp core version via WP-CLI. Ver 6.9.0 até 6.9.4 ou 7.0.0 até 7.0.1 significa que você está exposto à cadeia completa agora.
O WordPress empurrou essa correção através do seu mecanismo de auto-atualização forçada, o que geralmente significa que sites afetados se atualizam sozinhos dentro de horas mesmo com auto-atualizações regulares desligadas. Não assuma que chegou a todos os sites pelos quais você é responsável. Hosts que desabilitam auto-atualizações de core, ou plugins de segurança bloqueando conexões de saída para os servidores de atualização do WordPress, não terão recebido. Você precisa fazer login e verificar cada um.
Pule a disciplina de staging-first que normalmente recomendo para atualizações rotineiras, pelo menos para essa. Esse fluxo de trabalho existe para pegar conflitos de plugin antes que atinjam a produção. Um RCE não autenticado com um exploit público funcionando muda a matemática: corrija a produção imediatamente e depois verifique se nada quebrou, em vez do contrário.
Gerenciando vários sites de clientes e não consegue corrigir todos em uma hora? Priorize sites voltados para a internet com uso público de REST primeiro, ambientes de staging protegidos por senha por último.
Se você não conseguir corrigir imediatamente
Se a correção tiver que aguardar algumas horas porque você está esperando suporte de hospedagem ou precisa testar uma integração WooCommerce primeiro, existem paliativos. Nenhum deles substitui a atualização.
Em seu WAF ou proxy reverso, bloqueie solicitações para /wp-json/batch/v1 e o equivalente de query-string, ?rest_route=/batch/v1. Bloquear apenas um deixa a porta aberta através do outro. Se seu site fica atrás do Cloudflare, confirme se o ruleset gerenciado cobrindo essa cadeia está ativo. O conjunto de regras da Wordfence cobre o mesmo padrão, se é isso que você já está executando.
Desabilitar a REST API do WordPress inteiramente, através de um plugin como Disable WP REST API, bloqueia a rota vulnerável juntamente com tudo mais que depende de REST: o editor de blocos, senhas de aplicação, o aplicativo móvel e a maioria dos plugins construídos após 2018, então trate como um freio de emergência por algumas horas.
Isso é especialmente verdadeiro para uma loja WooCommerce, onde renovações de assinatura e webhooks de gateway de pagamento dependem dessa mesma superfície de API. Já escrevi antes sobre o que acontece quando essa superfície se comporta mal por motivos completamente não relacionados.
Como verificar se você já foi atingido
Antes de tratar uma correção bem-sucedida como o fim da história, verifique se um invasor chegou lá primeiro. Código de exploit público circulou desde 18 de julho, e a varredura em massa começou dentro de dias.
Comece com wp-content/mu-plugins/. Plugins de uso obrigatório carregam automaticamente e nunca aparecem na tela de Plugins no wp-admin, tornando essa pasta um ponto de queda favorito para um backdoor que cria sua própria conta admin. Se você ver um arquivo lá que não colocou, capture uma screenshot e puxe logs de servidor ao redor do horário de criação antes de tocar em qualquer coisa.
Se você tem WP-CLI, execute:
wp core verify-checksums
Qualquer linha relatando um arquivo que não verifica contra checksum é um arquivo que difere da versão oficial do WordPress, e vale a pena abrir imediatamente.
Então verifique o tipo de código que um webshell tipicamente esconde:
grep -RilE "eval\(|base64_decode\(|shell_exec\(|passthru\(|assert\(" \
wp-content/uploads wp-content/plugins
Um resultado não significa automaticamente comprometimento, já que alguns plugins legítimos usam codificação base64 por motivos ordinários, mas é uma lista que vale a pena ler linha por linha.
Finalmente, verifique Users no wp-admin para qualquer conta de administrador que você não reconheça, e procure em wp-content/plugins por uma pasta que você não instalou, especialmente uma que imita o nome de uma ferramenta de segurança. Campanhas relatadas disfarçaram um painel de ataque completo como um plugin de scanner de segurança legítimo.
Por que manter o WordPress atualizado não é opcional
WordPress alimenta uma grande parte da web, e ferramentas de varredura automatizadas não distinguem um blog de hobby de uma loja de comércio eletrônico corporativo. Eles fazem varredura de intervalos de endereços, não julgamentos. Uma vulnerabilidade de core com um proof of concept público é investigada dentro de dias da divulgação, às vezes horas. wp2shell passou de divulgação para código de exploit público para exploração observada em aproximadamente 48 horas.
O detalhe desconfortável: o endpoint REST em lote foi enviado desde a versão 5.6 em 2020, mas o bug de confusão de rota apenas entrou no core com a versão 6.9 em dezembro de 2025. Todo site exposto à cadeia completa estava executando uma versão com menos de oito meses.
Manter-se atual ainda é o que fecha isto mais rápido, porque a correção vai para o mesmo número de versão que você já deveria estar executando. Já indiquei como um cadência de atualização real parece para a camada de plugin e tema. As versões de segurança do core merecem a mesma disciplina, apenas em um relógio muito mais rápido.
Como um stack de segurança WordPress realmente endurecido se parece
Corrigir wp2shell fecha uma porta específica. Uma instalação WordPress tem várias outras, e a maioria dos comprometimentos vêm através de configuração em vez de um zero-day.
Comece no nível da aplicação. O firewall da Wordfence é executado ao nível do WordPress e captura padrões de ataque como este mesmo antes de um patch de core existir, já que funciona fora do comportamento da solicitação em vez de números de versão. Execute junto com o WAF do Cloudflare: a camada CDN interrompe lixo óbvio antes de chegar ao seu servidor, e a camada de aplicação captura o que é específico para WordPress.
Imponha autenticação de dois fatores em todas as contas com acesso de publicação ou administrador. Wordfence e WP 2FA lidam com isto sem muita configuração.
No nível de arquivo, adicione define('DISALLOW_FILE_EDIT', true); a wp-config.php. Isto remove o editor de plugin e tema do wp-admin, uma maneira a menos para uma sessão admin roubada soltar código através do dashboard. Bloqueie wp-config.php você mesmo para permissões 440 ou 400 onde seu host permite, já que esse arquivo contém credenciais de banco de dados em texto simples.
No lado do banco de dados, o usuário WordPress com o qual seu site se conecta raramente precisa de privilégio FILE, e removê-lo fecha uma categoria inteira de cadeia SQL-injection-to-code-execution, incluindo o mecanismo que essa vulnerabilidade usou. Peça ao seu host ou DBA para verificar as permissões da conta.
Se você não está usando XML-RPC, e a maioria dos sites não está a menos que publique de um aplicativo móvel ou um serviço como IFTTT, desabilite no nível do servidor.
Mais uma coisa que vale a pena saber: sites executando um cache de objeto persistente, Redis ou Memcached, foram menos expostos à metade de execução de código dessa cadeia específica, de acordo com o próprio writeup do Cloudflare sobre o incidente. Isso é um efeito colateral da arquitetura de cache, não um recurso de segurança, então não o trate como um substituto para correção. Uma camada de cache apropriada pertence ao seu stack mesmo assim, por razões que não têm nada a ver com segurança.
Onde isto a deixa
Executando WordPress 6.9.0 até 7.0.1? Pare aqui e corrija para 7.0.2 ou 6.9.5 primeiro. No 6.8.x? Atualize para 6.8.6 pela correção de SQL injection, mesmo que nunca tenha sido exposto à metade de RCE. Já corrigido? Gaste vinte minutos verificando mu-plugins e executando um verify de checksum mesmo assim. Corrigido e limpo não são a mesma declaração.
wp2shell não será a última vulnerabilidade de core que transforma uma instalação padrão em uma responsabilidade da noite para o dia. Os sites que saem bem são aqueles onde atualizar é um hábito permanente, não uma tarefa que alguém se lembra durante um pânico.
Se você é responsável por sites WordPress de clientes e quer alguém verificando exatamente este tipo de coisa antes que se torne uma ligação às 2 da manhã, esse é o trabalho de manutenção e segurança que faço. Deixe uma mensagem.