荷兰国家网络安全中心 (NCSC) 花了五天时间提醒各机构警惕一个根本不存在的漏洞。7月29日，NCSC发布安全通告NCSC-2026-0268，就CVE-2026-51302发出警告，称SQLite 3.41中存在一个内存破坏漏洞，其严重性评分最高达10分（满分10分）。本周一，该机构撤回了这份通告，仅补充了一句说明：该CVE已被撤销，这个漏洞极有可能是大语言模型凭空捏造的。

整个真相的揭开由JFrog的安全研究团队记录在案。该团队将这个CVE追溯到一个名为programmervuln的GitHub账户，该账户曾发布55份SQLite漏洞通告。JFrog的审计发现，其中54份完全是凭空捏造，另外1份虽包含一个真实漏洞，却被包裹在未经验证的CVE元数据之中。只要有人真正去核查，这些造假并不难识破：通告中引用的函数在所指的SQLite版本中并不存在，引用的代码行号超出了文件末尾，所谓的概念验证载荷在AddressSanitizer下运行时没有触发任何崩溃，而且这些CVE没有一个出现在SQLite官方的漏洞页面上。通告文本本身还触发了AI检测工具GPTZero的警报。

真正值得关注的是，这则虚构信息在有人核查之前走了多远。MITRE的公开CVE提交表单不进行任何实质性的身份验证，因此该账户得以获取至少6个CVE编号，其中4个被评为严重或高危，包括两个评分9.8和一个评分9.1。NIST在2024年初积压激增之后缩减了对提交内容的人工分析，这就撤掉了本来或许能拦下此事的那道防线。此后，这些评分自动流入了漏洞扫描器、依赖检查工具和各国应急响应团队所依赖的数据库。在荷兰，这条链路的终点是一份要求各机构打补丁的政府通告。

对于这类污染而言，SQLite是最糟糕的攻击目标，因为它是全球部署最广泛的软件之一，被嵌入浏览器、手机、操作系统和无数应用程序之中。针对它的高危评分必然引发关注。JFrog的研究人员直言其代价，写道这些由LLM炮制的垃圾CVE会让各机构浪费时间去调查和修补实际上并不存在的漏洞，同时还会污染漏洞数据库。这一代价是用真实的工时支付的：安全团队要对这些警报进行分诊排查，而一个国家级机构发布了警告之后又不得不将其收回。

撤回本身是这个故事中健康的一面，而最终揭穿骗局的那些核查手段，即阅读源代码、运行漏洞利用程序、查看厂商自己的安全页面，恰恰是这条链路在入口处跳过的环节。留下来的问题是这种不对称：语言模型几秒钟就能生成一份足以乱真的通告，而研究人员要证伪一份通告，每条论断都需要数小时的动手验证。CVE体系建立在漏洞报告出于善意提交的假设之上，而这一假设如今必须经受住这样一类工具的考验，它们能够大规模制造自信满满、格式规范的虚构内容。