wp2shell: uma RCE em WordPress padrão, encontrada em dez horas por US$ 25

Em 17 de julho de 2026, a Searchlight Cyber publicou o wp2shell, uma cadeia de execução remota de código pré-autenticação no núcleo do WordPress que não exige plugin, tema nem login. Basta uma requisição anônima contra uma instalação padrão: "O ataque não tem pré-condições e pode ser explorado por um usuário anônimo em uma instalação padrão do WordPress sem plugins," declara o comunicado da empresa. A cadeia une duas vulnerabilidades — CVE-2026-63030, uma falha de confusão de rotas no endpoint de lote da API REST do WordPress que o comunicado do projeto classifica como crítica, e CVE-2026-60137, uma injeção de SQL no parâmetro author__not_in do WP_Query que ele classifica como moderada. O WordPress lançou a versão 7.0.2 no mesmo dia, e os comunicados do projeto listam WordPress 6.9.5, WordPress 6.8.6 e WordPress 7.1 beta2 como contendo as mesmas correções. A Searchlight cita estimativas de mais de 500 milhões de sites WordPress. O pesquisador por trás da cadeia, Adam Kues, diz que ela surgiu de uma execução do GPT-5.6 Sol Ultra construída a partir de um prompt que a OpenAI havia publicado para um problema de matemática: até quatro agentes, pelo menos seis horas na busca e cerca de quatro mais na escalação, aproximadamente US$ 25 em uso de modelo. O registro está arquivado como uma descoberta de pesquisa — severidade alta na escala do próprio arquivo, confiança grau A, nenhum dano no mundo real registrado, datado de um único dia — e o Orca AI Incident Archive o traz com os documentos primários vinculados abaixo.

A divulgação foi coordenada. A Searchlight não divulgou os detalhes de funcionamento em 17 de julho e deu aos defensores o fim de semana para atualizar; Kues publicou o relato técnico completo em 20 de julho. Até então, o exploit encadeado já havia sido reproduzido de forma independente: a Searchlight afirma que Calif e Hacktron reconstruíram a cadeia completa antes de outras provas de conceito surgirem no GitHub. Os dois avisos de segurança do próprio WordPress indicam as mesmas versões corrigidas, e a CISA adicionou ambas as CVEs ao seu catálogo Known Exploited Vulnerabilities em 21 de julho.

Dois bugs e os arrays que saem do compasso

O ponto de entrada é um recurso, e não um erro. O WordPress 5.6 introduziu o endpoint em lote em 2020 para que um cliente pudesse enviar várias solicitações REST virtuais dentro de uma única solicitação HTTP, por exemplo, para renomear um conjunto de posts de uma só vez. O endpoint é acessível independentemente de o chamador estar autenticado, e cada subsolicitação carrega qualquer autenticação fornecida pelo chamador. Uma solicitação direta a uma rota REST do WordPress executa um pipeline de quatro etapas: verificar os parâmetros obrigatórios e válidos, sanitizá-los, executar o callback de permissão e, em seguida, executar o callback do endpoint. Os endpoints dependem desse pipeline para suas suposições de tipo — que um ID de post seja um inteiro, que um título seja uma string.

A API de lote divide o pipeline em duas partes, validando cada subsolicitação em um laço e executando-as em um segundo, e mantém dois arrays, $matches e $validation, cujas entradas devem se alinhar índice por índice. Em class-wp-rest-server.php, como Kues descreve, uma subsolicitação que é ela mesma um erro do WordPress é anexada a $validation e então encontra um continue, pulando a linha que anexa a $matches. A partir desse ponto, cada correspondência é deslocada uma posição para trás. O laço de execução emparelha a subsolicitação em um índice com a validação registrada nesse índice, mas o handler associado a uma rota diferente — assim, um parâmetro é verificado de acordo com as regras de um endpoint e depois executado pelo código de outro.

