Pentest com IA: falha achada em um dia, explorada no dia seguinte
O CVE-2026-61500 no Rejetto HFS foi encontrado por um agente de IA e explorado em menos de 24 horas. A aula está na parte chata do código, não na magia.
A imagem é tentadora: um modelo de IA encontra uma falha em um código aberto, transforma um problema matemático em exploit funcional e, menos de 24 horas depois, alguém já está usando a porta na vida real. Entendo a tentação, porque é uma boa história. Só que ela esconde a parte que interessa ao seu CTO, e essa parte é bem menos glamourosa: a falha não era de IA. Era um gerador de número aleatório ruim por trás de um cookie de sessão. O que mudou não foi o alvo. Mudou quem teve disposição de olhar a parte chata do código.
O que você leva deste texto: por que a falha mais séria da semana era de implementação comum, e o que isso significa para o escopo do seu próximo teste.
O que aconteceu
O CVE-2026-61500 foi publicado em 13 de julho de 2026 e atualizado em 1º de outubro. Ele atinge o Rejetto HTTP File Server (HFS) nas versões 3.0.0 até 3.2.0. O registro oficial do CVE descreve o problema em uma frase que dispensa interpretação: o HFS deriva a chave de assinatura dos cookies de sessão de um gerador pseudoaleatório não criptográfico e expõe saídas desse mesmo gerador para clientes não autenticados durante o login. Com isso, um atacante remoto consegue recuperar a chave e forjar um cookie de sessão válido. O resultado é acesso administrativo completo e execução remota de código, usando um recurso nativo do próprio produto.
O CWE registrado é o 338, uso de gerador pseudoaleatório criptograficamente fraco. A severidade é crítica: CVSS 3.1 de 9.8 e CVSS 4.0 de 9.3, com vetor de rede, complexidade baixa, sem privilégio e sem interação do usuário. O pior cenário possível para quem expõe a porta.
Quem encontrou foi o researcher Zach Hanley, da Horizon3, usando o modelo Mythos da Anthropic dentro de um fluxo de pesquisa de vulnerabilidades. A empresa entrou no Project Glasswing em julho de 2026 e relata ter encontrado muitas vulnerabilidades críticas com o modelo desde então. O aviso de correção do Rejetto, na versão 3.2.1, agradece nominalmente a Hanley e a Anthropic Research.
O detalhe que eu guardaria para a conversa com o seu time é este: a própria Horizon3 escreve que researchers como eles, que evitam seguir falhas criptográficas, já abandonavam esse tipo de achado antes. Não por falta de competência. Por falta de base matemática para fechar o impacto, e porque o tempo para desenvolver o exploit não compensava. Um modelo não tem essa restrição. Ele não cansa na parte chata.
A falha não era de IA
Vou repetir de propósito, porque é aqui que o comentário de internet costuma errar: esta é uma falha de aplicação web. Não tem modelo, não tem prompt, não tem agente obediente. É um cookie assinado com segredo previsível em uma aplicação Node.js.
Esse padrão aparece o tempo todo. Time que precisa de um identificador rápido chama Math.random(), cola o resultado num token e trata aquilo como segredo. Time que precisa de aleatoriedade para senha ou cookie usa UUID.randomUUID() e acha que resolveu, quando o caso de uso é outro. Time que usa biblioteca de sessão copiada de um tutorial não sabe de onde veio a chave. Nada disso é inovação. É implementação de terça-feira.
O achado do modelo foi bonito porque ele não ficou só no PRNG fraco. Ligou o gerador fraco ao caminho de código que expõe as saídas daquele mesmo gerador, avaliou se a exposição bastava para recuperar a chave, montou o exploit funcional e rodou. Isso não é magia. É sequência. E sequência é exatamente o que revisão humana curta, feita em duas horas no fim da sprint, não faz.
Três meses no ar até alguém usar
O CVE foi publicado em 13 de julho. A exploração na vida real apareceu em 1º de outubro, segundo o The Register. Quase três meses de janela.
No dia seguinte à descoberta, o CVE já estava sendo explorado, segundo a mesma matéria. O researcher Patrick Garrity, da VulnCheck, disse que os canários dele detectaram um ator na China mirando hosts realmente vulneráveis nos Estados Unidos, com atividade noturna apontada para servidores nos EUA e no Japão, e hits seguintes entrando por um proxy.
Esse intervalo de três meses é o dado mais útil do caso, e ele não fala de IA. Fala de inventário. O HFS já estava no catálogo de vulnerabilidades exploradas do CISA desde 2024 por um flaw de injeção de template que também levava a execução de código, com uso conhecido por ransomware. O produto já era conhecido. O que faltava era alguém olhar o segundo problema no mesmo arquivo.
O que isso muda no escopo do seu teste
O pentest que eu vendo não é caça a zero-day. É o oposto: pegar a classe de falha que o seu time já conhece na teoria e nunca testou na prática, e prová-la com exploit reproduzível antes que outro prove por você.
Três coisas que eu pediria para qualquer aplicação Node.js ou com sessão customizada:
Primeiro, teste de imprevisibilidade dos tokens de sessão. Cookie e token precisam ser impossíveis de forjar com o conhecimento que um atacante tem. Se a sua aplicação tem uma camada de sessão escrita à mão, ela é candidata natural a esse tipo de falha.
Segundo, funcionalidade administrativa como superfície. O HFS tem uma API administrativa que aceita código executável por configuração. Poder administrativo grande e fácil de alcançar é o que transforma um problema de autenticação em incidente.
Terceiro, validação independente com prova. Achado sem exploit rodando é opinião. Achado com requisição, resposta e efeito observável é o que fecha relatório de auditoria.
E vale a honestidade do outro lado: nenhum pentest acha chave de nuvem vazada em repositório nem falha em binário de appliance. Se o seu risco está no CI, no fornecedor e no patching, isso é outro trabalho, com outro nome. Pentest cobre a aplicação que você escreve e opera. Abrir o alcance para tudo é discurso de quem não quer dizer o que não faz.
O que fazer agora
- Se você usa Rejetto HFS 3.x, atualize para a 3.2.1 ou superior. É a ação mais urgente deste texto.
- Revise onde a sua aplicação sorteia segredo. Se a resposta for
Math.random(), isso não é sorteio de segredo. - Peça ao seu fornecedor de teste evidência de exploit reproduzível nos achados de autenticação. Sem isso, é relatório.
- Coloque “o que não foi testado” na conversa com o auditor. Escopo declarado vale mais que cobertura presumida.
O que me impressionou nesse caso não foi o modelo. Foi o alvo ser um produto que já estava no catálogo do CISA, com uma falha anterior do mesmo tipo, e ninguém ter olhado. Isso vai continuar acontecendo em qualquer base de código até que alguém teste de verdade, com tempo suficiente para chegar na parte chata.
IA não vai substituir quem decide o que testar. Ela torna o que você decide tarde, tarde demais para o atacante.