SQLite Critical CVEs or LLM Slop?
SQLite Critical CVEs or LLM Slop?
SQLite 的严重漏洞是真实的还是 AI 生成的垃圾信息？
Afek Berger, JFrog Security Researcher | 30 Jul, 2026 Afek Berger，JFrog 安全研究员 | 2026年7月30日
Over the past few days, a newly created GitHub repo (programmervuln/cveadvisory-) published a batch of SQLite vulnerability advisories (as part of other 50+ CVEs which we believe are also LLM slop except from one). 在过去几天里，一个新创建的 GitHub 仓库 (programmervuln/cveadvisory-) 发布了一批 SQLite 漏洞公告（这是 50 多个 CVE 中的一部分，我们认为除了其中一个外，其余均为 LLM 生成的垃圾信息）。
NVD quickly flagged these as critical, and CISA’s ADP agreed. But when JFrog security researchers dug in to verify, the claims fell apart: The cited code didn’t even exist in those versions or referenced unrelated logic. When testing the PoC payloads they didn’t work (not triggering any crash). NVD（美国国家漏洞数据库）迅速将这些漏洞标记为“严重”，CISA 的 ADP 也表示认同。但当 JFrog 的安全研究人员深入核实时，这些声明便站不住脚了：所引用的代码在这些版本中根本不存在，或者引用了无关的逻辑。在测试 PoC（概念验证）载荷时，它们也无法生效（未触发任何崩溃）。
None of these CVEs are listed on SQLite’s official advisory page (which is a gold standard for tracking actual vulnerabilities). All advisories in this repo seem AI generated when testing them with Gptzero. Combining all advisories into one file triggers AI-generated content warnings. This made us question the reliability of these CVEs as well as understanding that these CVEs may be LLM slop. 这些 CVE 均未出现在 SQLite 的官方公告页面上（该页面是追踪实际漏洞的黄金标准）。使用 Gptzero 测试时，该仓库中的所有公告似乎都是 AI 生成的。将所有公告合并为一个文件会触发 AI 生成内容的警告。这让我们质疑这些 CVE 的可靠性，并意识到它们很可能是 LLM 生成的垃圾信息。
While investigating one of the CVEs yesterday, CVE-2026-51302, we saw that Red Hat initially assigned it a 10.0 Critical severity score: Looking at the CVE again today, we noticed that the score has since been downgraded to 7.6 High. 昨天在调查其中一个漏洞 CVE-2026-51302 时，我们发现红帽（Red Hat）最初将其严重性评分定为 10.0（严重）：今天再次查看该 CVE 时，我们注意到评分已被下调至 7.6（高危）。
Analysis Matrix / 分析矩阵
| CVE | Reported Flaw / 报告的缺陷 | CVSS | NVD Metadata / 元数据 | Audit Finding / 审计发现 |
|---|---|---|---|---|
| CVE-2026-51302 | UAF in exprComputeOperands() | 9.8 CRITICAL | Pinned CPE: 3.41.0 | The advisory mentions non-existing functions. / 公告提到了不存在的函数。 |
| CVE-2026-51303 | UAF in ExprListDelete() back-refs | 9.8 CRITICAL | Contradictory metadata | The advisory said there are non-existent fixes. / 公告称存在不存在的修复。 |
| CVE-2026-51300 | UAF in sqlite3ExprDelete() | 9.1 CRITICAL | n/a placeholders | Advisory cited lines that are unrelated to the vulnerability. / 公告引用的行与漏洞无关。 |
| CVE-2026-51297 | UAF via jsonBlobEdit() | 8.8 HIGH | Pinned CPE: 3.41.0 | The advisory mentions non-existing functions. / 公告提到了不存在的函数。 |
| CVE-2026-51296 | UAF in jsonRemoveFunc | 7.5 HIGH | Populated CPE: 3.41.0 | Advisory cited lines that do not exist. / 公告引用的行不存在。 |
| CVE-2026-51304 | UAF via pOrderBy->nExpr post-free | 7.5 HIGH | Vendor/Product: n/a | Advisory showed a real function with a wrong argument number. / 公告展示了一个真实函数，但参数数量错误。 |
Investigation Methodology / 调查方法
- Source Inspection: We cloned the official sqlite/sqlite repository and checked out the target tags (version-3.41.0, version-3.51.2, and version-3.51.3). We compared the reported vulnerability mechanics against the actual source code. 源码检查： 我们克隆了官方的 sqlite/sqlite 仓库，并检出了目标标签（version-3.41.0, version-3.51.2 和 version-3.51.3）。我们将报告的漏洞机制与实际源代码进行了对比。
- Clean Environment Build: Compiled the official SQLite releases directly inside isolated Docker containers to prevent environmental contamination. 纯净环境构建： 在隔离的 Docker 容器中直接编译官方 SQLite 发行版，以防止环境污染。
- PoC Execution: Feed each advisory’s PoC SQL statements verbatim into the compiled SQLite binaries under AddressSanitizer (ASan) instrumentation to detect memory bugs. PoC 执行： 将每份公告的 PoC SQL 语句逐字输入到编译好的 SQLite 二进制文件中，并在 AddressSanitizer (ASan) 插桩下运行，以检测内存错误。
- NVD & Metadata Audit: Evaluated the CPE patterns and advisory metadata across NVD and GHSA feeds to cross-check tracking accuracy. NVD 与元数据审计： 评估 NVD 和 GHSA 订阅源中的 CPE 模式和公告元数据，以交叉核对追踪的准确性。
Detailed Technical Breakdown / 详细技术分析
1. CVE-2026-51302: Non-Existent Logic (9.8 Critical) 1. CVE-2026-51302：不存在的逻辑 (9.8 严重)
- Reported Vulnerability: The advisory claims a heap use-after-free occurs when sqlite3ReleaseTempReg() leaves a dangling pointer in regFree1, which is later dereferenced by exprComputeOperands(). 报告的漏洞： 公告声称当 sqlite3ReleaseTempReg() 在 regFree1 中留下悬空指针，随后被 exprComputeOperands() 解引用时，会发生堆释放后使用 (UAF) 错误。
- Finding: The primary issue here is that exprComputeOperands() didn’t exist in SQLite 3.41. It was added in the middle of 2025 (commits e24f20a, 280559b). Furthermore, the mechanics of sqlite3ReleaseTempReg() do not involve heap deallocation. The function simply recycles register indices into an array for reuse, making a UAF impossible by design. 发现： 主要问题在于 exprComputeOperands() 在 SQLite 3.41 中根本不存在。它是在 2025 年年中添加的（提交记录 e24f20a, 280559b）。此外，sqlite3ReleaseTempReg() 的机制并不涉及堆内存释放。该函数只是将寄存器索引回收进数组以供重用，因此从设计上讲，UAF 是不可能发生的。
2. CVE-2026-51303: Ghost Fixes (9.8 Critical) 2. CVE-2026-51303：幽灵修复 (9.8 严重)
- Reported Vulnerability: Claims that ExprListDelete() fails to clear back-references in parent structures when releasing child nodes, allegedly patched in version 3.51.3. 报告的漏洞： 声称 ExprListDelete() 在释放子节点时未能清除父结构中的反向引用，据称已在 3.51.3 版本中修复。
- Finding: There is no evidence of back-reference pointers in the Expr, Select, or Window structures that could lead to such a state. Most tellingly, a diff between 3.51.2 and 3.51.3 shows absolutely no changes to src/expr.c. The “patch” was entirely fabricated. 发现： 在 Expr、Select 或 Window 结构中没有任何证据表明存在可能导致此类状态的反向引用指针。最能说明问题的是，3.51.2 和 3.51.3 之间的差异对比显示 src/expr.c 没有任何变化。所谓的“补丁”完全是捏造的。
3. CVE-2026-51300: Misdirected Call Sites (9.1 Critical) 3. CVE-2026-51300：错误的调用点 (9.1 严重)
- Reported Vulnerability: Claims a UAF occurs in sqlite3ExprDelete() because a left-hand expression pointer is not cleared, referencing specific line numbers in expr.c. 报告的漏洞： 声称在 sqlite3ExprDelete() 中发生了 UAF，因为左侧表达式指针未被清除，并引用了 expr.c 中的特定行号。
- Finding: The cited line numbers (1012 and 1026) are a comment and a memory allocation call respectively, neither has anything to do with pLeft or deletion logic. While the function is called during OOM error handling, it occurs at the end of a scope where the pointer is never reused, preventing any potential UAF. 发现： 引用的行号（1012 和 1026）分别是注释和内存分配调用，两者都与 pLeft 或删除逻辑无关。虽然该函数在 OOM（内存不足）错误处理期间被调用，但它发生在作用域的末尾，此时指针从未被重用，从而避免了任何潜在的 UAF。
4. CVE-2026-51297 (8.8 High) 4. CVE-2026-51297 (8.8 高危)
- Reported Vulnerability: Claims jsonParseFree() leaves dangling references that are later accessed by jsonBlobEdit(). 报告的漏洞： 声称 jsonParseFree() 留下了悬空引用，随后被 jsonBlobEdit() 访问。
- Finding: Similar to the first case, jsonBlobEdit() was not present in the reported target version (3.41.0). It was only introduced later as part of the JSONB implementation. In the target version, jsonParseFree() is used strictly in destructors where the surrounding structure is immediately discarded. 发现： 与第一个案例类似，jsonBlobEdit() 在报告的目标版本 (3.41.0) 中并不存在。它是在后来作为 JSONB 实现的一部分引入的。在目标版本中，jsonParseFree() 严格用于析构函数中，此时周围的结构会被立即丢弃。
5. CVE-2026-51296: Impossible Line Numbers (7.5 High) 5. CVE-2026-51296：不可能的行号 (7.5 高危)
- Reported Vulnerability: Reports a UAF in jsonRemoveFunc specifically at lines 3555 and 3575 of json.c. 报告的漏洞： 报告称在 jsonRemoveFunc 中发生了 UAF，具体位于 json.c 的第 3555 行和 3575 行。
- Finding: In version 3.41.0, src/json.c is only 2706 lines long. 发现： 在 3.41.0 版本中，src/json.c 总共只有 2706 行。