É isso que transforma um parâmetro de lista aparentemente comum em injeção. A rota de coleção de posts mapeia seu argumento público author_exclude para author__not_in. Quando o valor é um array, o WordPress executa absint sobre cada elemento e os ordena; quando o valor é um escalar, ele é concatenado sem alteração no fragmento SQL que se torna NOT IN ($author__not_in). Uma string como 0) OR 1=1 -- portanto acaba no texto da consulta. Chamada normalmente, a rota a recusaria, porque author_exclude deve ser um array de inteiros; é a chamada em lote dessincronizada que deixa uma string passar.

Dois obstáculos permaneciam, e ambos foram resolvidos ao aninhar o truque. A API de lotes rejeita solicitações GET, e a injeção reside em uma rota GET; e a validação do método da solicitação é ela própria implementada como validação de parâmetros, que a mesma dessincronização pode contornar. O payload publicado por Kues envia uma subrequisição externa malformada para dessincronizar a verificação do método, depois um lote interno cuja segunda subrequisição carrega o malicioso author_exclude contra um manipulador que não o valida, e então o GET que o executa. Uma injeção baseada em UNION retorna valores arbitrários do banco de dados dentro de linhas com formato de posts comuns.

A execução do modelo: um prompt de matemática, apontado para uma base de código

Kues não escreveu o prompt do zero. A OpenAI havia publicado o prompt que usou enquanto trabalhava na conjectura Cycle Double Cover, e Kues escreveu que havia lido que o modelo tinha resolvido recentemente essa conjectura e que ninguém na comunidade de segurança parecia estar falando sobre o prompt. Seu raciocínio era que, se ele era bom o suficiente para matemática difícil, provavelmente era bom o suficiente para pesquisa em segurança. Ele o adaptou e o direcionou para o WordPress.

A configuração era deliberadamente restrita. Ele clonou a versão estável mais recente do WordPress para um diretório chamado main/ e apagou o seu diretório .git, dizendo ao modelo para não usar registos de alterações, histórico do Git ou a internet aberta para comparar o código com uma versão corrigida — a razão declarada por ele era que, para a descoberta de vulnerabilidades inéditas, consultar o histórico ou a web é um desperdício de tokens. Um diretório vazio third_party/ foi disponibilizado para que o modelo pudesse clonar dependências como o código-fonte de PHP ou MySQL, se considerasse que a cadeia precisava de falhas nas bibliotecas subjacentes ao WordPress. A tarefa foi especificada como RCE de pré-autenticação numa implementação de produção típica em MySQL, com até quatro agentes e pelo menos seis horas. Kues escreveu que declara explicitamente o requisito de configuração porque, de outro modo, os modelos "trapaceiam" — ao escolher opções de configuração extremamente improváveis ou ao inventar pré-condições que um atacante nunca conseguiria alcançar.

O que voltou, na saída em execução, foi a alegação de uma injeção SQL de pré-autenticação. Kues duvidou disso: o WordPress está entre os alvos mais intensamente auditados de todos os tempos, escreveu ele, e não tivera uma vulnerabilidade de pré-autenticação significativa naquela década. Ele instalou uma instância padrão do WordPress em um servidor remoto e pediu ao modelo que roubasse o e-mail do administrador; em poucos minutos, ele imprimiu o endereço que havia usado para configurar a instância. Ele então perguntou se a injeção somente leitura poderia ser escalada, e cerca de quatro horas depois o modelo respondeu que sim — para administrador, sem quebrar nenhuma senha e sem computação offline.

Seu próprio cálculo de custos: 50% de um limite semanal de uso, que ele estimou em cerca de US$ 25 proporcionalmente a uma assinatura de US$ 200, por um exploit produzido em pouco mais de dez horas. A parte humana não foi gratuita — Kues passou o dia seguinte destrinchando o que o modelo havia feito e escreveu que o trabalho de pós-exploração levou muito mais tempo para ele entender do que levara para ser gerado. Seu veredito é incomumente direto e estritamente delimitado: "Não faço afirmações gerais, mas posso dizer com total confiança que nenhum pesquisador de segurança teria conseguido encontrar e concluir esta cadeia de exploit em 10 horas sem IA."

De um SELECT somente leitura a administrador

A escalada é a parte do registro que mais importa, porque é onde uma leitura de banco de dados se tornou controle do servidor. O relato de Kues a descreve como uma sequência de seis movimentos, cada um usando um recurso comum do WordPress contra outro.

