伪造的 SQLite CVE：LLM 生成的漏洞“垃圾”兴起
A 系列针对 SQLite 的严重漏洞公告最近被发现是“LLM slop”——由 AI 生成的伪造报告，它们引用了不存在的代码并提供了无法运行的漏洞验证（PoC）载荷。尽管这些是虚假的，但这些 CVE 最初被国家漏洞数据库（NVD）和 CISA 的授权数据发布者（ADPs）标记为严重，凸显了当前漏洞验证流程中的危险缺口。
伪造的 SQLite 漏洞
JFrog 安全研究人员调查了一批由 GitHub 仓库 (programmervuln/cveadvisory-) 发布的一系列 SQLite 公告。他们的审计显示，该账号发布的 55 个公告中有 54 个是完全伪造的。
幻觉 CVE 的分析
研究人员使用了一个隔离的测试工作流，涉及官方 SQLite 源码检查、干净的 Docker 构建以及 AddressSanitizer (ASan) 插桩，以验证这些说法。结果显示出一致的 AI 幻觉模式：
| CVE | 报告的缺陷 | 发现结果 |
|---|---|---|
| CVE-2026-51302 | exprComputeOperands() 中的 UAF |
exprComputeOperands() 函数在目标版本 (3.41.0) 中并不存在。 |
| CVE-2026-51303 | ExprListDelete() 中的 UAF |
版本 3.51.3 中报告的“补丁”是伪造的；在 3.51.2 和 3.51.3 之间，src/expr.c 中没有任何更改。 |
| CVE-2026-51300 | sqlite3ExprDelete() 中的 UAF |
引用的行号指向了一个注释和一个内存分配调用，与报告的缺陷无关。 |
| CVE-2026-51297 | 通过 jsonBlobEdit() 导致的 UAF |
jsonBlobEdit() 函数在目标版本 (3.41.0) 中并不存在。 |
| CVE-2026-51296 | jsonRemoveFunc 中的 UAF |
引用的行号超过了源文件的总长度 (src/json.c)。 |
| CVE-2026-51304 | 通过 pOrderBy->nExpr 导致的 UAF |
报告的函数签名不正确，且代码在删除后明确地将指针置为空。 |
在每一个案例中，提供的 PoC SQL 语句要么在解析阶段失败，要么成功执行但未触发任何内存错误。
CVE 验证中的系统性失败
伪造报告能够获得严重级别评分（例如 Red Hat 最初分配给 CVE-2026-51302 的 10.0 分）这一事实，指向了漏洞摄取流程的崩溃。
NVD 安全网的崩溃
从历史上看，国家漏洞数据库（NVD）会手动分析和验证传入的 CVE。然而，在 2024 年 2 月，由于报告数量激增，NIST 暂停了深度分析。这导致了流程的碎片化，其中：
- 缺乏验证： 当前的提交过程没有任何步骤要求提供功能性的漏洞验证（PoC）或缺陷重现。
- 自动化摄取： 听起来合理的虚假公告可以未经人类验证就直接进入 GHSA 和企业级扫描器。
- 身份匿名性： MITRE 的公开提交表单缺乏严格的身份验证，允许任何人提出 CVE 和 CVSS 评分。
对安全运营的影响
伪造的 CVE 会给组织和维护者带来巨大的运营开销和安全风险：
- 资源浪费： 安全团队浪费时间调查和修复不存在的漏洞。
- 数据库污染： 漏洞数据库被“噪音”填满，使其更难识别真正的严重威胁。
- AI 驱动的错误修复： 用于自动化分拣的 AI 代理可能会尝试修复不存在的函数，从而可能在生产代码中引入真实的缺陷。
- 维护者负担： 开源维护者被迫花费时间去揭穿幻觉，而不是修复真正的安全缺陷。
如何识别“Slop” CVE
为了避免被伪造的公告误导，安全专业人员应该寻找以下红旗（预警信号）：
- 缺乏厂商协同验证： 该问题未在官方维护者安全页面（例如
sqlite.org/cves.html）上提及。 - 缺乏提交记录： 在引用字段中没有链接的 commit hash 或 pull request。
- 元数据矛盾： CPE 产品定义为空，或者版本范围与公告的叙述逻辑冲突。
- 不存在的代码引用： 公告引用了在指定软件版本中不存在的函数或行号。
ypt: "body": "# 伪造的 SQLite CVE：LLM 生成的漏洞“垃圾”兴起\n\nA 系列针对 SQLite 的严重漏洞公告最近被发现是“LLM slop”——由 AI 生成的伪造报告，它们引用了不存在的代码并提供了无法运行的漏洞验证（PoC）载荷。尽管这些是虚假的，但这些 CVE 最初被国家漏洞数据库（NVD）和 CISA 的授权数据发布者（ADPs）标记为严重，凸显了当前漏洞验证流程中的危险缺口。\n\n## 伪造的 SQLite 漏洞\n\nJFrog 安全研究人员调查了一批由 GitHub 仓库 (programmervuln/cveadvisory-) 发布的一系列 SQLite 公告。他们的审计显示，该账号发布的 55 个公告中有 54 个是完全伪造的。\n\n### 幻觉 CVE 的分析\n\n研究人员使用了一个隔离的测试工作流，涉及官方 SQLite 源码检查、干净的 Docker 构建以及 AddressSanitizer (ASan) 插桩，以验证这些说法。结果显示出一致的 AI 幻觉模式：\n\n| CVE | 报告的缺陷 | 发现结果 |\n| :--- | :--- | :--- |\n| CVE-2026-51302 | exprComputeOperands() 中的 UAF | exprComputeOperands() 函数在目标版本 (3.41.0) 中并不存在。 |\n| CVE-2026-51303 | ExprListDelete() 中的 UAF | 版本 3.51.3 中报告的“补丁”是伪造的；在 3.51.2 和 3.51.3 之间，src/expr.c 中没有任何更改。 |\n| CVE-2026-51300 | sqlite3ExprDelete() 中的 UAF | 引用的行号指向了一个注释和一个内存分配调用，与报告的缺陷无关。 |\n| CVE-2026-51297 | 通过 jsonBlobEdit() 导致的 UAF | jsonBlobEdit() 函数在目标版本 (3.41.0) 中并不存在。 |\n| CVE-2026-51296 | jsonRemoveFunc 中的 UAF | 引用的行号超过了源文件的总长度 (src/json.c)。 |\n| CVE-2026-51304 | 通过 pOrderBy->nExpr 导致的 UAF | 报告的函数签名不正确，且代码在删除后明确地将指针置为空。 |\n\n在每一个案例中，提供的 PoC SQL 语句要么在解析阶段失败，要么成功执行但未触发任何内存错误。\n\n## CVE 验证中的系统性失败\n\n伪造报告能够获得严重级别评分（例如 Red Hat 最初分配给 CVE-2026-51302 的 10.0 分）这一事实，指向了漏洞摄取流程的崩溃。\n\n### NVD 安全网的崩溃\n\n从历史上看，国家漏洞数据库（NVD）会手动分析和验证传入的 CVE。然而，在 2024 年 2 月，NIST 暂停了深度分析，由于报告数量激增。这导致了流程的碎片化，其中：\n* 缺乏验证： 当前的提交过程没有任何步骤要求提供功能性的漏洞验证（PoC）或缺陷重现。\n* 自动化摄取： 听起来合理的虚假公告可以未经人类验证就直接进入 GHSA 和企业级扫描器。\n* 身份匿名性： MITRE 的公开提交表单缺乏严格的身份验证，允许任何人提出 CVE 和 CVSS 评分。\n\n## 对安全运营的影响\n\n伪造的 CVE 会给组织和维护者带来巨大的运营开销和安全风险：\n\n* 资源浪费： 安全团队浪费时间调查和修复不存在的漏洞。\n* 数据库污染： 漏洞数据库被“噪音”填满，使其更难识别真正的严重威胁。\n* AI 驱动的错误修复： 用于自动化分拣的 AI 代理可能会尝试修复不存在的函数，从而可能在生产代码中引入真实的缺陷。\n* 维护者负担： 开源维护者被迫花费时间去揭穿幻觉，而不是修复真正的安全缺陷。\n\n## 如何识别“Slop” CVE\n\n为了避免被误导 by 伪造的公告，安全专业人员应该寻找以下红旗（预警信号）：\n\n* 缺乏厂商协同验证： 该问题未在官方维护者安全页面（例如 sqlite.org/cves.html）上提及。\n* 缺乏提交记录： 在引用字段中没有链接的 commit hash 或 pull request。\n* 元数据矛盾： CPE 产品定义为空，或者版本范围与公告的叙述逻辑冲突。\n* 不存在的代码引用： 公告引用了在指定软件版本中不存在的函数或行号。\n\n## 社区观点\n\n行业观察者对安全报告中信号与噪音比例下降的问题表示了担忧。一些贡献者指出，虽然 LLM 可以发现真实的缺陷，但缺乏验证机制为通过虚假报告进行“大规模攻击”创造了途径。\n\n> "LLMs are text-prediction engines. They are not Artificial Intelligence, and shouldn’t not be treated in any form or fashion as if they possess intelligence... Now, we all pay the consequence, to the tune of hundreds of thousands if not millions of dollars of wasted productivity。"\n\n其他人也警告说，目前这种“输出机器”先于“验证机器”构建的趋势对于软件开发来说是不可持续的。\n
Sources
相关
- Dispatch
- Dispatch
- Dispatch
- Dispatch
- Dispatch