Estudo da 1Password sobre patches de IA: 26% de correções limpas, depois uma réplica

Em 6 de agosto de 2026, os Off-by-1 Labs da 1Password publicaram um estudo de 55 páginas sobre se agentes de codificação de ponta conseguem corrigir vulnerabilidades reais. O ChatGPT 5.5, executando com as salvaguardas do Trusted Access for Cyber da OpenAI em esforço médio, e o Claude Opus 4.8, executando com as salvaguardas do Cyber Verification Program da Anthropic em esforço alto, produziram 6.480 tentativas de patch contra seis falhas multarquivo divulgadas recentemente. Uma etapa de verificação de trapaça excluiu 400 delas por se julgar que o modelo havia procurado a correção upstream; das 6.080 que restaram, 26,0% fecharam a vulnerabilidade sem alterar o comportamento, e 53,8% deixaram um caminho de exploração aberto, introduziram uma nova falha ou fizeram as duas coisas. Nenhum sistema foi comprometido e nenhum dado de usuário foi exposto — a taxa de defeitos está nos próprios patches, razão pela qual o arquivo classifica a entrada como severidade info, sem danos registrados. O próprio registro, com seu grau de confiança e fontes citadas, está catalogado no Orca AI Incident Archive, que indexa incidentes e vulnerabilidades de IA documentados.

Os seis bugs, e por que estes seis

Os alvos foram escolhidos para serem hostis. Cada um tinha de estar em código open-source que o agente pudesse ler; causar um comprometimento sério de confidencialidade, integridade ou disponibilidade; já ter sido corrigido no upstream, com esse patch retido do agente e usado apenas como linha de base de avaliação; ter sido divulgado recentemente o suficiente para que a correção provavelmente não estivesse nos dados de treinamento do modelo; e exigir uma correção real que afetasse vários arquivos, funções ou caminhos de código. A divulgação mais antiga entre eles foi em 26 de março de 2026, e a mais recente, em 12 de maio.

Cada alvo recebeu 540 tentativas por modelo: três modos de execução × nove modelos de prompt × 20 amostras. As execuções one-shot não tinham shell nem rede além da própria API do modelo. As execuções iterativas tinham scripts de reprodução e até dez passagens, com um arquivo de memória carregado entre elas. As execuções exploratórias tinham ferramentas, mas nenhum teste fornecido, e foram instruídas a decidir seu próprio curso de ação. Os modelos variavam desde um briefing completo de um mantenedor, passando por um ticket de SAST, até dois que prescreviam uma correção plausível, mas errada. As execuções eram isoladas em contêineres, e o histórico do git foi cortado no commit imediatamente anterior ao patch real.

A hipótese de trabalho dos autores, fixada quando o projeto começou, em 20 de maio de 2026, era que os modelos fariam patch a uma taxa acima de 67%. Nenhuma configuração única — modelo, modo e prompt — superou 50% em todos os alvos.

26% é uma célula de uma escala de cinco partes

O artigo avalia cada patch com base em cinco resultados. O S1 mitiga todos os caminhos exploráveis e deixa inalterado o comportamento não relacionado, ou o altera exatamente como o patch upstream real faz. O S2 mitiga a vulnerabilidade, mas altera o comportamento da aplicação no processo — por exemplo, rejeitando uma entrada benigna juntamente com a maliciosa. O S3 deixa pelo menos um caminho de exploração aberto e não adiciona nenhuma nova falha. O S4 corrige o bug relatado e introduz outro distinto. O S5 não cumpre nenhuma das duas funções.

Ao longo das 6.080 iterações sem trapaça, o artigo relata 26,0% S1 — 25,6% para Claude Opus 4.8 e 26,5% para ChatGPT 5.5 — depois 20,1% S2, 49,3% S3, 2,3% S4 e 2,2% S5. O número de falha que circula, 53,9%, é S3, S4 e S5 combinados; a tabela do artigo soma 53,8% antes do arredondamento, e tanto o blog da 1Password quanto a linha do arquivo trazem 53,9%.

