在过去几天，一个新创建的GitHub仓库 (programmervuln/cveadvisory-) 引发了关注。

1. 引用的代码在那些版本中根本不存在，或引用了不相关的逻辑。
2. 测试时概念验证（PoC）有效载荷无法工作（未触发任何崩溃）。
3. 这些CVE中没有一个列在SQLite的官方安全公告页面上（该页面是追踪实际漏洞的金标准）。
4. 使用 Gptzero 测试该仓库中的所有安全公告时，均显示为AI生成内容。

将所有安全公告合并到一个文件中会触发AI生成内容警告

这促使我们质疑这些CVE的可靠性，并意识到这些CVE可能属于“AI垃圾内容”。

昨天调查其中一个CVE（CVE-2026-51302）时，我们发现Red Hat最初将其评为10.0严重等级：

今天再次查看该CVE时，我们注意到其评分已被下调至7.6（高危）。

分析矩阵

调查方法

为了彻底验证这些报告，我们建立了一个隔离的测试工作流程：

• 源代码检查： 我们克隆了官方 sqlite/sqlite 仓库，并检出了目标标签（version-3.41.0、version-3.51.2 和 version-3.51.3）。我们将报告的漏洞机制与实际源代码进行了比对。
• 干净环境构建： 在隔离的Docker容器内直接编译官方SQLite版本，以防止环境污染。
• PoC执行： 在带有地址消毒器（ASan）插桩的编译后的SQLite二进制文件中，逐字输入每个安全公告的PoC SQL语句，以检测内存错误。
• NVD与元数据审计： 评估NVD和GHSA数据源中的CPE模式和安全公告元数据，以交叉验证跟踪准确性。

详细技术分析

1. CVE-2026-51302：不存在的逻辑（9.8 严重）

报告的漏洞： 安全公告声称，当 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测试： 查询成功运行，未触发崩溃，因为该漏洞不存在。

2. CVE-2026-51303：幽灵修复（9.8 严重）

报告的漏洞： 声称 ExprListDelete() 在释放子节点时未能清除父结构中的反向引用，据称已在版本3.51.3中修补。

发现： 没有证据表明 Expr、Select 或 Window 结构中存在会导致这种状态的反向引用指针。最明显的是，3.51.2和3.51.3之间的差异显示 src/expr.c 没有任何更改。所谓的“修复”完全是捏造的。

PoC测试： 该PoC是无效SQL，在解析器阶段就失败了，从未实际进入执行逻辑。

3. CVE-2026-51300：误导性的调用点（9.1 严重）

报告的漏洞： 声称在 sqlite3ExprDelete() 中发生UAF，因为左侧表达式指针未被清除，并引用了 expr.c 中的特定行号。

发现： 引用的行号（1012 和 1026）分别是一个注释和一个内存分配调用，两者都与 pLeft 或删除逻辑无关。虽然该函数在内存不足错误处理期间被调用，但它发生在作用域的末尾，该指针从不被重用，从而防止了任何潜在的UAF。

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

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

4. CVE-2026-51297（8.8 高危）

报告的漏洞： 声称 jsonParseFree() 留下悬空引用，随后被 jsonBlobEdit() 访问。

发现： 与第一个案例类似，jsonBlobEdit() 在报告的目标版本（3.41.0）中不存在。它是在后来作为JSONB实现的一部分引入的。在目标版本中，jsonParseFree() 严格用于析构函数，其周围的结构会立即被丢弃。

PoC测试： 该PoC立即遇到格式错误的JSON错误，这意味着代码从未到达漏洞声称存在的JSON修改逻辑。

5. CVE-2026-51296：不可能的行号（7.5 高危）

报告的漏洞： 报告 jsonRemoveFunc 中存在UAF，具体在 json.c 的第3555行和第3575行。

发现： 在版本3.41.0中，src/json.c 只有2706行。引用的行号不存在。实际的函数实现在大约2000行之前被找到，对该代码的审计未发现内存管理缺陷。

PoC测试： 有效载荷在JSON解析期间失败，内存未被触及。

6. CVE-2026-51304 CVSS 7.5（高危）

报告的漏洞： 声称 sqlite3ExprListDelete(pOrderBy) 释放排序列表，而后续代码读取 pOrderBy->nExpr。

发现： 安全公告中报告的单参数签名不存在。实际的签名需要一个指向数据库上下文的指针（sqlite3 *db）。此外，SQLite在删除后立即将指针置空：

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

PoC测试： 针对包含20列的ORDER BY查询执行该PoC有效载荷，处理正常，返回排序后的结果，无任何问题。

AI垃圾内容CVE如何产生

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

从历史上看，NIST充当了这个系统的可靠安全网，国家漏洞数据库（NVD）的专家会手动分析、验证和丰富传入的CVE，然后才会给予批准。但这个安全网在 2024年2月 被打破了。

面对漏洞报告的大量激增，NIST实际上暂停了深入分析。CISA和其他授权数据发布者（ADP）试图通过自己的丰富工作来介入，但全球流程现在变得支离破碎，并被大量的积压工作所淹没。因为当今系统的任何一步都不实际要求概念验证或错误重现，一个听起来合理的假安全公告可以直接通过流程，最终进入GHSA、下游数据库和企业扫描器。

关键要点

这一事件揭示了自动化漏洞摄取的系统性问题。对55份安全公告的更广泛审计……

识别垃圾内容CVE的危险信号：

• 缺少供应商佐证： 官方维护者安全页面（例如 sqlite.org/cves.html）未提及该问题。
• 缺少提交历史： 参考字段中没有关联提交哈希或拉取请求。
• 元数据矛盾： 空的CPE产品定义或与安全公告叙述冲突的版本范围。
• 不存在的代码引用： 引用在声称的目标版本中不存在的函数或超出文件结尾（EOF）的行号。

这些由LLM生成的垃圾内容CVE可能导致组织浪费时间调查和修补实际不存在的漏洞，并污染漏洞数据库。在关键漏洞被自动优先处理或根据漏洞评分开启工单的环境中，这些捏造的CVE可能成为真正的负担。

在使用AI自动化漏洞分类和修复的环境中，这变得更加令人担忧。遇到捏造的CVE的AI代理可能会尝试定位有漏洞的函数、生成补丁，或基于甚至不存在的代码推荐更改。它非但不能帮助安全团队修复真正的漏洞，反而可能将他们引向完全错误的道路，可能导致不必要的更改并浪费时间。

为避免受到此类漏洞噪音的影响：

• 不要盲目信任新发布的CVE。调查此类关键CVE以了解评分是否与漏洞匹配。
• 检查您的环境是否真的受到该CVE的影响。
• 尽可能在安全环境中使用提供的PoC重现报告的问题。

已报告的发现

我们也已正式将这些发现报告给GHSA、Redhat和NVD，以协助修复这些记录。