O Centro Nacional de Cibersegurança dos Países Baixos (NCSC) passou cinco dias dizendo a organizações que se preocupassem com uma falha que nunca existiu. Em 29 de julho, o NCSC publicou o aviso NCSC-2026-0268, alertando sobre a CVE-2026-51302, uma falha de corrupção de memória no SQLite 3.41 que carregava uma classificação de severidade de até 10 em 10. Na segunda-feira, a agência retirou o aviso com uma única linha adicionada, dizendo que a CVE havia sido retratada e que a vulnerabilidade muito provavelmente foi alucinada por um grande modelo de linguagem.

O desmonte da história está documentado pela equipe de pesquisa de segurança da JFrog, que rastreou a CVE até uma conta do GitHub chamada programmervuln, que havia publicado 55 avisos de vulnerabilidade do SQLite. A auditoria da JFrog constatou que 54 eram completamente fabricados e que um continha um bug real embrulhado em metadados de CVE não verificados. As fabricações não eram nada sutis quando alguém finalmente olhou de perto. Funções citadas nos avisos não existem nas versões do SQLite mencionadas, os números de linha referenciados apontam para além do fim dos arquivos, os payloads de prova de conceito não derrubaram nada quando executados sob AddressSanitizer, e nenhuma das CVEs aparece na própria página de vulnerabilidades do SQLite. O texto em si disparou alertas da ferramenta de detecção de IA GPTZero.

O que importa é até onde a ficção viajou antes que alguém verificasse. O formulário público de submissão de CVEs do MITRE não realiza nenhuma verificação real de identidade, então a conta conseguiu obter pelo menos seis identificadores CVE, com quatro classificados como críticos ou altos, incluindo dois com pontuação 9.8 e um com 9.1. O NIST reduziu a análise manual de submissões após um pico no acúmulo de pendências no início de 2024, o que removeu a camada que talvez tivesse detectado o caso. A partir daí, as pontuações fluíram automaticamente para os bancos de dados que scanners de vulnerabilidade, verificadores de dependências e equipes nacionais de resposta consomem. Nos Países Baixos, o pipeline terminou em um aviso governamental orientando organizações a aplicar correções.

O SQLite é um alvo de pior caso para esse tipo de poluição porque está entre os softwares mais amplamente implantados do mundo, embutido em navegadores, celulares, sistemas operacionais e incontáveis aplicações. Uma pontuação crítica contra ele garante atenção. Os pesquisadores da JFrog descreveram o custo sem rodeios, escrevendo que essas CVEs de lixo gerado por LLM podem fazer organizações desperdiçarem tempo investigando e corrigindo vulnerabilidades que na verdade não existem, além de poluir os bancos de dados de vulnerabilidades. Esse custo foi pago em horas reais, por equipes de segurança que triaram os alertas e por uma agência nacional que emitiu um aviso e depois teve de voltar atrás.

A retratação em si é a parte saudável da história, e as verificações que finalmente flagraram a farsa, ler o código-fonte, executar o exploit, consultar a página de segurança do próprio fornecedor, são exatamente as que o pipeline pulou no caminho de entrada. A assimetria é o problema que permanece. Um modelo de linguagem pode produzir um aviso convincente em segundos, enquanto refutar um deles exigiu dos pesquisadores horas de verificação manual por alegação. O sistema de CVEs foi construído sobre a suposição de que relatos de vulnerabilidade são submetidos de boa fé, e essa suposição agora precisa sobreviver ao contato com ferramentas capazes de fabricar ficção confiante e bem formatada em escala.