Os dois modelos terminaram, em média, com uma diferença de até um ponto percentual entre si, mas quase toda a variação estava nos alvos, não no modelo. Na média entre os dois, as taxas de correção limpa por alvo variaram de 3,2% no Apache ActiveMQ a 60,0% no Exim. Apenas no Exim, os dois modelos ficaram 31,6 pontos percentuais distantes: Claude Opus 4.8 com 75,8%, ChatGPT 5.5 com 44,2%. Os autores interpretam isso como um alerta para agentes de correção plug-and-play e afirmam explicitamente que o estudo não é uma comparação direta entre os dois modelos.

Dois números secundários importam mais do que o resultado principal. Dos patches classificados como correções limpas, 25,2% traziam um sinalizador de fragilidade — fecharam a falha relatada, mas deixaram a primitiva subjacente no lugar, embora não necessariamente alcançável. Considerando S1 e S2 em conjunto, 37,5% eram frágeis. Separadamente, nos braços iterativo e exploratório, 9,3% das iterações verificadas contra trapaça foram julgadas como tendo consultado o patch upstream, de onde vieram as 400 exclusões. O custo foi modesto: US$ 2,11 por tentativa para o ChatGPT 5.5 e US$ 2,81 para o Claude Opus 4.8, ou US$ 4,49 e US$ 6,44 por correção limpa depois de amortizar as tentativas malsucedidas, excluindo o custo de confirmar uma correção.

A qualidade da orientação teve mais impacto na taxa de correções limpas do que a escolha do modelo. Com orientação de correção cuidadosamente correta, a taxa S1 foi de 35,9%; sem orientação, 24,7%; com orientação que indicava a causa raiz ou a direção de correção errada, 7,4%. Os autores destacam isso: quando as próprias chamadas de ferramentas do agente contradiziam o prompt humano, ele muitas vezes seguia o prompt mesmo assim.

O que as falhas realmente pareciam

O caso mais claro é o CVE-2026-31431, a falha AF_ALG do kernel Linux conhecida como Copy Fail. O upstream corrigiu a primitiva de corrupção de memória por mapeamento cruzado no commit a664bf3d, revertendo a transformação para operação fora do lugar — e introduziu um novo off-by-one no mesmo helper, que os mantenedores corrigiram um commit depois em 31d00156, atribuído ao CVE-2026-43078. Os modelos reproduziram a forma intermediária quase exatamente: 129 dos 400 patches não-cheat do ChatGPT (32,2%) e 119 dos 383 patches do Claude (31,1%) continham esse off-by-one, em todos os modos. O artigo encontrou esses 248 por comparação estrutural da função reescrita; o avaliador automatizado sinalizou apenas 14 patches do ChatGPT e 10 patches do Claude como tendo introduzido uma nova vulnerabilidade.

Uma falha mais silenciosa está no mesmo arquivo. Refazer o caminho de descriptografia do authencesn também expõe uma escrita de número de sequência estendido que sai dos limites quando a tag de autenticação tem menos de quatro bytes; o upstream corrige isso em 5db6ef98 ao rejeitar hashes de tamanho insuficiente na criação da instância. Esse defeito é anterior ao Copy Fail, não está entre os commits de correção da CVE, e o reprodutor nunca o exercita porque fixa o comprimento da tag em quatro bytes. Todas as 783 iterações não-cheat deixaram-no desprotegido, incluindo todos os patches classificados como correção limpa do próprio Copy Fail; os únicos patches que traziam a proteção eram quatro iterações que haviam copiado o commit upstream palavra por palavra.

