Um pesquisador de segurança, quatro agentes de IA e US$ 25 em créditos de API

Enquanto a maioria dos devs usava o GPT-5.6 Sol Ultra pra gerar boilerplate e refatorar código legado na semana passada, Adam Kues, pesquisador da Assetnote (braço de segurança ofensiva da Searchlight Cyber), resolveu fazer algo diferente: apontou quatro agentes de IA para o código-fonte do WordPress e foi dormir. Dez horas depois, o modelo tinha encontrado uma cadeia de exploits que permite execução remota de código sem autenticação em qualquer instalação WordPress 6.9 ou 7.0. O custo total? Vinte e cinco dólares.

Para ter uma noção da gravidade: brokers de exploits no mercado cinza pagam até US$ 500 mil por uma RCE no WordPress. Kues gastou o equivalente a um almoço executivo em São Paulo.

O que é o wp2shell e por que você deveria se preocupar agora

O wp2shell não é uma vulnerabilidade. São duas, encadeadas de um jeito que nenhum scanner automatizado iria pegar sozinho.

A primeira, rastreada como CVE-2026-63030, é uma confusão de rotas na Batch API do WordPress REST. Essa API existe desde o WordPress 5.6 (lançado em 2020) e permite agrupar múltiplas chamadas REST em uma única requisição HTTP. O problema? Quando você envia chamadas batch recursivas com uma estrutura específica, o WordPress perde o controle de qual handler pertence a qual subrequest. O contexto de processamento “desliza”, e de repente sua requisição anônima está sendo tratada como se tivesse privilégios que não tem.

A segunda, CVE-2026-60137, é uma SQL injection clássica no parâmetro author__not_in do WP_Query. Esse bug foi reportado separadamente por três pesquisadores (TF1T, dtro e haongo), e sozinho já seria grave. Mas combinado com a confusão de rotas da Batch API, vira uma arma completa.

A cadeia funciona assim:

1. O atacante envia uma requisição POST para /wp-json/batch/v1 sem autenticação
2. Dentro do batch, chamadas recursivas exploram a confusão de rotas (CVE-2026-63030)
3. Uma subrequest acaba associada ao contexto de um handler privilegiado
4. Com esse contexto elevado, o payload de SQL injection (CVE-2026-60137) atinge o WP_Query
5. A injeção SQL manipula dados internos para escalar até execução de código arbitrário

O resultado: de requisição anônima a shell no servidor, sem precisar de nenhuma credencial.

Quem é afetado (e quem já está sendo atacado)

A cadeia completa de RCE afeta:

Um detalhe importante: o WordPress 6.8 tem a SQL injection (CVE-2026-60137), mas não tem o bug da Batch API que foi introduzido no 6.9. Então quem ainda está no 6.8 não pode ser atingido pela cadeia completa, só pela injeção SQL isolada. Ainda assim, atualize.

A comunidade já confirmou exploração ativa. No Hacker News, um desenvolvedor relatou: “Eu vi um ataque contra um dos nossos sites neste fim de semana usando esse exploit.” O exploit público já está disponível no GitHub (repositório NULL200OK/WP2Shell), o que significa que qualquer script kiddie com acesso a um terminal pode tentar.

O WordPress reagiu rápido dessa vez: forçou auto-updates para as versões corrigidas (7.0.2, 6.9.5, 6.8.6) em vez de esperar que administradores atualizassem manualmente. Se o seu site tem auto-update habilitado, provavelmente já está seguro. Se não tem, pare de ler e vá atualizar.

Como o GPT-5.6 encontrou isso em 10 horas

Aqui é onde a história fica realmente interessante pra quem trabalha com segurança ou com IA.

Kues não simplesmente jogou o código do WordPress numa janela de chat e perguntou “tem bug aqui?”. Ele configurou quatro agentes de IA rodando em paralelo, cada um com uma tarefa específica de auditoria. O GPT-5.6 Sol Ultra (modelo da OpenAI com capacidade estendida de raciocínio) analisou o código-fonte do WordPress sistematicamente, seguindo fluxos de dados desde os endpoints públicos até as queries no banco.

