幻覺 SQLite CVEs：漏洞報告中 LLM Slop 的興起

LLM 生成的虛假 CVEs 目標指向 SQLite

最近針對 SQLite 的安全公告被識別為「LLM slop」——由人工智慧生成的捏造漏洞，但仍被國家漏洞資料庫 (NVD) 和 CISA 的授權數據發布者 (ADP) 標記為關鍵等級。JFrog 安全研究人員發現，一個 GitHub 儲存庫 (programmervuln/cveadvisory-) 發布了一批超過 50 個 CVEs，其中絕大多數完全是虛假的，包括數個針對 SQLite 的高嚴重性報告。

捏造證據

JFrog 通過嚴格的測試工作流程驗證了這些 CVEs 的虛假性，該流程涉及對官方 SQLite 標籤的原始碼檢視、在 Docker 中的乾淨環境構建，以及在 AddressSanitizer (ASan) 下執行 PoC。調查揭示了四種主要的幻覺模式：

1. 不存在的代碼引用

幾份公告引用了在目標 SQLite 版本中不存在的函數或行號。例如，CVE-2026-51302 聲稱 exprComputeOperands() 中存在漏洞，但該函數直到 2025 年中才被添加到 SQLite 中，遠晚於所報告的版本 3.41.0。同樣，CVE-2026-51296 引用了 src/json.c 中超過文件實際長度的行號。

2. 捏造的修補程式

CVE-2026-51303 聲稱在版本 3.51.3 中實施了修復。然而，版本 3.51.2 與 3.51.3 之間的 diff 顯示相關文件 (src/expr.c) 沒有任何變動，證明該「修補程式」完全是捏造的。

3. 無效的 PoC 載荷

公告中提供的概念驗證 (PoC) SQL 語句無法觸發崩潰或記憶體錯誤。在某些情況下，PoCs 是無效的 SQL，在解析器階段就失敗了，從未達到它們聲稱要針對的執行邏輯。

4. 邏輯上的不可能

在 CVE-2026-51304 中，公告聲稱在列表被釋放後發生了使用後釋放 (UAF) 錯誤。原始碼分析顯示，SQLite 明確地在刪除後立即將指標歸零 (pPrior->pOrderBy = 0)，使得後續的解引用在設計上是不可能的。

CVE 流程的系統性失效

此事件突顯了全球漏洞報告基礎設施中的一個關鍵漏洞。目前的系統允許聽起來合理的虛假公告到達企業級掃描器，主要歸因於兩個因素：

• 缺乏身份驗證： MITRE 公開提交表單不要求身份驗證，允許任何人提出 CVE 和 CVSS 分數。
• 「NVD 安全網」的崩潰： 從歷史上看，NIST 專家會手動驗證並豐富 CVEs。然而，自 2024 年 2 月以來，報告數量的大幅激增導致 NIST 暫停了深度分析，使得流程變得支離破碎，且缺乏強制性的概念驗證或重現步驟。

對安全運維的影響

捏造的 CVEs 為安全團隊和維護者帶來了顯著的運維負擔：

• 浪費資源： 組織浪費時間調查和修補不存在的錯誤，特別是當自動化系統根據 CVSS 分數觸發高優先級的工單時。
• 維護者倦怠： 專案維護者必須花時間拆解幻覺，而非修復真正的錯誤。
• AI Triage 風險： 用於自動化修復的 AI 代理可能會嘗試「修補」不存在的函數，從而可能將真正的錯誤引入代碼庫。

社群洞察與反對觀點

Hacker News 上的行業觀察者指出，這種趨勢降低了信噪比，使得識別合法威脅變得更加困難。一些貢獻者對此表示擔憂，認為這可能是更具惡意的攻擊的前兆：

"Not validating submissions seems like avenue for massive attack. Flood the whole system with endless false reports. Thus making it significantly less reliable."

其他人則指出，使用 AI 生成的內容來報告 AI 生成的 slop，這本身就是一種諷刺，並提到這些工具的泛濫使得產生了一種「隨機性」，人類的專業知識正被被同質化、機率性的缺陷所取代。

如何識別「Slop」CVEs

為了避免在捏造的漏洞中浪費資源，安全團隊應尋找以下紅旗指標：

• 沒有供應商證實： 問題未出現在官方維護者的安全頁面（例如，sqlite.org/cves.html）。
• 缺少 Commit History： 參考欄位中沒有連結的 commit hash 或 pull requests。
• 元數據矛盾： CPE 產品定義為空，或者版本範圍與公告敘述不符。
• 不可能的引用： 公告引用了在指定版本中不存在的函數或行號。