Patches Incompletos em CVEs Open Source: Por Que Corrigir uma Vulnerabilidade Pode Não Ser Suficiente

O Problema que a Gestão de Vulnerabilidades Prefere Ignorar

Existe uma lógica sedutora no fluxo de trabalho de segurança tradicional: uma CVE aparece, o time aplica o patch indicado no registro, e o ticket vai para fechado. Simples, rastreável, auditável. O problema é que essa lógica assume que toda correção de segurança chega em um único commit — e uma pesquisa recente da Universidade do Texas em Dallas mostra que isso está longe de ser sempre verdade.

Os pesquisadores analisaram 1.646 CVEs de projetos open source cadastradas no National Vulnerability Database (NVD) entre 1999 e 2025 que exigiam mais de um commit para ser completamente corrigidas. Esse conjunto representa cerca de um em cada quinze registros de CVEs com patch vinculado na base. O número pode parecer pequeno, mas o impacto operacional é desproporcional: cada um desses casos possui uma janela de exposição entre o primeiro e o último commit, durante a qual o software continua vulnerável — mesmo que o time de segurança acredite ter concluído a remediação.

Como uma Vulnerabilidade Exige Múltiplos Patches

A pesquisa classificou os casos de correção multi-patch em três categorias distintas, cada uma com sua própria dinâmica de risco.

1. Vulnerabilidades em Múltiplos Locais do Código

A categoria mais comum, com 830 registros, envolve falhas que existem em mais de um lugar simultaneamente. O mesmo padrão de código vulnerável aparece em branches diferentes, métodos distintos ou até em projetos separados que compartilham uma base comum. Como o Git não consegue aplicar um único commit a todos os branches ao mesmo tempo, o mantenedor precisa portar a correção manualmente para cada local afetado. O ImageMagick, que mantém várias linhas de release ativas em paralelo, precisou de mais de um commit para quase um terço de todas as suas correções de segurança — exatamente por causa dessa necessidade de portabilidade entre versões.

2. Correções Agrupadas com Trabalho Não Relacionado

Uma segunda categoria agrupa a mudança de segurança com outros commits adjacentes: um workaround temporário aplicado antes da correção definitiva, uma atualização de changelog ou documentação commitada separadamente. Tecnicamente, o código ainda está exposto até que todos os commits do grupo estejam aplicados.

3. Patches Defeituosos — O Risco Mais Crítico

A terceira categoria é a mais perigosa e, ao mesmo tempo, a mais difícil de detectar: 641 registros envolvem correções incompletas ou incorretas, onde o primeiro patch resolve apenas parte da vulnerabilidade ou introduz um novo bug no processo. Um exemplo concreto do estudo ilustra bem essa situação.

A CVE-2012-0038, um integer overflow no sistema de arquivos XFS do Linux, foi corrigida com um primeiro commit que adicionava uma verificação de bounds. O problema: essa verificação dependia de uma função auxiliar que retornava um inteiro sem sinal, mas o código o tratava como inteiro com sinal — o que permitia contornar a checagem completamente. Um segundo commit, 18 dias depois, corrigiu o tipo da variável e fechou a brecha de verdade. Durante quase três semanas, o sistema estava tecnicamente corrigido segundo o registro da CVE, mas ainda explorável na prática.

As Ferramentas de Detecção Automática Falham Nesse Cenário

Se o problema já é grave em termos de processo, a situação piora quando se considera o desempenho das ferramentas automatizadas de detecção de vulnerabilidades nesse contexto específico.

Os pesquisadores testaram sete modelos de detecção — incluindo CodeBERT, UniXcoder, LineVul, Devign e ReVeal — sobre o conjunto de correções incompletas. A tarefa era simples: classificar o código como vulnerável ou corrigido. O resultado foi alarmante: todos os modelos ficaram abaixo de 50% em acurácia e F1, o que os autores descrevem como desempenho pior do que uma escolha aleatória.

A explicação técnica é direta: um patch de segurança modifica apenas uma fatia pequena do código. Os modelos tendem a atribuir o mesmo rótulo às versões pré-correção, intermediária e pós-correção de uma função, porque as diferenças são sutis demais para o padrão que aprenderam a reconhecer.

