Reed's News
← 返回精选

SQLite 虚假 CVE：LLM 垃圾信息如何污染漏洞库

Tech 83 ymir_e 2026/8/3 1230 字 原文 ↗

近日，GitHub上一个新建仓库（programmervuln/cveadvisory-）发布了一批SQLite漏洞公告（该仓库共声称发现50余个CVE，除1个外其余均为大语言模型生成的无效内容）。NVD迅速将这些漏洞标记为严重级别，CISA的授权数据发布方（ADP）也予以认可。但JFrog安全研究员深入验证后发现，这些漏洞声明完全站不住脚：

  • 公告中提及的代码要么不存在于对应版本，要么指向无关逻辑
  • 测试提供的PoC（概念验证） payload时，未触发任何崩溃，完全无效
  • 这些CVE均未出现在SQLite官方漏洞公告页面（该页面是追踪真实漏洞的权威标准）
  • 用Gptzero检测后发现，仓库中所有公告似乎都是AI生成的

将所有公告合并为一个文件时，触发了AI生成内容预警

这让我们对这些CVE的可靠性产生质疑，也确认它们属于大语言模型生成的无效内容（LLM slop）。

昨日我们调查其中一个漏洞CVE-2026-51302时发现，Red Hat最初为其评定的CVSS（通用漏洞评分系统）得分为10.0，属于最高级别的"严重"：

今日再次查看该CVE时，发现其评分已被下调至7.6，为"高危"级别。

CVE编号 报告漏洞描述 CVSS评分 NVD元数据情况 审计发现
CVE-2026-51302 exprComputeOperands()函数存在UAF（释放后使用）漏洞 9.8 严重 绑定CPE：3.41.0 公告提及的函数不存在
CVE-2026-51303 ExprListDelete()函数存在引用释放后指针的UAF漏洞 9.8 严重 元数据自相矛盾 公告声称的修复措施完全不存在
CVE-2026-51300 sqlite3ExprDelete()函数存在UAF漏洞 9.1 严重 存在占位符缺失 公告引用的代码行与漏洞无关
CVE-2026-51297 通过jsonBlobEdit()触发UAF漏洞 8.8 高危 绑定CPE：3.41.0 公告提及的函数不存在
CVE-2026-51296 jsonRemoveFunc函数存在UAF漏洞 7.5 高危 已填充CPE：3.41.0 公告引用的代码行不存在
CVE-2026-51304 通过pOrderBy->nExpr释放后引用触发UAF漏洞 7.5 高危 厂商/产品信息缺失 公告展示的真实函数参数数量错误

为全面验证这些报告，我们建立了一套隔离测试流程：

  • 源码检查：克隆SQLite官方仓库，检出目标版本标签（version-3.41.0、version-3.51.2、version-3.51.3），将报告中的漏洞机制与实际源码对比
  • 纯净环境编译：在隔离的Docker容器中直接编译SQLite官方版本，避免环境干扰
  • PoC测试：将公告中的PoC SQL语句原封不动输入经AddressSanitizer（ASan，内存错误检测工具）插桩的SQLite二进制文件，检测内存漏洞
  • NVD及元数据审计：评估NVD和GHSA（GitHub安全公告）中的CPE（通用平台枚举）模式与公告元数据，交叉验证追踪准确性

CVE-2026-51302验证详情

报告漏洞：公告称sqlite3ReleaseTempReg()函数会在regFree1中留下悬空指针，后续被exprComputeOperands()函数引用，导致堆内存释放后使用（UAF）。 审计发现：核心问题在于，exprComputeOperands()函数在SQLite 3.41版本中根本不存在，它是2025年年中才新增的（对应提交记录：e24f20a、280559b）。此外，sqlite3ReleaseTempReg()的实现逻辑不涉及堆内存释放，只是将寄存器索引回收到数组中复用，从设计上就不可能产生UAF漏洞。

/* expr.c:6562, SQLite 3.41.0 */
void sqlite3ReleaseTempReg(Parse *pParse, int iReg){
if( iReg ){
sqlite3VdbeReleaseRegisters(pParse, iReg, 1, 0, 0);
if( pParse->nTempReg < ArraySize(pParse->aTempReg) ){
pParse->aTempReg[pParse->nTempReg++] = iReg;
}
}
}

PoC测试结果：查询成功执行，未触发任何崩溃，证明漏洞不存在。

CVE-2026-51303验证详情

报告漏洞：公告称ExprListDelete()函数释放子节点时未清除父结构中的引用指针，据称已在3.51.3版本中修复。 审计发现：Expr、Select或Window结构中不存在可能导致此类问题的引用指针。更关键的是，对比3.51.2与3.51.3版本的代码，src/expr.c文件完全没有变化，所谓的"修复"纯属捏造。 PoC测试结果：PoC是无效SQL语句，在解析阶段就失败，根本无法进入执行逻辑。

CVE-2026-51300验证详情

