A promessa de deixar agentes de inteligência artificial corrigir automaticamente vulnerabilidades de software acaba de levar um travão empírico. A equipa de investigação Off-by-1 Labs, criada pela 1Password, gerou e avaliou manualmente milhares de correções produzidas por dois modelos de fronteira para falhas divulgadas recentemente — e concluiu que a maioria dos patches não elimina realmente o problema. Os investigadores escrevem que os modelos de linguagem produzem aquilo a que chamam FLAWED — Fix-Like Artifacts with Embedded Defects, ou artefactos com aparência de correção mas com defeitos embutidos — em 53,9% dos casos quando é necessária uma correção complexa.
Resposta rápida: A Off-by-1 Labs, da 1Password, gerou 6080 correções para seis CVEs recentes com o ChatGPT 5.5 e o Claude Opus 4.8 e verificou que apenas 26% resolveram totalmente a falha sem alterar o comportamento da aplicação. Cerca de metade deixou pelo menos um caminho de exploração aberto e uma pequena fatia chegou a introduzir uma vulnerabilidade nova. A recomendação dos autores é clara: nenhum patch gerado por IA deve chegar a produção sem revisão de um engenheiro com conhecimento do domínio, e a validação deve assentar em execução de exploits, não apenas em testes que passam.
O que foi realmente medido
O trabalho é o projeto inaugural da Off-by-1 Labs e deu origem ao artigo Frontier Models’ Vulnerability Patches are Often F.L.A.W.E.D., que se distingue de estudos anteriores por visar vulnerabilidades novas, com pouca probabilidade de constarem dos dados de treino dos modelos. Os autores são Axel Mierczuk, Spencer Michaels e Keith Hoodlet.
Foram testados dois modelos de fronteira: o ChatGPT 5.5 com esforço de raciocínio “médio” e o Claude Opus 4.8 com esforço “alto”. O objetivo declarado não era comparar os dois modelos entre si, mas perceber com que fiabilidade sistemas de IA de topo conseguem produzir correções seguras. Em vez de se limitarem a confirmar se o código compilava ou passava nos testes automáticos, os investigadores revisaram cada correção quanto à eliminação completa da vulnerabilidade, à preservação do comportamento da aplicação e à ausência de novos riscos de segurança.
Houve ainda um cuidado metodológico relevante para evitar resultados inflacionados: a equipa retirou 400 patches do conjunto reportado depois de detetar tentativas dos modelos de irem buscar informação sobre a correção oficial já disponível, e as médias publicadas basearam-se nos restantes.
Os números: 26% de sucesso limpo
Ao longo de seis CVEs divulgados recentemente foram produzidos 6080 patches, e a taxa média de sucesso para gerar uma correção que resolvesse totalmente a vulnerabilidade sem alterar materialmente o comportamento da aplicação foi de apenas 26,0%.
| Resultado da correção | Percentagem |
|---|---|
| Corrigiu a falha sem alterar o comportamento da aplicação | 26,0% |
| Corrigiu a falha mas alterou o comportamento da aplicação | 20,1% |
| Falhou a eliminar pelo menos um caminho de exploração | 49,3% |
| Corrigiu a falha original mas introduziu uma nova vulnerabilidade | 2,3% |
| Falhou a correção e introduziu uma nova vulnerabilidade | 2,2% |
Estes valores foram compilados a partir da classificação dos investigadores, que registaram 49,3% de casos sem remoção de pelo menos um caminho explorável, 2,3% em que a falha original foi corrigida mas surgiu uma nova, e 2,2% em que ambas as coisas correram mal. Um exemplo citado de alteração indesejada de comportamento é particularmente ilustrativo: a lógica de uma verificação inverter-se silenciosamente de lista de permissões para lista de bloqueio, o que fecha o CVE e parte o produto.
Patches “frágeis”: bloquear o exploit não é corrigir a falha
O dado mais incómodo não é a taxa global, mas o modo como os modelos falham. Mais de um terço das correções classificadas nas duas categorias de sucesso foram descritas como frágeis do ponto de vista de segurança, porque bloqueavam um input malicioso específico em vez de atacar a causa-raiz no código. Num dos exemplos, relativo ao Spring AI, os modelos escapavam determinados caracteres maliciosos em vez de tratar a origem do problema, o que travava o exploit demonstrado deixando intactos caminhos de ataque alternativos.
Depois de filtrar essas correções frágeis, a proporção de patches genuinamente sólidos encolhe drasticamente: Keith Hoodlet, responsável pela Off-by-1 Labs, resumiu que “gerar um patch não é o mesmo que corrigir uma vulnerabilidade” e indicou que apenas cerca de 17% das correções da primeira categoria atacavam efetivamente a causa-raiz. A conclusão dos autores é que o valor esperado de um patch totalmente gerado por LLM e não revisto por humanos é negativo por uma margem considerável.
Dar indicações erradas é pior do que não dar nenhumas
Um dos resultados com aplicação prática imediata para equipas de desenvolvimento diz respeito ao contexto fornecido ao modelo no prompt.
| Orientação dada ao modelo | Taxa de correção bem-sucedida |
|---|---|
| Orientação de remediação correta | 65,0% |
| Nenhuma orientação | 50,4% |
| Orientação de remediação incorreta | 15,2% |
Com indicações corretas, os modelos atingiram 65,0% de sucesso; com indicações incorretas caíram para 15,2%, substancialmente pior do que não receber orientação nenhuma, cenário em que a taxa foi de 50,4%. Os autores argumentam que um programador humano a percorrer código vulnerável tem uma hipótese razoável de perceber que o enunciado está errado — os modelos não perceberam e foram ativamente desviados por ele. Traduzido para o dia a dia: um ticket de vulnerabilidade com uma hipótese errada sobre a causa contamina todo o trabalho do agente. A recomendação dos investigadores é evitar fornecer orientações de remediação incertas.
Que vulnerabilidades foram usadas no teste
Os dois modelos foram testados contra seis vulnerabilidades complexas em software aberto amplamente utilizado, incluindo Linux, Google Chrome, Apache ActiveMQ, Spring AI, Exim e Gemini CLI. De acordo com a listagem publicada pelo CSO Online a partir do estudo, os identificadores em causa são CVE-2026-31431 (“Copy Fail”), CVE-2026-34197 (execução remota de código no ActiveMQ), CVE-2026-8512, CVE-2026-45185 (RCE no Exim), CVE-2026-22738 (RCE via SpEL no Spring AI) e o RCE do Gemini CLI, com o aviso GHSA-wpqr-6v78-jr5g.
Ao estudo principal juntou-se um caso prático revelador. O freenginx, um servidor web, permite executar pequenos programas em Perl quando chega um pedido, e uma falha nessa funcionalidade — um erro de memória do tipo use-after-free — permitia a um visitante fazer o servidor ir abaixo. A equipa detetou um segundo crash, reportou-o aos responsáveis do freenginx a 29 de junho e a correção foi disponibilizada a 2 de julho.
O custo por correção e o custo escondido
O estudo analisou também o custo financeiro: em média, 2,11 dólares por tentativa de correção e ciclo de validação com o ChatGPT 5.5 e 2,81 dólares com o Claude Opus 4.8. À primeira vista é barato face ao tempo de um engenheiro. Mas os investigadores escrevem que os patches produzidos por LLM continuam a exigir revisão por um engenheiro qualificado com conhecimento do domínio, e a revisão manual que fizeram mostra porque é que essa revisão é cara: compreender uma correção ao ponto de certificar as suas implicações de segurança dá pelo menos tanto trabalho como escrever de raiz uma correção conhecidamente boa. É esse o custo que não aparece na fatura da API.
Limitações e enquadramento
Há ressalvas importantes, assumidas pelos próprios autores. Os seis CVEs foram escolhidos por serem de elevado impacto e exigirem correções complexas em múltiplos ficheiros, o que os torna mais difíceis do que uma vulnerabilidade aleatória, e os autores são diretos ao dizer que os seus números não descrevem o bug médio; os resultados são também um retrato de duas versões de modelos num dado momento.
Ainda assim, o sinal é consistente com outra investigação. Na AI Cyber Challenge da DARPA, as equipas finalistas demonstraram sistemas automáticos que detetaram 77% (54 em 70) das vulnerabilidades injetadas, mas corrigiram corretamente 61% (43 em 70). Um relatório da Veracode, citado pelo CyberScoop, concluiu que, apesar de progressos assinaláveis na escrita de código funcional, a segurança é outra história. O próprio contexto do estudo remete para a corrida atual: com modelos e sistemas agênticos a descobrir vulnerabilidades em escala, como no Project Glasswing da Anthropic, e com o anúncio em junho do Project Daybreak da OpenAI e parceiros, os defensores estão naturalmente a virar-se para agentes de IA para gerar correções. Questionada pelo CSO Online, a Anthropic terá recomendado manter humanos no circuito, defendendo que a geração de patches ultrapassou a capacidade de verificação e que a validação deve ser ancorada em execução, e não em inspeção.
Alongside do artigo, a 1Password disponibilizou os patches gerados, o conjunto de dados subjacente e o software usado para gerar, validar, comparar e verificar manualmente as correções, material destinado a ajudar as equipas a testar onde a correção assistida por IA é útil e onde a revisão humana continua necessária.
Porque é que isto importa em Portugal
Muitas organizações portuguesas estão neste momento a integrar copilotos e agentes nos seus fluxos de desenvolvimento e de gestão de vulnerabilidades, frequentemente com a expectativa de reduzir o tempo médio de correção. O estudo sugere que essa métrica pode melhorar no papel enquanto o risco real se mantém — ou piora, se o patch mascarar o exploit conhecido e deixar caminhos alternativos abertos.
O enquadramento legal reforça a exigência. O Regime Jurídico da Cibersegurança, aprovado pelo Decreto-Lei n.º 125/2025 e que transpõe a NIS2, foi publicado em Diário da República a 4 de dezembro de 2025 e transpõe a Diretiva (UE) 2022/2555, tendo entrado em vigor 120 dias depois, a 3 de abril de 2026. Para o concretizar, o CNCS publicou o Regulamento do Regime Jurídico da Cibersegurança (Regulamento n.º 756/2026, de 22 de junho). Para as entidades abrangidas, a gestão de vulnerabilidades e o tratamento de incidentes são obrigações substantivas: demonstrar conformidade implica provar que a correção foi eficaz, não apenas que foi aplicada. Um registo de “vulnerabilidade fechada” suportado por um patch que continua explorável é, na prática, uma falha de controlo interno.
Há ainda a dimensão de dados pessoais. Se uma falha mal corrigida permitir acesso indevido a dados, a organização responde perante o RGPD pela adequação das medidas técnicas implementadas, e a existência de um patch automático não revisto dificilmente servirá de defesa. Para as PME, a mensagem é mais simples: usar IA para acelerar o diagnóstico e propor hipóteses é razoável; usar IA para fechar tickets de segurança sem verificação independente não é.
O que fazer a seguir
- Manter revisão humana obrigatória sobre qualquer correção de segurança gerada por IA antes de chegar a produção, sobretudo em falhas complexas.
- Validar com exploits e não só com a suíte de testes: um patch que passa nos testes pode continuar vulnerável por outro caminho.
- Exigir que a correção elimine a causa-raiz, e não apenas o input do proof-of-concept usado na demonstração.
- Não incluir hipóteses de causa não confirmadas no prompt nem no ticket: orientação errada degrada fortemente o resultado.
- Testar regressões funcionais: cerca de um quinto das correções bem-sucedidas alterou o comportamento da aplicação.
- Documentar o processo de verificação para efeitos de conformidade e de resposta a incidentes junto do CNCS/CERT.PT.
Perguntas frequentes
Quantos patches gerados por IA falharam no estudo?
A Off-by-1 Labs avaliou 6080 correções geradas pelo ChatGPT 5.5 e pelo Claude Opus 4.8 para seis vulnerabilidades recentes em software aberto e concluiu que 53,9% falharam a correção, introduziram uma nova vulnerabilidade ou ambas; apenas 26,0% resolveram totalmente a falha sem alterar materialmente o comportamento da aplicação.
O que é um patch “frágil”?
É uma correção que aparenta funcionar porque bloqueia o exploit demonstrado, mas não elimina o código vulnerável. Mais de um terço das correções consideradas bem-sucedidas foram classificadas como frágeis, por bloquearem um input malicioso específico em vez de tratarem a causa-raiz.
Vale a pena dar contexto ao modelo sobre a vulnerabilidade?
Sim, mas apenas se o contexto estiver certo. Com orientação correta a taxa de sucesso subiu para 65,0%, sem qualquer orientação ficou em 50,4% e com orientação incorreta caiu para 15,2%.
Isto significa que não se deve usar IA para corrigir vulnerabilidades?
Não. Significa que a correção automática não deve ser autónoma. A 1Password recomenda que as organizações validem a correção assistida por IA nos seus próprios repositórios antes de adotarem fluxos automatizados e que engenheiros de segurança experientes continuem a rever todas as correções geradas por IA, sobretudo em vulnerabilidades complexas.
Esta informação tem caráter noticioso e baseia-se em dados divulgados publicamente pela Off-by-1 Labs / 1Password, pelo CNCS e por investigação académica e jornalística especializada.