Primeiro, envenene o cache de posts em memória.O WordPress mantém um cache de objetos WP_Post por requisição, para que o mesmo post referenciado várias vezes em uma única requisição custe apenas uma ida e volta ao banco de dados. A injeção SQL pode fabricar posts, então o atacante controla exatamente o que é armazenado em cache — mas esses posts fabricados não são linhas no banco de dados, e o cache morre com a requisição.

Segundo, transforme posts fabricados em linhas reais. O recurso de embed do WordPress armazena em cache os embeds resolvidos no banco de dados como posts do tipo oembed_cache. Incorporar um post local por caminho relativo, como em [embed]/?p=S[/embed], faz com que o WordPress ignore a busca HTTP e nunca verifique se o post referenciado existe, de modo que uma linha é criada. Três desses embeds com tokens de query string diferentes produzem três hashes de cache diferentes, e é assim que o atacante consegue várias linhas para trabalhar.

Terceiro, contorne o único campo que permanece fixo.Quando as versões em memória e no banco de dados de um post divergem, o WordPress as reconcilia com uma chamada que define explicitamente post_content a partir da saída do embed. Tudo no post é controlado pelo atacante, exceto seu conteúdo, que é precisamente o campo que um customize_changeset usa para armazenar o JSON de alterações pendentes de tema e site.

Quarto, o gadget de ciclo.Os posts têm pais, e o WordPress recusa ciclos: o filtro wp_insert_post_parent percorre a árvore para cima e, ao encontrar um loop, chama uma atualização que define post_parent como zero. Essa chamada não sobrescreve post_content, então a versão fabricada em memória sobrevive à reconciliação — um changeset, com seu JSON intacto, respaldado por uma linha real.

Quinto, tome emprestada a autoridade do administrador. Um changeset cujo status indica que está agendado para o futuro, mas cuja data está no passado, é aplicado imediatamente. Cada entrada em seu JSON indica um user_id, e a entrada na cadeia de Kues indica user_id 1, o administrador, então o WordPress assume temporariamente essa identidade para aplicar a alteração. A primeira alteração é uma atualização aparentemente inofensiva em nav_menus_created_posts.

Sexto, reproduza a requisição com essa identidade. Publicar um post dispara uma ação com nome dinâmico, {status}_{post_type}. Como o post é fabricado, esse status e tipo podem ser qualquer coisa — inclusive parse e request, o que produz o parse_request hook e reinicia o pipeline de requisições desde o início enquanto a identidade de administrador emprestada ainda é válida. A requisição em lote original continha uma subrequisição que criava um novo administrador; ela falhou na primeira tentativa como visitante e tem êxito na reprodução. A partir daí, o atacante faz login com essa nova conta e envia um plugin backdoor de um arquivo ZIP, o que é execução de código.

A técnica tem uma condição atrelada. O Hacker News, citando a Cloudflare, informou que a CVE-2026-63030 só resulta em execução remota de código quando não há cache de objetos persistente em uso; a injeção em si está presente desde o WordPress 6.8, enquanto a cadeia completa exige 6.9 ou posterior. Uma instalação padrão não tem cache de objetos persistente, e é por isso que a formulação “sem pré-condições” da Searchlight e o qualificador da Cloudflare descrevem o mesmo caso padrão a partir de direções diferentes.

O que os documentos primários estabelecem