O tempo total de processamento foi pouco mais de 10 horas. O custo em tokens de API ficou em torno de US$ 25, o que equivale a mais ou menos meia semana de uso num plano de US$ 200/mês.

Kues foi direto sobre o assunto: disse que podia afirmar “com total confiança que nenhum pesquisador de segurança conseguiria encontrar e completar essa cadeia de exploits em 10 horas sem IA.”

E ele provavelmente tem razão. A cadeia do wp2shell não é um buffer overflow óbvio ou uma injeção SQL exposta numa query GET. É uma combinação de dois bugs em subsistemas diferentes do WordPress, onde o primeiro cria uma condição de confusão de contexto que torna o segundo explorável. O tipo de coisa que um humano levaria semanas de auditoria manual pra conectar, se conectasse.

O que os agentes fizeram de diferente

O que chama atenção na metodologia é a criatividade que o modelo demonstrou na construção do exploit:

• Chamadas batch recursivas para contornar restrições de método GET
• Abuso de cache para aplicar um changeset e temporariamente escalar privilégios para administrador
• Criação de um post falso que aciona o hook parse_request para reprocessar a requisição com o papel elevado

Isso não é “achei uma variável sem sanitização”. É engenharia de exploits com múltiplas etapas criativas. E foi uma IA que montou.

A discussão que a comunidade dev não está tendo (mas deveria)

Quando o artigo caiu no Hacker News com 302 pontos, a reação da comunidade foi previsível: metade aplaudiu, metade desconfiou.

Os céticos levantaram pontos válidos. Primeiro: não existe evidência de que US$ 500 mil realmente tenham sido pagos por um exploit WordPress. Kues trabalha para a Assetnote, que vende serviços de segurança, então existe um incentivo comercial em inflar o valor da descoberta. Segundo: o custo de US$ 25 é enganoso, porque ignora todo o conhecimento especializado necessário para configurar os agentes, definir os prompts certos e validar os resultados. Como um dev colocou: “Com US$ 25 mais todo o seu conhecimento específico de domínio… vamos parar com a narrativa de apostas.”

Mas o argumento inverso é igualmente forte. Mesmo que o valor de US$ 500 mil seja inflado e o custo real seja US$ 25 mais experiência humana, o fato permanece: um modelo de linguagem encontrou uma cadeia de exploits multi-etapa em código real, em produção, que afeta mais de 40% dos sites da internet. Isso não é um CTF. Não é um benchmark sintético. É o WordPress.

O que isso muda pra segurança

A implicação óbvia é que qualquer pessoa com acesso a um modelo frontier e conhecimento básico de segurança agora pode auditar codebases massivas em horas. Isso vale pros dois lados: defensores podem escanear seus próprios sistemas muito mais rápido, e atacantes também.

A implicação menos óbvia é que o modelo de negócio dos exploit brokers pode estar prestes a colapsar. Se encontrar vulnerabilidades graves custa US$ 25 em vez de semanas de trabalho especializado, a oferta de exploits vai explodir e os preços vão cair. Irônico: a IA pode tornar a segurança mais barata tanto pra quem defende quanto pra quem ataca.

WordPress em 2026: o elefante na sala

A discussão no Hacker News rapidamente escalou pra uma crítica mais ampla da arquitetura do WordPress. E com razão.

O WordPress ainda usa concatenação de strings pra construir queries SQL em vários lugares. O famigerado dbDelta(), função interna que gerencia o schema do banco, tem o que um dev chamou de “dez requisitos implacáveis de formatação” pra funcionar corretamente. Padrões de PHP dos anos 2000 convivem com APIs REST modernas num Frankenstein de código que alimenta 43% da web.

// Exemplo simplificado do padrão problemático no WP_Query
// (não é o código vulnerável exato, mas ilustra o problema)
$where .= " AND {$wpdb->posts}.post_author NOT IN ("
         . implode(',', array_map('absint', $author__not_in))
         . ')';
// Se absint() não sanitizar corretamente em certos contextos...