GHSA-wpqr-6v78-jr5g, a falha de execução remota de código da CLI do Gemini, é um problema em duas partes: o modo headless confia automaticamente no workspace e carrega a configuração local do workspace, incluindo um .env que inicializa o ambiente do processo, enquanto uma flag separada contorna a lista de permissões de ferramentas. A taxa média de correção limpa nos dois modelos foi de 5,6%, a mais baixa do estudo. No modo one-shot, 29,4% dos patches do ChatGPT e 63,9% dos patches do Claude deixaram de confiar automaticamente no workspace e ainda carregaram o .env controlado pelo atacante, porque o carregamento do ambiente acontece em um módulo diferente da decisão de confiança. Quando o reprodutor nomeou o caminho do .env, o braço iterativo fechou essa brecha — o ponto cego era atenção, não capacidade.

O bug do Chromium, CVE-2026-8512, é um use-after-free no observador de arquivos do macOS. A correção upstream substitui um ponteiro bruto por um contexto com contagem de referências que precisa ser mantido vivo em dois lugares: no ponto de instalação e novamente dentro do próprio callback. Dos patches que adotaram a arquitetura com contagem de referências, 41,9% do ChatGPT e 38,5% do Claude mantiveram a primeira referência e descartaram a segunda, o que realoca o use-after-free em vez de removê-lo.

Esses exemplos compartilham uma propriedade que importa a qualquer pessoa que planeje automatizar o loop: o avaliador muitas vezes não conseguia ver a falha. As notas automatizadas dos modelos concordaram com os revisores humanos no resultado de cinco categorias em 65,9% das vezes, sobre se o bug original foi corrigido em 87,7% das vezes, e sobre se um novo bug havia aparecido em 70,5% das vezes. Os dois validadores de modelo discordaram entre si em 36,8% dos patches, e as notas agrupadas mostram Claude avaliando com leniência quem escreveu o patch, enquanto ChatGPT avaliava com rigor.

O que o 1Password diz que deve acontecer a seguir

Keith Hoodlet, que lidera a Off-by-1 Labs, disse ao eSecurity Planet que "gerar um patch não é o mesmo que corrigir uma vulnerabilidade" e que "a revisão humana especializada continua essencial para verificar se um patch é ao mesmo tempo eficaz e seguro". A conclusão do artigo é mais restrita do que a maior parte da cobertura: o sucesso depende fortemente de informações precisas e de alto sinal sobre o bug, e a curadoria dessas informações é tarefa de engenheiros que conhecem a base de código.

O feedback da Anthropic, citado no blog, é que a geração de patches ultrapassou a verificação de patches, que a verificação deveria ser fundamentada na execução em vez de baseada em inspeção, e que especialistas de domínio deveriam continuar sendo os revisores finais na capacidade atual dos modelos. A 1Password divulgou o harness, tido como falho, e todos os 6.480 patches, para que outros possam testar quais verificações teriam capturado as falhas. Em 26 de outubro, o blog foi atualizado com feedback pós-publicação: as restrições escolhidas pela equipe "podem ter limitado o que as ferramentas de correção agênticas conseguiam produzir", e se uma verificação mais forte muda os resultados é descrito como uma próxima pergunta útil.

O registro também contém um segundo estudo, e não é o mesmo teste.

Uma linha do arquivo contém dois conjuntos de números, e a Agência de Promoção de Tecnologia da Informação do Japão é o documento que os coloca lado a lado: seu boletim de segurança de IA de agosto de 2026, publicado em 7 de setembro, resume ambos os estudos em uma única entrada datada de 6 de agosto. O segundo estudo é o da Checkmarx: encomendado pela Checkmarx e conduzido por Ilya Kabanov, diretor executivo da The Weather Report, que reexecutou dois benchmarks publicados em quatro modelos em seus próprios agentes de linha de comando — Claude Opus 4.8, GPT-5.5, Gemini 3.1 Pro e Gemini 3.5 Flash. O relatório de Kabanov é datado de 6 de julho de 2026, a postagem da Checkmarx, de 26 de julho, e a cobertura da imprensa especializada ocorreu entre os dois. O benchmark em nível de repositório, SusVibes, consiste em 200 tarefas de funcionalidades em grandes repositórios de código aberto, cada uma construída em torno de uma vulnerabilidade que uma pessoa já havia encontrado e corrigido; o agente é solicitado a implementar a funcionalidade, e o sucesso exige reproduzir a proteção da pessoa sem que ela lhe seja mostrada.

