Três de Cada Quatro Patches de Segurança Gerados por IA Estão Quebrados

A Off-by-1 Labs, time de pesquisa em segurança da 1Password, gerou 6.080 patches para seis CVEs divulgadas recentemente usando dois modelos de raciocínio de fronteira. Depois mediu o que esses patches de fato fizeram. Apenas 26,0% corrigiram completamente a vulnerabilidade sem alterar o comportamento da aplicação. Outros 20,1% corrigiram e quebraram alguma outra coisa. Os 53,9% restantes falharam em corrigir, introduziram uma vulnerabilidade nova, ou conseguiram as duas coisas ao mesmo tempo.

A hipótese de partida dos pesquisadores era uma taxa de sucesso acima de 67%. Eles publicaram o número que encontraram.

O Que Foi Medido de Fato

O desenho do experimento importa, porque a tentação é descartar um resultado ruim como prompt ruim. A Off-by-1 rodou 540 tentativas de patch por vulnerabilidade por modelo, em três configurações de ambiente e nove templates de prompt específicos por CVE. O ChatGPT-5.5 rodou com esforço de raciocínio médio e Trusted Access for Cyber habilitado. O Opus 4.8, da Anthropic, rodou com esforço alto sob o Cyber Verification Program. Os dois modelos tinham o relatório da vulnerabilidade, o código e a possibilidade de iterar.

Os seis alvos não são bugs de brinquedo. CVE-2026-31431 é escalação de privilégio no Linux. CVE-2026-34197 é execução remota de código no ActiveMQ. CVE-2026-8512 é um use-after-free na File System Access API do Chrome no macOS. CVE-2026-45185 é RCE não autenticada no EXIM. CVE-2026-22738 é injeção de SpEL no SpringAI. GHSA-wpqr-6v78-jr5g é RCE na CLI do Gemini. Seis avisos reais, cobrindo kernel, message broker, navegador, servidor de e-mail e duas bases de código do próprio ecossistema de IA.

Cada tentativa foi classificada em uma taxonomia de cinco cenários: correção completa sem mudança de comportamento (S1), correção completa com mudança de comportamento (S2), sem correção (S3), correção acompanhada de vulnerabilidade nova (S4) e ausência de correção acompanhada de vulnerabilidade nova (S5). Os três últimos formam o que o time batizou de FLAWED, artefatos com aparência de correção e defeitos embutidos. Essa categoria é a maioria da produção.

O custo de gerar essa produção merece registro, porque é baixo o suficiente para ser perigoso. US$ 2,11 por tentativa de patch e ciclo de validação no ChatGPT-5.5. US$ 2,81 no Opus 4.8. A esse preço, uma organização gera remediação mais rápido do que consegue avaliar, que é exatamente a condição em que trabalho não verificado se acumula.

A Assimetria Que Ninguém Precificou

Keith Hoodlet, autor da pesquisa, formula o achado central sem rodeios: “LLMs que se destacam ao descobrir uma ampla variedade de vulnerabilidades hoje são, no momento, eficazes em corrigir apenas um subconjunto estreito delas.”

Descoberta e remediação são duas capacidades distintas que por acaso moram no mesmo modelo. Encontrar uma vulnerabilidade é um problema de busca com ponto final verificável: o exploit dispara ou não dispara. Corrigi-la é um problema de design restringido por tudo aquilo que o código já fazia corretamente. Um modelo pode ser excelente na primeira tarefa e medíocre na segunda, e o desempenho na primeira não diz nada sobre a segunda.

A indústria vinha assumindo o contrário em silêncio. A atualização do Project Glasswing da Anthropic, de maio de 2026, descreveu a virada com honestidade: “O progresso em segurança de software costumava ser limitado pela velocidade com que conseguíamos encontrar novas vulnerabilidades. Agora é limitado pela velocidade com que conseguimos verificar, divulgar e corrigir.” Todo roadmap de AppSec que trata remediação assistida por IA como consequência natural da descoberta assistida por IA herdou uma premissa que esses dados não sustentam.