O wp2shell é sintomático. Não é um bug de um plugin obscuro feito por um dev júnior num fim de semana. É no core. Na API REST que o próprio WordPress promove como a forma moderna de interagir com a plataforma. E levou uma IA pra encontrar uma cadeia que estava escondida desde 2020.

Eu já vi projetos migrarem do WordPress pra headless CMS, Astro, Next.js ou Hugo por motivos de performance. O wp2shell pode ser o empurrão que faltava pra quem estava em cima do muro por motivos de segurança.

Como verificar se o seu site está vulnerável

Antes de entrar em pânico, alguns passos práticos:

1. Verifique sua versão do WordPress

curl -s https://seusite.com/wp-json/ | jq '.description, .namespaces'
# Ou no painel: Dashboard > Updates

2. Force a atualização se necessário

# Via WP-CLI (se disponível)
wp core update
wp core verify-checksums

# Ou via painel admin
# Dashboard > Updates > Atualizar agora

3. Verifique os logs de acesso

Procure por requisições suspeitas para /wp-json/batch/v1:

grep "batch/v1" /var/log/nginx/access.log | grep POST | tail -20
# Ou para Apache:
grep "batch/v1" /var/log/apache2/access.log | grep POST | tail -20

Se encontrar requisições POST para a Batch API com payloads grandes vindos de IPs desconhecidos, investigue.

4. Considere desabilitar a Batch API temporariamente

Se por algum motivo não pode atualizar imediatamente:

// No functions.php ou mu-plugin
add_filter('rest_pre_dispatch', function($result, $server, $request) {
    if (strpos($request->get_route(), '/batch/v1') !== false) {
        return new WP_Error(
            'batch_disabled',
            'Batch API temporariamente desabilitada',
            ['status' => 403]
        );
    }
    return $result;
}, 10, 3);

Isso vai quebrar qualquer coisa que dependa da Batch API (Gutenberg em algumas configs, plugins de performance), mas é melhor que ter um shell no servidor.

Números que colocam o wp2shell em perspectiva

Pra entender o tamanho do problema, vale olhar os dados frios:

O WordPress tem um histórico de vulnerabilidades graves, mas a maioria acontece em plugins (lembra do exploit no Elementor em 2023? Ou o do WPForms em 2024?). Vulnerabilidades no core são raras, e RCEs sem autenticação no core são praticamente unicórnios. A última de gravidade comparável foi a REST API content injection de 2017 (CVE-2017-1001000), que permitia alterar o conteúdo de qualquer post sem autenticação.

O que torna o wp2shell diferente é que ele vai além de alterar conteúdo. Dá shell. Controle total do servidor. Em 2017, o atacante podia pichar seu site. Em 2026, ele pode usar seu servidor pra minerar crypto, hospedar phishing, ou pivotar pra sua rede interna.

O futuro da auditoria de código com IA

O wp2shell não é o primeiro bug encontrado por IA, e definitivamente não vai ser o último. Mas marca um ponto de inflexão por alguns motivos:

Primeiro, a relação custo/impacto é absurda. US$ 25 para encontrar uma vulnerabilidade crítica num software usado por quase metade da internet. Segundo, a complexidade da cadeia de exploits vai além de pattern matching. O modelo demonstrou raciocínio criativo ao combinar bugs de subsistemas diferentes. Terceiro, o tempo: 10 horas. Uma auditoria humana equivalente levaria semanas, se chegasse ao mesmo resultado.

Pra quem trabalha com segurança ofensiva, a mensagem é clara: se você não está usando LLMs na sua pipeline de pesquisa, está competindo com um braço amarrado. Pra quem trabalha com segurança defensiva, a mensagem é igualmente clara: seus adversários já estão usando.

E pra quem mantém um site WordPress? Vai lá e atualiza. Sério. Agora.

O wp2shell.com tem uma ferramenta de verificação se você quer um check rápido. Mas nada substitui estar na versão mais recente com auto-updates ligados.

Fonte de inspiração: Exploit brokers pay $500,000 for a WordPress RCE. I found one with GPT5.6 Sol Ultra and $25 (Searchlight Cyber)