O Google GTIG identificou o primeiro zero-day desenvolvido por IA no wild. E o código deixou a assinatura. Segundo o relatório publicado em 11 de maio, atores criminais usaram IA para descobrir e armar uma vulnerabilidade em uma ferramenta popular de administração de sistemas código aberto (open-source). O exploit era um bypass de 2FA via script Python. A causa raiz: uma falha semântica de lógica (hardcoded trust assumption) — o tipo de vulnerabilidade que LLMs encontram bem e fuzzers tradicionais não. Nós acompanhamos essa evolução de perto e o cenário é claro: a superfície de ataque acabou de se expandir para classes inteiras que nossas ferramentas tradicionais não cobrem.
A assinatura de IA no código de exploit
O Google GTIG determinou que o exploit foi desenvolvido com apoio de IA por quatro marcadores inequívocos. Primeiro, docstrings educacionais em abundância — nenhum atacante humano escreve comentários didáticos em exploit code. Segundo, CVSS alucinado: o script continha um score de severidade fabricado que não existe em nenhuma base de dados. O modelo inventou o número. Terceiro, formato Pythonic estruturado e textbook — código limpo, anotado, estilo de dados de treinamento de LLM. Quarto, menus de ajuda detalhados e classe ANSI colorida polida — código de exploit excessivamente refinado para o propósito criminoso.
O Google declarou ter "alta confiança de que o ator usou um modelo de IA para apoiar a descoberta e armamento desta vulnerabilidade." Não foi Gemini. Não foi Mythos. Modelo comercial não identificado. O plano era uso em massa — o Google descobriu proativamente antes da campanha de exploração em larga escala. O vendor corrigiu. Erros na implementação do exploit provavelmente interferiram com o sucesso dos criminosos. Mas o fato de o ataque não ter atingido escala não diminui o marco: a IA já está descobrindo e armando vulnerabilidades que humanos e ferramentas tradicionais não encontram.
A classe de vulnerabilidade que muda o jogo
Aqui está o ponto que importa para quem defende infraestrutura: o tipo de bug que IA encontra é diferente do que fuzzers encontram. O espelho é esclarecedor. Em outubro de 2024, o Big Sleep (Project Zero + DeepMind) encontrou um zero-day no SQLite — IA defensiva encontrando vulnerabilidades para corrigir. Agora, segundo o Google GTIG, IA ofensiva encontrando vulnerabilidades para explorar. Mesma capacidade, intent oposto.
Mas a diferença de classe de vulnerabilidade importa. O Big Sleep encontrou um bug de segurança de memória — stack buffer underflow no SQLite. O zero-day criminoso é uma falha semântica de lógica. LLMs raciocinam sobre intenção do desenvolvedor. Fuzzers não. Isso expande a superfície de ataque para classes inteiras que ferramentas tradicionais não cobrem. Um fuzzer testa limites de memória e entradas malformadas. Um LLM lê o código, entende o que o desenvolvedor quis fazer, e encontra onde a lógica quebrou. É uma categoria de vulnerabilidade fundamentalmente diferente.
Para nós, que operamos segurança ofensiva diariamente, essa distinção é prática, não teórica. Quando auditamos uma aplicação, as falhas semânticas de lógica — bypass de autorização, trust assumptions incorretas, fluxos de autenticação quebrados — são exatamente as que exigem raciocínio humano. Até agora, eram as mais difíceis de encontrar automaticamente. Agora, um LLM com acesso ao código-fonte pode identificá-las em minutos.
A compressão de tempo e o contexto APT
Os números da Cogent Research (27 de maio) são contundentes: o tempo de CVE disclosure para exploit funcional caiu de 125,3 dias (janeiro 2025) para 0,5 dias (abril 2026). 62% das CVEs críticas tinham exploits antes da detecção por scanners. Isso é vulnerabilidades conhecidas. O zero-day do Google GTIG é o próximo nível: IA encontrando vulnerabilidades desconhecidas.
E o contexto do mesmo relatório mostra que a adoção de IA por APTs é ampla. Segundo o Google GTIG, APT45 (Coreia do Norte) envia milhares de prompts para analisar CVEs e validar PoCs. UNC2814 (China) usa jailbreaks com persona para pesquisa de vulnerabilidades em dispositivos embarcados. APT27 (China) usa Gemini para gerenciamento de rede ORB. PROMPTFLUX/HONESTCUE usa API Gemini para ofuscação dinâmica. Não é um ator isolado — é um ecossistema.
Segundo John Hultquist, analista-chefe do GTIG: "Há uma concepção equivocada de que a corrida de vulnerabilidades por IA é iminente. A realidade é que já começou."
Nós vemos essa compressão de tempo na prática. Um cliente nosso teve uma CVE crítica explorada em menos de 24 horas após disclosure este ano. Quando o tempo de janela é medido em horas, o processo manual de avaliação, priorização e patching não acompanha. Automação não é mais aspiracional — é requisito de sobrevivência.
O que isso significa para defesa corporativa
A corrida não é mais se IA zero-days vão se tornar comuns. É quão rápido. E a resposta não é mais fuzzing — é análise semântica. Nós operamos segurança ofensiva para clientes corporativos e o que vemos no campo confirma: as ferramentas que protegiam infraestrutura ontem não cobrem as classes de vulnerabilidade que IA descobre hoje.
Ferramentas de análise estática tradicionais procuram padrões conhecidos. Fuzzers testam limites de memória. Nenhuma das duas modela intenção do desenvolvedor. Quando um LLM lê um código de autenticação e identifica que o desenvolvedor assumiu confiança hardcoded (hardcoded trust assumption) em vez de validar explicitamente, isso é raciocínio sobre semântica — não sobre sintaxe.
Na Tech86, nossa prática de segurança ofensiva simula exatamente esse tipo de raciocínio. Nós não dependemos apenas de fuzzers e scanners — nosso processo de pentest inclui análise semântica de lógica de autorização, trust assumptions embutidas no código (hardcoded), e inconsistências de modelo de ameaça (threat model). Quando o atacante usa IA para encontrar falhas de lógica, a defesa precisa usar a mesma classe de raciocínio para antecipá-las.