Principais destaques
- Um pesquisador utilizou um modelo avançado de inteligência artificial para analisar o código-fonte do WordPress durante várias horas.
- A IA encontrou uma sequência de comportamentos que, quando combinados, resultavam em uma cadeia completa de exploração até execução remota de código.
- O caso mostra que o futuro da pesquisa em segurança pode estar menos na busca manual por falhas e mais na colaboração entre especialistas e modelos de IA.
A divulgação da atualização de segurança do WordPress chamou atenção pela gravidade da vulnerabilidade corrigida, mas existe uma história igualmente interessante por trás dessa descoberta.
Em vez de ser encontrada durante uma auditoria convencional, a falha surgiu após um pesquisador colocar um modelo de inteligência artificial para fazer aquilo que normalmente exige dias ou semanas de trabalho humano: ler milhões de caracteres de código, levantar hipóteses, testar possibilidades e conectar pequenos detalhes espalhados por diferentes partes do sistema.
O resultado surpreendeu até mesmo quem conduziu a pesquisa. Depois de cerca de dez horas de análise contínua, a IA não apenas identificou uma vulnerabilidade inédita, como também encontrou uma maneira de transformá-la em uma cadeia completa de exploração capaz de assumir o controle de uma instalação padrão do WordPress.
Mais do que a falha em si, o episódio chamou atenção porque mostrou uma nova forma de realizar pesquisas de segurança. Em vez de procurar apenas erros evidentes, a inteligência artificial foi capaz de entender o funcionamento interno da plataforma, encontrar inconsistências e combiná-las de uma maneira que dificilmente seria imaginada logo no início da investigação.
A investigação começou sem consultar a internet
O pesquisador responsável explica que decidiu evitar um comportamento comum dos modelos de IA: procurar informações externas para tentar descobrir vulnerabilidades já conhecidas.
Para impedir isso, ele utilizou uma cópia limpa do código-fonte da versão estável mais recente do WordPress e removeu completamente o histórico do Git. Assim, o modelo não poderia comparar versões corrigidas nem identificar mudanças recentes que denunciassem onde existia uma falha.
A única fonte de informação disponível seria o próprio código.
Além disso, o pesquisador determinou que a IA deveria agir como um verdadeiro analista de segurança, explorando diferentes áreas simultaneamente. Em vez de concentrar todos os esforços em um único caminho, o modelo recebeu a missão de investigar autenticação, manipulação de arquivos, validação de parâmetros, serialização, cache, comunicação com banco de dados, APIs REST, bibliotecas de terceiros e qualquer outro componente que pudesse representar uma superfície de ataque.
Outra instrução importante era continuar investigando mesmo quando um caminho parecesse não levar a lugar nenhum. Caso uma hipótese falhasse, o modelo deveria abandonar aquela estratégia temporariamente e abrir novas linhas de investigação, retornando apenas se surgisse uma ideia realmente diferente.
Na prática, a IA passou horas funcionando como uma equipe inteira de pesquisadores trabalhando em paralelo.
O primeiro indício parecia improvável
Depois de horas analisando milhares de arquivos, o modelo apresentou sua primeira conclusão: existia uma vulnerabilidade de SQL Injection acessível sem necessidade de autenticação.
A reação inicial foi de desconfiança.
O WordPress é um dos softwares mais utilizados do planeta, alimentando centenas de milhões de sites. Seu código já foi analisado inúmeras vezes por empresas especializadas, pesquisadores independentes e programas de recompensa por vulnerabilidades. Encontrar uma brecha desse tipo parecia improvável.
Mesmo assim, o pesquisador decidiu validar o resultado.
Foi instalada uma cópia totalmente padrão do WordPress em um servidor de testes. Em seguida, o modelo recebeu apenas a missão de demonstrar que conseguia extrair uma informação do banco de dados.
Poucos minutos depois, a IA retornou exatamente o endereço de e-mail utilizado para criar a conta de administrador daquela instalação.
Naquele momento ficou claro que a vulnerabilidade era real.
A falha estava escondida na API em lote
A investigação revelou que o problema não estava em apenas uma linha de código, mas em uma interação inesperada entre diferentes partes do WordPress.
O ponto de partida era a Batch API, recurso criado para permitir que várias chamadas à API REST fossem executadas em uma única requisição.
Em condições normais, cada requisição enviada para a API passa por uma sequência de etapas: primeiro ocorre a validação dos parâmetros, depois a sanitização dos dados, em seguida a verificação de permissões e, somente então, a função responsável pelo processamento é executada.
No entanto, a implementação da Batch API organizava essas etapas de maneira diferente.
Primeiro todas as requisições eram validadas. Somente depois todas eram executadas.
À primeira vista isso parece apenas uma otimização de desempenho. O problema é que existia uma situação específica em que os índices internos utilizados para relacionar validação e execução deixavam de corresponder exatamente às mesmas requisições.
Esse desalinhamento permitia que uma requisição fosse executada utilizando a validação destinada a outra.
Na prática, determinadas verificações simplesmente deixavam de existir.
Pequenos detalhes formaram uma exploração gigantesca
A descoberta da inconsistência ainda não representava uma invasão completa.
Ela apenas permitia contornar determinadas validações.
Foi nesse momento que o modelo começou a fazer algo que chamou atenção do pesquisador: em vez de insistir na mesma vulnerabilidade, passou a procurar outras partes do WordPress que pudessem se beneficiar daquele comportamento inesperado.
Foi assim que encontrou um parâmetro relacionado à filtragem de autores durante consultas de postagens.
Normalmente esse parâmetro era convertido para números inteiros antes de ser utilizado na construção da consulta SQL.
Entretanto, quando combinado com o problema encontrado na Batch API, essa sanitização deixava de acontecer.
O resultado era uma injeção de SQL totalmente funcional.
Mas nem isso bastava para chegar ao objetivo final.
O modelo continuou procurando mecanismos internos capazes de ampliar o impacto daquela leitura indevida do banco de dados.
Foi então que identificou o funcionamento do cache de objetos do WordPress.
Durante uma mesma requisição, o sistema reutiliza informações de postagens armazenadas em memória para evitar consultas repetidas ao banco de dados.
Manipulando cuidadosamente os dados retornados pela SQL Injection, a IA percebeu que era possível envenenar esse cache temporário, fazendo o WordPress acreditar que determinados objetos continham informações diferentes daquelas realmente presentes no banco.
A criatividade da IA apareceu na etapa seguinte
Até esse ponto ainda não existia execução de código.
O ataque apenas manipulava informações temporárias.
Foi então que o modelo encontrou outra peça importante do quebra-cabeça: o sistema de embeds do WordPress.
Sempre que um conteúdo incorpora outro post ou página, o WordPress cria estruturas auxiliares para acelerar futuras renderizações.
A IA percebeu que essas estruturas poderiam servir como ponto de apoio para transformar dados temporários em alterações persistentes.
Depois disso vieram novas descobertas envolvendo os chamados changesets, utilizados pelo personalizador de temas, relações entre páginas pai e filha, detecção automática de ciclos na hierarquia de conteúdos e, por fim, o sistema de hooks que permite a plugins executar funções durante diferentes eventos do WordPress.
Nenhuma dessas funcionalidades apresentava uma vulnerabilidade isoladamente.
O que impressionou foi a capacidade da IA de entender como cada mecanismo interagia com os demais.
Em vez de procurar uma única falha crítica, o modelo encontrou diversas pequenas oportunidades e as conectou em uma sequência extremamente elaborada até chegar à criação de um novo administrador e, posteriormente, à instalação de um plugin capaz de executar código no servidor.
O que essa descoberta representa para o futuro
O aspecto mais marcante desse episódio talvez não seja a vulnerabilidade corrigida pelo WordPress, mas a forma como ela foi encontrada.
Durante décadas, pesquisadores de segurança trabalharam examinando manualmente milhares de linhas de código em busca de comportamentos inesperados. Hoje, modelos de inteligência artificial conseguem realizar essa mesma tarefa em velocidade muito maior, analisando diferentes hipóteses simultaneamente e conectando partes distantes de um projeto de software.
Isso não significa que os especialistas deixarão de ser necessários. Pelo contrário. Neste caso, foi o pesquisador quem definiu o objetivo da investigação, preparou o ambiente de testes, validou cada descoberta, reproduziu a exploração em um servidor real e comunicou a equipe responsável pelo WordPress antes da divulgação pública.
A IA acelerou a descoberta, mas a análise crítica, a confirmação técnica e a divulgação responsável continuaram dependendo da experiência humana.
O caso reforça uma tendência que vem ganhando força na indústria: a inteligência artificial está deixando de ser apenas uma ferramenta para escrever código e começa a atuar como uma parceira na pesquisa de vulnerabilidades complexas. À medida que esses modelos evoluem, é provável que a corrida entre quem encontra falhas e quem as corrige se torne cada vez mais rápida.