Os avisos de segurança do próprio WordPress são a corroboração mais forte, porque representam o fornecedor admitindo a mecânica e entregando a correção. GHSA-ff9f-jf42-662q, classificado como crítico, descreve uma fraqueza de confusão de rotas em lote da API REST no WordPress 6.9 e superior que se combina com a injeção para alcançar execução de código, e credita Adam Kues, da Assetnote e da Searchlight Cyber. GHSA-fpp7-x2x2-2mjf, classificado como moderado, descreve a injeção author__not_in a partir do WordPress 6.8 e superior, e afirma que ambos os problemas foram corrigidos em WordPress 7.0.2, WordPress 6.9.5, WordPress 6.8.6 e WordPress 7.1 beta2. Os registros do NVD para as duas CVEs, pontuados pelo WPScan CNA em vez do NIST, trazem 9,8 para CVE-2026-63030 com o vetor AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H, e 5,9 para CVE-2026-60137 com AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:N/A:N — uma falha alcançável pela rede e que não exige privilégios no primeiro caso, e uma que exige alta complexidade de ataque e resulta em impacto apenas na confidencialidade no segundo. O campo de severidade do próprio arquivo para esta entrada consta como alto, enquanto o WordPress classifica a falha em lote como crítica; as duas são escalas separadas aplicadas a uma cadeia inteira e a um único componente, não uma discordância sobre as falhas em si.

As entradas do catálogo da CISA, conforme refletidas nos campos de enriquecimento do NVD, foram adicionadas em 21 de julho de 2026, com prazos de correção de 24 de julho para CVE-2026-63030 e 4 de agosto para CVE-2026-60137. A CISA denomina a primeira “Vulnerabilidade de Conflito de Interpretação do WordPress Core” e a segunda “Vulnerabilidade de Injeção SQL do WordPress Core”. A Searchlight também publicou um verificador público em wp2shell.com para que os operadores pudessem testar uma instância sem esperar por uma assinatura de scanner.

A reprodução independente é documentada pela própria Searchlight e, portanto, é uma afirmação sobre terceiros, e não um relato de terceiros: Calif e Hacktron reconstruíram toda a cadeia antes que outras provas de conceito aparecessem no GitHub, segundo o artigo de 20 de julho. O que é verificável de forma independente é o efeito — provas de conceito, tráfego de exploração e telemetria de fornecedores em questão de dias, descritos abaixo.

O que é alegado, mas não estabelecido

Dois créditos para uma única injeção não se conciliam no registro público. O comunicado do WordPress para a CVE-2026-60137 declara que a falha foi "descoberta e divulgada de forma responsável em equipe por TF1T, dtro e haongo". O relato da Searchlight apresenta a mesma injeção de pré-autenticação que sua execução de modelo revelou, e não menciona essa equipe; o comunicado do WordPress atribui a Kues apenas a confusão da rota de lote, e não menciona um modelo. Nenhum dos documentos explica a sobreposição, e nada que esta matéria localizou resolve isso — a possibilidade de que as duas tenham sido descobertas independentes do mesmo bug não está excluída, e a possibilidade de que um relatório seja uma redescoberta posterior também não está estabelecida. O registro não adjudica a questão, e este artigo também não.

O número da manchete da publicação de 20 de julho da Searchlight não é sustentado pelo próprio texto. Ela diz: "Corretores de exploits pagam US$ 500.000 por uma RCE do WordPress. Encontrei uma com GPT5.6 Sol Ultra e US$ 25". O corpo do texto documenta os US$ 25 e as dez horas em termos específicos; não traz nomes de corretores, ofertas, correspondência nem fonte para o valor de US$ 500.000. Nenhum relatório independente localizado para este artigo corrobora um preço pago ou oferecido por wp2shell. Leia os US$ 500.000 como o enquadramento da manchete, e não como um preço de mercado estabelecido.

O âmbito da própria entrada do arquivo é mais estreito do que a história à sua volta. Regista um resultado de investigação no dia da divulgação, não assinala danos no mundo real e está datada de um único dia, 17 de julho de 2026. Isto não é afirmar que nada aconteceu depois: foi reportado tráfego de exploração nas horas seguintes ao aviso, e a CISA catalogou ambas as CVEs quatro dias depois. O sinal abrange o que a entrada descreve — a descoberta e a divulgação coordenada — e a exploração subsequente está documentada por outras partes, com base nas suas próprias evidências, abaixo.

Exploração após o aviso