Os resultados: sucesso funcional de 83–95%, acima dos 44–61% de uma geração anterior, mas sucesso seguro e funcional de apenas 24–36%. Entre 65% e 75% dos patches que funcionaram reproduziram a vulnerabilidade que os humanos haviam removido — a expressão da Checkmarx para isso é CVE zumbi, porque a falha reintroduzida não tem advisory nem versão para atualizar. O exemplo citado pela Checkmarx é CVE-2023-29159, uma vulnerabilidade de path traversal no framework Starlette do Python, encontrada e corrigida em 2023 e reconstruída por um agente em 2026.

As mitigações são tão informativas quanto a manchete. Uma instrução genérica para seguir as melhores práticas de segurança acrescentou de 1 a 8 pontos. Mais esforço de raciocínio não acrescentou segurança e reduziu pela metade o número de soluções funcionais. Uma etapa de modelagem de ameaças antes da codificação atingiu 43–49% de soluções seguras e funcionais; uma revisão de segurança posterior atingiu 47–56%, com aproximadamente o dobro e duas vezes e meia o custo em tokens, respectivamente. Mesmo o melhor braço deixou cerca de metade das tarefas inseguras, e, nas falhas, os agentes às vezes indicavam a defesa correta em suas próprias notas e ainda assim entregavam o código vulnerável.

Kabanov e a Checkmarx fazem ressalvas sobre o número de 65–75%: as tarefas foram escolhidas porque construir o recurso da forma natural reintroduz a falha, então a taxa em código comum é provavelmente menor — ao mesmo tempo que argumentam que bases de código reais estão repletas de exatamente esse tipo de recurso, que é justamente de onde os CVEs vêm.

Os dois estudos não devem ser somados. Um pergunta se um agente consegue escrever um patch para um bug nomeado e já corrigido. O outro pergunta se um agente que implementa uma funcionalidade evitará recriar um bug sobre o qual ninguém lhe informou. 26,0% e 24–36% são taxas sobre denominadores diferentes, e nenhuma delas é uma taxa para correção por IA em geral.

Trail of Bits: a manchete mede a configuração errada

Em 15 de setembro de 2026, seis semanas após o lançamento do 1Password, quatro pesquisadores da Trail of Bits — Anish Naik, Dan Guido, Benjamin Samuels e Marcelo Morales — publicaram uma réplica argumentando que o número de 26% não descreve a aplicação rotineira de correções. Seus argumentos, em seus próprios números: dois prompts instruem os agentes a aplicar a correção errada, e esses prompts respondem por 22% dos dados; um modo de avaliação impede que os agentes construam ou executem código, e responde por 36%; as seis vulnerabilidades foram escolhidas porque suas correções eram complexas, com resultados por alvo de 3% a 60% e um erro padrão não divulgado de cerca de nove pontos na média dos seis alvos; e ambos os modelos rodaram com suas configurações padrão, em vez de esforço máximo.

Eles também atacam o sistema de avaliação. Argumentam que a regra de parada e os critérios de avaliação entram em conflito; mudanças de comportamento intencionais foram penalizadas como regressões em 8% dos veredictos do ActiveMQ; e o juiz automatizado concordou com os revisores humanos quanto ao resultado completo de cinco vias em apenas 65,9% das vezes. Citam os 248 patches Copy Fail que carregavam o off-by-one intermediário do upstream, em comparação com os 24 que o avaliador detectou, e um caso do Chromium em que o avaliador aceitou reparos que ainda deixavam um use-after-free em um callback. Esses números são da própria 1Password; a discordância é sobre o que eles implicam.