报告漏洞：公告称sqlite3ExprDelete()函数未清除左侧表达式指针，导致UAF漏洞，并引用了expr.c文件中的具体行号。 审计发现：被引用的行号（1012和1026）分别是注释和内存分配调用，与pLeft指针或删除逻辑完全无关。虽然该函数会在内存不足（OOM）错误处理时被调用，但调用发生在作用域末尾，指针不会被再次使用，不可能产生UAF漏洞。

/* expr.c:1330, SQLite 3.41.0 */
void sqlite3ExprDelete(sqlite3 *db, Expr *p){
if( p ) sqlite3ExprDeleteNN(db, p);
}

PoC测试结果：作为有效SQL查询成功执行，返回预期结果，未出现内存泄漏或错误。

CVE-2026-51297验证详情

报告漏洞：公告称jsonParseFree()函数会留下悬空引用，后续被jsonBlobEdit()函数访问，导致UAF漏洞。 审计发现：与第一个案例类似，jsonBlobEdit()函数在报告提及的目标版本（3.41.0）中不存在，它是后续为实现JSONB功能才新增的。在目标版本中，jsonParseFree()仅在析构函数中使用，且相关结构会被立即丢弃。 PoC测试结果：PoC触发了格式错误的JSON报错，代码根本无法进入所谓存在漏洞的JSON修改逻辑。

CVE-2026-51296验证详情

报告漏洞：公告称jsonRemoveFunc函数在json.c文件的3555和3575行存在UAF漏洞。 审计发现：在3.41.0版本中，src/json.c文件仅有2706行，被引用的行号根本不存在。该函数的实际实现位置大约在2000行处，审计后未发现内存管理缺陷。 PoC测试结果：payload在JSON解析阶段失败，未触及相关内存区域。

CVE-2026-51304验证详情

报告漏洞：公告称sqlite3ExprListDelete(pOrderBy)函数释放排序列表后，后续代码仍会读取pOrderBy->nExpr，导致UAF漏洞。 审计发现：公告中提到的单参数函数签名不存在，实际函数需要传入数据库上下文指针（sqlite3 *db）。此外，SQLite会在删除后立即将指针置空：

/* select.c:3761, SQLite 3.41.0 */
sqlite3ExprListDelete(db, pPrior->pOrderBy);
pPrior->pOrderBy = 0; /* 指针立即置空，无法被引用 */

PoC测试结果：针对20列ORDER BY查询的payload正常执行，返回排序后的结果，未出现任何问题。

通过MITRE公开表单提交CVE的流程缺乏真实身份验证，几乎任何人都可以提交漏洞描述并建议CVSS评分。

过去，美国国家标准与技术研究院（NIST）曾是这一体系的可靠安全屏障：国家漏洞数据库（NVD）的专家会对提交的CVE进行人工分析、验证和补充，确认无误后才会批准发布。但这道屏障在2024年2月失效了。

由于漏洞报告数量激增，NIST实际上暂停了深度分析工作。CISA及其他授权数据发布方（ADP）试图接手补充工作，但全球漏洞处理流程现已碎片化，且积压了大量待处理报告。如今的流程中，没有任何环节要求提交者提供PoC或漏洞复现步骤，因此看似合理的虚假公告可以轻易通过审核，进入GHSA、下游数据库和企业扫描工具。

此次事件暴露了漏洞自动收录机制的系统性问题。我们对该GitHub账号发布的55份公告进行全面审计后发现，其中54份完全是伪造的，仅1份包含真实漏洞，但附带的CVE元数据未经验证。

识别AI生成无效CVE的警示信号

  • 缺乏厂商确认：官方维护者的安全页面（如sqlite.org/cves.html）未提及相关问题
  • 无提交记录：参考字段中未关联任何提交哈希或拉取请求
  • 元数据矛盾：CPE产品定义为空，或版本范围与公告描述冲突
  • 代码引用不存在：提及的函数在目标版本中不存在，或引用的行号超出文件范围

这些AI生成的无效CVE会导致企业浪费时间去调查和修复根本不存在的漏洞，还会污染漏洞数据库。在严重漏洞自动优先处理或根据漏洞评分自动创建工单的环境中，此类伪造CVE会成为实实在在的负担。

如果环境中使用AI自动进行漏洞分类和修复，问题会更严重：AI代理遇到伪造CVE时，可能会尝试定位不存在的漏洞函数、生成补丁或建议修改不存在的代码，不仅无法帮助安全团队修复真实漏洞，还会引导他们走入歧途，可能引入不必要的变更并浪费时间。

避免受此类无效漏洞干扰的建议

  • 不要盲目信任未知或未验证来源发布的新CVE
  • 对严重级别CVE进行调查，确认评分是否与漏洞实际情况匹配
  • 检查自身环境是否真的受该CVE影响
  • 尽可能在安全环境中用提供的PoC复现报告的问题

我们已正式向GHSA、Red Hat和NVD报告上述发现，协助他们修正相关记录。