wp2shell: falha crítica no núcleo do WordPress permite RCE sem autenticação em milhões de sites

Uma requisição HTTP anônima. É isso que basta para executar código no núcleo do WordPress a partir da falha “wp2shell”, que combina duas vulnerabilidades separadas — CVE-2026-63030 (confusão de roteamento na REST API batch) e CVE-2026-60137 (SQL injection no core) — em uma cadeia de exploração completa. Todo site rodando WordPress 6.9 ou 7.0 estava exposto até sexta-feira, quando a fundação lançou as versões 6.9.5 e 7.0.2 e ativou o mecanismo de atualização forçada. Um proof-of-concept funcional já circula publicamente no GitHub.

O que aconteceu

O pesquisador Adam Kues, da Assetnote — braço de gerenciamento de superfície de ataque da Searchlight Cyber —, descobriu o problema de roteamento no endpoint batch da REST API e reportou o caso ao time de segurança do WordPress via HackerOne. A correção foi lançada em regime de emergência: além dos patches 6.9.5 e 7.0.2, a fundação acionou o sistema de auto-update forçado, algo raramente usado, para reduzir a janela de exposição em sites que nunca aplicam atualizações manualmente.

Menos de 24 horas depois do release, outros pesquisadores fizeram engenharia reversa do patch, publicaram o mecanismo completo e disponibilizaram um exploit funcional no GitHub. Segundo o levantamento da The Hacker News, a Searchlight tentou segurar a divulgação técnica justamente para dar tempo aos administradores, mas a corrida foi perdida em questão de horas — cenário típico de vulnerabilidades em código aberto amplamente auditado.

Estimativas do próprio ecossistema WordPress indicam que centenas de milhões de sites usam a plataforma, mas o número exato de instalações vulneráveis é menor: a cadeia de RCE só funciona a partir da versão 6.9, lançada em 2 de dezembro de 2025. Ainda assim, o intervalo de risco cobre praticamente todo site que instalou atualizações nos últimos oito meses.

Detalhes da vulnerabilidade

A falha é composta por dois erros pequenos que, isolados, seriam pouco explorados. O primeiro está no parâmetro author__not_in do WP_Query: quando um atacante envia uma string em vez de um array, a checagem de tipo é ignorada e o valor bruto cai direto na consulta SQL. Esse é o vetor de SQL injection catalogado como CVE-2026-60137.

O segundo problema — CVE-2026-63030 — está no endpoint /wp-json/batch/v1, que permite executar várias sub-requisições em uma única chamada. O WordPress rastreia essas sub-requisições em dois arrays paralelos. Um erro proposital em uma delas desloca os arrays em uma posição, fazendo com que uma requisição execute sob o handler de outra. Aninhando as chamadas, o atacante contorna a allow-list do endpoint e alcança o parâmetro vulnerável sem autenticação.

“O endpoint batch existe desde a versão 5.6, mas a cadeia de RCE só funciona a partir da 6.9 — é onde o handler vulnerável passa a ser alcançável sem login.”

Uma condição adicional envolvendo cache de objetos persistente também foi revelada nas últimas horas, ampliando a superfície do ataque em ambientes que usam Redis ou Memcached como backend de cache — comuns em instalações corporativas e hosts gerenciados.

Quem é afetado

• Sites rodando WordPress 6.9.x e 7.0.x (todas as versões inferiores a 6.9.5 e 7.0.2)
• Instalações “bare” — sem plugins ou temas customizados — também são vulneráveis, já que o bug está no core
• Ambientes com cache de objetos persistente (Redis, Memcached) enfrentam risco adicional
• Sites em hospedagens que desabilitam auto-updates por padrão (VPS, servidores dedicados, algumas configurações WPMU)
• Multisite networks — o endpoint batch está exposto em toda a rede

Análise

Existe um padrão que se repete em cada disclosure de core WordPress: entre o release do patch e a publicação de um exploit funcional, a janela é de horas, não dias. Foi assim na cadeia object injection de 2023, foi assim no bug de REST API de 2017 que resultou em defacement massivo de mais de 1,5 milhão de páginas, e é assim agora com wp2shell. O código-fonte aberto e amplamente auditado torna qualquer patch um mapa detalhado do problema que ele corrige.

A diferença, desta vez, é o uso da atualização forçada. O WordPress raramente aciona esse mecanismo — historicamente, ficou reservado para incidentes de escala catastrófica. O fato de a fundação ter puxado o gatilho já na sexta-feira sugere que a avaliação interna considerou a exploração em massa iminente, não hipotética. Para efeito de comparação, o zero-day de SharePoint (CVE-2026-58644) reportado pela CISA esta semana levou dias entre disclosure e adição ao catálogo KEV. No caso do wp2shell, a janela foi comprimida ao extremo.

Para o mercado brasileiro, o alerta é particularmente relevante: o Brasil é um dos maiores usuários de WordPress da América Latina, com grande presença em pequenas e médias empresas, governos municipais e portais educacionais. Muitas dessas instalações rodam em hospedagens compartilhadas cuja política de atualização é opaca ou opt-out — exatamente o cenário em que o auto-update forçado precisa funcionar bem.

Recomendações práticas

• Confirme imediatamente que suas instalações estão em 6.9.5 ou 7.0.2 — não confie apenas na presença do auto-update ativado
• Monitore logs de acesso para requisições ao endpoint /wp-json/batch/v1, especialmente com payloads contendo author__not_in como string
• Se você opera atrás de um WAF (Cloudflare, Sucuri, Akamai), verifique se o fornecedor já publicou regras específicas para wp2shell
• Considere restringir o acesso ao endpoint batch por IP em ambientes onde ele não é usado — muitos sites não precisam dele exposto
• Rode um scanner de indicadores de comprometimento (IoC) — arquivos PHP suspeitos em wp-content/uploads, novos usuários administradores, cron jobs desconhecidos
• Reforce o monitoramento de outbound connections nos servidores WordPress — RCE típico se traduz em beaconing para C2 externos
• Para agências e prestadores que gerenciam múltiplos sites: audite o parque completo, não apenas o cliente que ligou primeiro

Fonte: The Hacker News