CVE falsos, relatórios gerados por IA e a necessidade de verificação

Está ficando mais barato criar relatórios de vulnerabilidade convincentes, o que aumenta as consequências para quem mantém softwares e para as equipes de segurança. Seis vulnerabilidades e exposições comuns (CVEs) foram divulgadas contra o SQLite em julho de 2026, e duas delas receberam uma pontuação de gravidade de 9,8. Os relatórios pareciam legítimos: descreviam falhas de segurança de memória e incluíam explicações técnicas e código de prova de conceito.

Mas os pesquisadores da JFrog descobriram que algumas das funções mencionadas nos relatórios não existiam nas versões afetadas. Além disso, nenhuma das provas de conceito (PoCs) reproduziu as vulnerabilidades alegadas. A própria página de CVEs do SQLite informa atualmente que esses seis relatórios não correspondem a bugs; os registros de CVE foram posteriormente rejeitados.

O problema vai além do SQLite. Daniel Stenberg, responsável pela manutenção do curl, estimou no ano passado que cerca de 20% dos relatórios de segurança recebidos eram resultado de conteúdo de baixa qualidade gerado por IA. A Autoridade de Numeração de CVEs (CNA) do GitHub recebeu quase 4.000 solicitações de CVE em maio de 2026: um aumento de cerca de 10 vezes no volume em relação ao ano anterior. O GitHub não atribuiu esse aumento à IA nem apontou uma queda na qualidade das submissões, mas o enorme crescimento do volume evidencia a sobrecarga no processo de divulgação de vulnerabilidades.

A IA facilita a criação de alegações detalhadas sobre vulnerabilidades, mas determinar se elas são legítimas exige tempo. E, quando uma CVE entra em feeds de segurança e bancos de dados públicos, corrigir o registro original não significa automaticamente que todas as cópias também serão corrigidas. Isso torna cada vez mais necessário distinguir uma vulnerabilidade relatada de uma vulnerabilidade verificada tecnicamente.

O que é uma CVE “falsa”?

As pessoas costumam usar o termo “CVE falsa” para se referir a uma CVE que provavelmente foi relatada de forma incorreta. Mas “falsa” não significa que houve intenção de enganar. O erro pode decorrer de uma análise estática que não detecta uma verificação de validação ou interpreta equivocadamente uma entrada como sendo controlada por um invasor. Um relatório pode descrever uma função real, mas alegar uma via de ataque inválida. Um identificador (ID de CVE) pode ser atribuído e, mais tarde, descartado se a condição relatada não for, de fato, uma vulnerabilidade. Isso é diferente de um relatório deliberadamente fictício.

Uma contestação também não é uma CVE falsa. Um fornecedor pode contestar as conclusões de um pesquisador sobre a possibilidade de exploração, os limites de ameaça ou se uma função deveria processar dados não confiáveis. Mas uma contestação não prova que o pesquisador errou. E rejeitar uma CVE não significa necessariamente que ela foi inventada: ela pode ser rejeitada por ser duplicada ou por motivos administrativos. Embora um identificador de CVE não constitua uma verificação técnica independente, o setor precisa levar a sério os relatórios legítimos.

Por que as CVEs falsas são um problema

Um dos problemas que estamos observando é o uso de IA para gerar relatórios de vulnerabilidade sem validar devidamente as conclusões. Esses relatórios podem incluir explicações técnicas detalhadas, referências a código e até PoCs, o que pode fazê-los parecer legítimos. Mas, como vimos com as CVEs do SQLite, algumas das funções mencionadas nem sequer existiam nas versões afetadas.

O GitHub relatou um aumento significativo no número de submissões de vulnerabilidades em 2026, embora não tenha atribuído esse aumento à IA nem informado uma queda na qualidade das submissões. A preocupação é que, à medida que aumenta o número de relatórios, também cresce o trabalho necessário para investigá-los, independentemente de as conclusões serem legítimas ou não.