Weiliang Qi, co-autor do estudo, explicou a decisão de não testar ferramentas comerciais: como os casos de teste vêm de registros públicos de vulnerabilidades, produtos proprietários podem já ter assinaturas para as mesmas CVEs, o que tornaria impossível distinguir generalização genuína de memorização. Mas Qi também foi direto sobre as expectativas: a maioria das ferramentas comerciais opera com técnicas de correspondência de assinaturas e padrões de código, abordagens essencialmente similares às dos modelos testados — o que sugere limitações parecidas em cenários de correções incompletas ou multi-localização.

Detectores de código clonado também enfrentaram dificuldades. As ferramentas ReDebug e FIRE foram usadas para identificar sites vulneráveis adicionais a partir da assinatura do primeiro patch. A taxa de verdadeiros positivos do FIRE caiu de 90 para cerca de 52 nesse cenário, porque os trechos vulneráveis em locais diferentes divergem o suficiente para escapar da assinatura construída a partir do primeiro caso.

A Janela de Exposição e o Risco Real

O timing é onde o risco teórico se torna operacional. Quase 32% dos casos multi-patch levam mais de 24 horas entre o primeiro e o último commit. Correções que precisam ser portadas entre branches ou projetos diferentes tendem a ter os maiores atrasos.

Esse intervalo cria uma corrida. Quando um branch recebe uma correção pública, qualquer pessoa com acesso ao repositório — incluindo agentes maliciosos — pode ler o diff, identificar o padrão da vulnerabilidade e procurar o mesmo problema nos branches ainda não corrigidos. A CVE-2023-4226, uma falha de upload arbitrário de arquivos no Chamilo LMS, seguiu exatamente esse caminho: um workaround foi publicado primeiro, e a correção definitiva chegou 16 dias depois.

Qi foi cuidadoso ao delimitar o que os dados provam: o estudo mede a janela de exposição, não a atividade de atacantes. Não há evidência direta de exploração durante esses intervalos nos casos analisados. Mas o pesquisador traçou um paralelo relevante com a reutilização de código entre projetos — uma classe de risco que a comunidade de segurança já trata com seriedade e para a qual ferramentas como VUDDY, MOVERY e FIRE foram desenvolvidas. Patches multi-localização dentro de um único projeto seguem um padrão análogo.

Ruído nos Próprios Registros de Patches

Além dos problemas de detecção e timing, a pesquisa identificou uma terceira camada de complexidade: os próprios registros de patches introduzem ruído nos dados. Cerca de 5,8% dos casos multi-patch incluem commits sem papel de segurança — edições de README, bumps de versão, arquivos de teste — o que eleva o custo de qualquer análise automatizada baseada nesses dados.

Um caso específico, a CVE-2022-2522, manteve no registro um commit que era apenas o pai do commit de segurança real, mesmo após um usuário apontar o erro e o mantenedor recusar a correção. Ferramentas de análise que reconstroem estados vulneráveis a partir da reversão de patches herdam esse ruído — e reverter um commit intermediário pode produzir um estado híbrido com características tanto do código vulnerável quanto do corrigido, confundindo qualquer modelo de classificação.

O Que Isso Significa na Prática para Desenvolvedores e Times de Segurança

O estudo não invalida o processo padrão de gestão de vulnerabilidades — ele funciona bem para a maioria dos casos. Mas para uma parcela significativa das CVEs em projetos open source, tratar o primeiro patch vinculado como o fim da remediação é um erro estrutural.

• CVEs de alta severidade com um único commit vinculado merecem uma verificação de commits de acompanhamento antes de fechar o ticket.
• Verificar a qual branch o patch pertence e se outros branches ativos foram igualmente corrigidos é uma etapa que frequentemente falta nos fluxos de trabalho automatizados.
• Projetos com múltiplas linhas de release simultâneas têm probabilidade estatisticamente maior de exigir correções multi-patch.
• Ferramentas de análise de composição de software e scanners de vulnerabilidade precisam evoluir para lidar com estados intermediários de correção, não apenas com o binário vulnerável ou corrigido.

O rótulo de um registro no NVD marca o início da remediação para uma fatia relevante das vulnerabilidades open source. O código — e o histórico de commits ao redor dele — carrega o restante da história.