O caso do SpringAI mostra o modo de falha com clareza incomum. Os patches escapavam caracteres específicos na entrada do usuário e deixavam a causa raiz da injeção intacta. O scanner de vulnerabilidade silencia. O caminho de exploração continua ali, esperando um caractere um pouco diferente. Os pesquisadores registram que isso “levaria ao ressurgimento da vulnerabilidade antiga no software”. Um ticket fechado, um buraco aberto e nenhum sinal entre os dois.

Ler o Diff Não é um Controle

Mais de 33% dos patches bem-sucedidos, os resultados S1 e S2, ainda continham sutilezas que os pesquisadores classificaram como frágeis do ponto de vista de segurança. A pilha boa tem sua própria taxa de contaminação. Passar na checagem automatizada e ser sólido são coisas diferentes.

A Off-by-1 deu nome à metade humana do problema: rendição cognitiva. Um revisor que não está prestando atenção cuidadosa aprova o código do LLM porque ele parece uma correção. Tem o formato de uma correção. Toca o arquivo que o aviso apontava. Adiciona uma chamada de sanitização. Lê como competente, porque o modelo que escreveu é genuinamente competente em produzir texto que lê como competente.

Por isso um processo de revisão construído sobre a leitura de diffs não funciona como controle para trabalho de segurança gerado por IA. A leitura é justamente o canal que esse modo de falha está otimizado para atravessar. Já argumentamos que agentes burlam a verificação quando ela opera em escala; aqui a mesma dinâmica aparece sem nenhuma intenção adversarial, apenas por plausibilidade. E é por isso que insistimos que governança de IA é uma disciplina de cibersegurança, não um exercício de documentação. Um documento de política não roda o exploit. Um harness de teste roda.

O ponto de controle é a verificação ancorada em execução. O build corrigido precisa ser atacado com a prova de conceito original e confirmado morto. O comportamento da aplicação precisa ser exercitado contra uma suíte de regressão capaz de pegar as falhas S2, aquelas em que a vulnerabilidade sumiu e uma funcionalidade sumiu junto. Nenhuma das duas é atividade de leitura. As duas são executáveis, portanto automatizáveis, portanto escalam junto com o volume de geração que US$ 2,11 por patch torna possível.

O Que Separa Isso de Uma Opinião

A Off-by-1 Labs publicou a ferramenta FLAWED e os datasets. Qualquer time pode apontar a mesma medição para a própria base de código, as próprias CVEs e a própria configuração de modelo.

Isso muda o formato da conversa interna. A pergunta deixa de ser se patching por IA é bom o bastante, discutida a partir de promessas de fornecedor e histórias de guerra individuais, e passa a ser qual é a sua taxa de S1 no seu código. Linguagens, frameworks e classes de vulnerabilidade diferentes vão produzir números diferentes. Alguns times vão superar os 26,0%. Outros vão ficar longe. De qualquer forma a resposta é mensurável em uma tarde, e uma organização que mediu negocia com um número enquanto a concorrência negocia com adjetivos.

É a mesma disciplina que descrevemos para baselines de qualidade de código, aplicada a um domínio onde errar custa uma vulnerabilidade aberta em vez de uma sprint mais lenta.

Faça Isso Agora

Pegue as últimas dez correções de segurança que sua organização mergeou com assistência de IA. Para cada uma, responda com evidência a uma única pergunta: alguém rodou a prova de conceito original contra o build corrigido?

Se a resposta for não na maioria dos casos, o que existe aí é um processo de geração com uma etapa de leitura acoplada, e os dados publicados dizem que essa etapa aprova a maior parte do trabalho quebrado. Baixe a ferramenta FLAWED, rode contra um serviço representativo e coloque a taxa de S1 resultante na frente de quem assina a postura de segurança da empresa. Depois transforme a reexecução do exploit em requisito de merge, não em boa prática.

Os times que vão atravessar bem os próximos dois anos são os que conseguem provar, em um ambiente e sob demanda, que uma vulnerabilidade está morta. O resto está entregando correções que apenas leu.

Fontes

1Password (Off-by-1 Labs), Keith Hoodlet. “Off-by-1 Labs Research: AI-generated vulnerability patches require human review.” Agosto de 2026.
Off-by-1 Labs. “FLAWED tooling and datasets.” Agosto de 2026.

A Victorino ajuda organizações de engenharia a colocar verificação ancorada em execução no pipeline de remediação de segurança assistida por IA: contato@victorino.com.br | www.victorino.com.br