安全公司 JFrog 调查一个新 GitHub 账号发布的 55 条漏洞通告后称，其中 54 条完全伪造，只有一条包含真实缺陷却仍混有未经验证的 CVE 元数据。部分针对 SQLite 的通告曾被 NVD 标为高危或严重，CISA 的补充数据也进入了下游记录。

一句话结论：AI 没有攻破 SQLite，却已经能用足够像真的函数名、行号和 PoC 污染漏洞流水线；CVE 编号只负责标识一项公开声明，不等于漏洞已经被维护者或数据库复现。

JFrog 选取六项 SQLite 通告，检出的问题非常具体：有的引用目标版本里尚未出现的函数，有的给出超出源文件长度的行号，有的声称某版本包含修复，但对应文件在两个版本之间根本没有变化。研究人员用官方源码构建目标版本，启用 AddressSanitizer 运行原样 PoC，没有复现所称崩溃。

例如 CVE-2026-51302 把一个后来才加入的函数写进 SQLite 3.41.0，并把寄存器编号复用描述成堆内存释放。CVE-2026-51303 所谓补丁则不存在，PoC 甚至在 SQL 解析阶段就失败。问题不是研究结论有争议，而是报告中的代码事实本身无法成立。

这些通告仍能获得编号并进入自动化系统，是因为当前流程分工不同。CVE 体系允许授权机构分配标识，NVD、CISA ADP 和各安全平台再补充评分、产品映射和版本范围。编号分配并不天然包含维护者确认、可运行 PoC 或独立复现。积压和自动化越严重，格式完整的假报告越容易向下游扩散。

SQLite 官方长期提醒，第三方 CVE 并不一定代表核心团队判断，许多通告还默认攻击者已经能执行任意 SQL。即使一个缺陷真实存在，应用是否暴露恶意 SQL 或不受信任数据库文件，仍决定实际风险。现在又多了一层：通告描述本身可能是编造的。

对企业最危险的不是多开几张工单。自动修复 Agent 可能根据不存在的函数生成补丁，安全团队也可能为虚假严重漏洞紧急升级关键系统。治理办法不该是拒绝所有新 CVE，而是对陌生提交者、无维护者链接和无法复现的高危报告增加隔离状态。

关键事实

• 调查范围：同一 GitHub 账号发布的 55 条漏洞通告
• JFrog 结论：54 条被判定为完全伪造，1 条含真实缺陷但元数据未验证
• SQLite 核验：六项通告出现不存在的函数、错误行号、虚构修复和失效 PoC
• 当前状态：JFrog 已向 GHSA、Red Hat 和 NVD 报告调查结果

OC 判断

CVE 应被看成索引，不是安全认证。漏洞管理平台需要把“已分配编号”“数据库已补充”“维护者确认”和“第三方复现”显示为不同状态。AI 让通告产量变高之后，复现证据必须重新成为高危排序的入口条件。

为什么重要

• 对开发者：不要因扫描器报出严重 CVE 就盲目修改代码，先核对受影响路径和维护者记录。
• 对安全团队：自动开票可以保留，但自动升级和自动补丁应等待可复现证据。
• 对开源维护者：需要一条能快速标记错误归属和虚假通告的公开纠错通道。

参考来源

• JFrog: SQLite Critical CVEs or LLM Slops?
• SQLite: Vulnerabilities
• SQLite: Defense Against The Dark Arts
• NVD: CVE-2026-51302