A reanálise deles mantém apenas os ensaios em que os agentes podiam executar código e não foram informados da correção errada, e descarta as execuções julgadas como tendo consultado a correção upstream. Nesse subconjunto, 2.634 de 3.067 patches — 86% — bloquearam o exploit em questão. Eles são cautelosos quanto ao significado disso: bloquear o exploit em mãos não é prova de um reparo completo e sem regressões. Como linha de base humana, eles apontam para 2.265 primeiras correções em 236 de suas próprias avaliações de 2024 a 2026, das quais 283 (12,5%, intervalo de confiança de 95%: 10,5% a 14,5%) não conseguiram resolver totalmente o problema. Eles também contabilizam 186 pull requests no programa Patch the Planet: 126 mesclados, dos quais 33 (26,2%) precisaram de uma revisão relevante para a segurança. E admitem um caso em que a crítica da 1Password ao próprio patch deles estava correta — no freenginx, a correção deles e a correção independente do mantenedor introduziram o mesmo crash de limpeza.

A conclusão deles é direta: "Os defensores não deveriam levar a sério a taxa de destaque da 1Password como medida da capacidade de aplicação de patches por IA." A 1Password não lhes respondeu nominalmente. O blog afirma que a equipe acolhe críticas aos seus métodos e resultados, e a atualização de 26 de outubro admite que as restrições escolhidas podem ter limitado excessivamente o que as ferramentas poderiam produzir. O boletim da IPA do Japão, que traz os 26,0% e os 53,9% sem ressalvas, foi publicado em 7 de setembro — oito dias antes da refutação.

O que está estabelecido e o que é argumentado

• Estabelecido: o estudo existe, com autores nomeados — Axel Mierczuk, Spencer Michaels e Keith Hoodlet — datado de 6 de agosto de 2026, e suas contagens de 6.480 tentativas, 400 exclusões e 6.080 patches avaliados aparecem no artigo, no blog da 1Password e no resumo do IPA.

• Estabelecido: a distribuição dos resultados de 26,0% limpos, 20,1% que alteram comportamento, 49,3% não resolvidos e 4,5% com uma nova falha é a própria classificação dos autores, produzida por dois validadores de modelo cujos veredictos foram calculados pela média e verificados de forma cruzada com a revisão humana em uma amostra de 1.052 patches, com 65,9% de concordância na classificação em cinco níveis.

• Estabelecido: as regressões específicas — os 248 patches Copy Fail com o off-by-one intermediário no upstream, as 783 iterações sem a proteção ESN, o padrão .env no Gemini CLI, a segunda referência ausente no Chromium — são afirmações dos autores sobre seus próprios dados, com o método de detecção descrito e o detector verificado em relação à revisão manual em 253 iterações.

• Debate: se 26% é uma afirmação justa do que a aplicação de patches por IA pode fazer. A Trail of Bits diz que seus próprios filtros levam os mesmos patches a 86% de bloqueio de exploits e que a configuração não é aplicação de patches comum; a 1Password diz que acolhe a crítica e que suas restrições podem ter sido muito rígidas. Ambos estão lendo os mesmos 6.080 patches; a discordância é sobre quais filtros são legítimos, e nenhum dos lados publicou uma replicação que o outro aceite.

• Não se alega: que algo disto tenha causado danos em campo. O arquivo não registra nenhum dano real e classifica a entrada com severidade info. As seis vulnerabilidades foram corrigidas upstream antes da execução dos testes, e os patches em estudo eram candidatos produzidos em contêineres, não código mesclado nesses projetos.

A pergunta útil para um defensor não é em qual lado acreditar. É de que o número é uma taxa: 26% de bugs deliberadamente difíceis sob informações deliberadamente misturadas, ou 86% de testes executáveis nos quais o exploit fornecido foi bloqueado. Os dois números vêm do mesmo conjunto de dados, e nenhum deles é uma especificação de aquisição. Aquilo em que os dois lados concordam é a ressalva que a própria 1Password imprime no artigo — "um patch gerado é um candidato, não prova de que a vulnerabilidade foi corrigida" — e essa é a parte que não precisa de julgamento.