Jake Knott, pesquisador principal de segurança da watchTowr, disse ao The Hacker News que "nas primeiras horas da manhã de sábado (UTC), a exploração bem-sucedida já estava bem avançada, inicialmente usando código de exploração público para exfiltrar credenciais com hash, seguida de execução remota de código assim que detalhes adicionais se tornaram públicos". O mesmo relatório cita telemetria da KEVIntel que liga 13 endereços IP exclusivos, da Suíça, Alemanha, Reino Unido, Indonésia, Lituânia, Países Baixos e Singapura, à exploração da CVE-2026-63030, e cita o fundador da KEVIntel, Ryan Dewhurst, dizendo que as solicitações correspondiam a provas de conceito disponíveis publicamente e que payloads cegos, baseados em UNION e baseados em boolean foram todos utilizados.

Os pesquisadores da Wiz, Shahar Dorfman e Gili Tikochinski, que publicaram em 20 de julho, quantificaram a escala do problema: 60% das organizações que usam WordPress tinham pelo menos uma instância vulnerável no momento em que as CVEs foram publicadas, e 25% estavam expondo um servidor vulnerável à internet, caindo para 50% e 10% em até 24 horas à medida que a aplicação de patches começou. Eles registraram uploads maliciosos de plugins pelo instalador do admin, enumeração de usuários contra o endpoint de usuários, tentativas de inclusão de arquivo local contra wp-config, e acesso ao painel administrativo retornando HTTP 200 — a assinatura de um login bem-sucedido, e não de uma sondagem. O malware que encontraram abrangia desde um backdoor PHP mínimo de uma linha até um webshell de 150 KB disfarçado como um plugin de segurança legítimo do WordPress chamado CMSmap, com módulos de gerenciamento de arquivos, acesso a banco de dados, varredura de portas e escalada de privilégios.

A Wiz também registrou um limite sobre o que se pode concluir. A varredura em grande volume sem pós-exploração era comum, consistente com varredura massiva oportunista e com varredura de segurança legítima, e a empresa afirmou que não havia identificado movimentação lateral nem exfiltração de dados. Isso é uma afirmação sobre o que a telemetria de um fornecedor mostrou, não uma constatação de que nada foi retirado.

O que mudou depois, e o que permaneceu em aberto

Para operadores, o caminho de resposta foi curto. Atualizar para WordPress 7.0.2, WordPress 6.9.5 ou WordPress 6.8.6 é a correção. As alternativas de emergência da Searchlight, para sites que não puderam atualizar imediatamente, eram bloquear o acesso anônimo à API de lote — seja instalando um plugin que bloqueia totalmente o acesso anônimo à REST API, seja bloqueando /wp-json/batch/v1 e ?rest_route=/batch/v1 em um firewall de aplicação web. A empresa alertou que ambas podem afetar o uso legítimo do site e devem ser tratadas como medidas temporárias até que a atualização chegue. O verificador público em wp2shell.com testa uma instância diretamente. As entradas do catálogo da CISA acrescentaram um prazo de conformidade: remediação até 24 de julho para CVE-2026-63030 e até 4 de agosto para CVE-2026-60137.

Para a pergunta de pesquisa, a parte que não foi resolvida é o que o modelo de fato contribuiu em relação ao seu operador. Kues é preciso sobre a divisão: o modelo produziu a cadeia em cerca de dez horas, e entendê-la levou mais tempo para ele do que gerá-la. Ele evita alegações gerais e diz apenas que o resultado de dez horas não seria alcançável por um humano sem auxílio. O próprio prompt não é segredo — deriva de um que a OpenAI publicou, e a Searchlight reproduziu sua estrutura no texto, incluindo a instrução de ignorar o histórico de versões e o requisito de que o exploit funcione em uma configuração típica de produção. Se essa receita se transfere para outras bases de código é exatamente a pergunta que Kues diz não estar respondendo, e nenhuma segunda execução foi publicada.

O que o registro deixa sem estabelecer é, portanto, estreito, mas consequente: qual das duas partes creditadas encontrou primeiro a injeção, se algum corretor chegou a pagar a cifra da manchete e o que, se é que algo, os webshells observados pela Wiz realmente levaram dos sites em que aterrissaram. Sobre o último ponto, a única declaração pública é a da Wiz, de que não identificou nenhum movimento lateral ou exfiltração de dados — uma ausência de evidências a partir de um ponto de observação, oferecida como tal.