在过去几天中，新创建的GitHub仓库（programmervuln/cveadvisory-）发布了一批SQLite漏洞建议（作为其他50多个CVE的一部分，我们相信这些也是LLM垃圾，除了一个）。NVD迅速将这些标记为严重，CISA的ADP也表示同意。但当JFrog的安全研究人员深入验证时，这些说法崩溃了：引用的代码在这些版本中根本不存在或引用了不相关的逻辑。当测试PoC有效载荷时，它们没有成功（没有触发任何崩溃）。这些CVE都没有列在SQLite的官方建议页面上（这是跟踪实际漏洞的黄金标准）。在用Gptzero测试这些建议时，发现所有建议似乎都是AI生成的。将所有建议合并成一个文件会触发AI生成内容警告。这让我们质疑这些CVE的可靠性，并意识到这些CVE可能是LLM垃圾。昨天在调查CVE-2026-51302时，我们看到Red Hat最初将其评为10.0的严重程度：今天再次查看该CVE时，我们注意到该评分已降至7.6。CVE报告缺陷CVSS NVD元数据审计发现CVE-2026-51302在exprComputeOperands()中的UAF 9.8严重 Pin 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高 Pin CPE：3.41.0 该建议提到不存在的函数。CVE-2026-51296在jsonRemoveFunc中的UAF 7.5高 Populated CPE: 3.41.0 建议引用的行不存在。CVE-2026-51304通过pOrderBy->nExpr后释放的UAF 7.5高 供应商/产品：不适用，建议显示了一个真实函数，但参数数量错误。为了彻底验证这些报告，我们建立了一个独立的测试工作流程：源代码检查：我们克隆了官方的sqlite/sqlite仓库并检出了目标标签（version-3.41.0，version-3.51.2和version-3.51.3）。我们将报告的漏洞机制与实际源代码进行了比较。干净环境构建：在隔离的Docker容器内直接编译官方SQLite版本，以防止环境污染。PoC执行：将每个建议的PoC SQL语句逐字输入编译后的SQLite二进制文件中，并在AddressSanitizer（ASan）插装下检测内存错误。NVD和元数据审核：评估NVD和GHSA馈送中的CPE模式和建议元数据，以交叉检查跟踪的准确性。报告漏洞：该建议声称在sqlite3ReleaseTempReg()中发生堆用后释放，当regFree1中留下一个悬空指针后，exprComputeOperands()会对其进行反引用。发现：主要问题在于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测试：查询成功执行，没有触发崩溃，因为该错误并不存在。报告漏洞：声称ExprListDelete()在释放子节点时未能清除父结构中的反向引用，声称在版本3.51.3中修复。发现：没有证据表明在Expr、Select或Window结构中存在反向引用指针，这可能会导致这种状态。最明显的是，3.51.2和3.51.3之间的diff显示src/expr.c没有任何变化。该“补丁”完全是捏造的。PoC测试：该PoC是无效的SQL，在解析阶段失败，实际上未触及执行逻辑。报告漏洞：声称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测试：成功执行，返回预期输出，没有内存泄漏或错误。报告漏洞：声称jsonParseFree()留下悬空引用，随后被jsonBlobEdit()访问。发现：类似