Para quem já fez a triagem de relatórios de vulnerabilidade, é fácil reconhecer a dificuldade prática. Um modelo de IA pode identificar uma chamada de API suspeita, esboçar um cenário de exploração e gerar rapidamente um relatório com aparência profissional. Determinar se esse cenário é viável pode exigir a verificação da versão exata, o rastreamento do fluxo de controle, a compreensão de como os dados chegam à função, a criação de um ambiente de teste e a execução do suposto exploit. O processo é o mesmo, independentemente de o relatório estar correto ou não, e isso pode custar caro.

As CVEs falsas também podem causar danos à reputação. Um anúncio de vulnerabilidade pode se espalhar rapidamente por feeds de scanners, bancos de dados de segurança e resultados de busca. No entanto, uma correção subsequente talvez não alcance o mesmo público. Mesmo depois de um relatório ser contestado ou rejeitado, os fornecedores podem ter de se defender perante clientes que viram o relatório original.

Há também o risco de vulnerabilidades legítimas passarem despercebidas ou terem sua investigação atrasada porque as equipes estão ocupadas analisando relatórios incorretos. Quando quem mantém os softwares e as equipes de segurança dispõem de recursos limitados, cada hora dedicada a refutar um falso positivo é uma hora que poderia ter sido usada para investigar um problema de segurança real.

Reagir com automação

Muitos investigadores ainda fazem a triagem manualmente para lidar com a nova enxurrada de relatórios, mas essa abordagem não é sustentável. A automação tem se mostrado uma grande aliada na verificação de alegações de vulnerabilidade em relação à versão e à configuração realmente afetadas. Estas são as cinco perguntas a fazer:

• Os pré-requisitos para o ataque são plausíveis, inclusive no que diz respeito à configuração e às permissões?
• A suposta função existe na versão afetada?
• Um invasor consegue acessar o código vulnerável? Determine se o código em questão pode ser executado nas condições afetadas e se um invasor pode fornecer uma entrada que chegue até ele.
• Os testadores conseguem reproduzir o comportamento em um teste controlado ou com uma PoC?
• O comportamento observado apresenta o impacto à segurança descrito no comunicado?

Ferramentas baseadas em agentes podem criar ambientes de teste, analisar caminhos de execução no código, gerar PoCs e registrar evidências de execução para análise. Elas não conseguem verificar automaticamente todas as alegações. Mesmo quando uma vulnerabilidade é autêntica, uma PoC pode falhar se o ambiente estiver incompleto ou se o gatilho estiver incorreto. Os testadores podem reproduzir uma falha sem comprovar a explorabilidade alegada. Essas ressalvas explicam por que o julgamento humano continua sendo crucial. Ainda assim, essas ferramentas podem ajudar as equipes a chegar mais perto de uma resposta reproduzível antes que um relatório consuma ainda mais tempo das equipes de engenharia, gestão de vulnerabilidades e suporte ao cliente.

Como lidar com a sobrecarga no ecossistema de CVEs

Nenhuma política concisa resolverá magicamente o problema das CVEs falsas. Mas seria útil exigir evidências mais robustas nas submissões e deixar mais claro o status da reprodução. Também ajudaria estabelecer um tratamento mais claro para registros contestados e corrigir mais rapidamente os dados derivados. Os pesquisadores devem ser incentivados a validar suas descobertas obtidas com auxílio de IA antes de submetê-las.

As equipes de segurança e os fornecedores devem se concentrar em examinar as evidências. Uma pontuação crítica de CVE não revela se o caminho vulnerável pode ser alcançado no ambiente deles. O fato de uma PoC falhar não significa que está tudo bem. E receber um ID de CVE não isenta as equipes do trabalho técnico necessário para compreender um problema.

A IA está ampliando a capacidade de descobrir vulnerabilidades e também possibilitando a criação de alegações convincentes, mas incorretas. Em um cenário de proliferação de relatórios, as organizações precisam investir em verificação. Isso envolve criar testes, reproduzir resultados, verificar pressupostos e facilitar a avaliação das evidências. Esta é uma área em que os testes de segurança baseados em agentes podem desempenhar um papel importante.