編按：本文綜合整理自 JFrog Security Research 原文、OSS-Sec 郵件列表與 MITRE CVE Project 變更紀錄，並加入 Siami 編輯部觀點與分析。
過去一週，一個名為 programmervuln/cveadvisory- 的 GitHub 帳號向 MITRE 提交了超過 50 份 CVE 漏洞報告，其中 6 份鎖定 SQLite、CVSS 評分最高達 9.8 Critical。NVD 與 CISA ADP 短時間內核准並發布，紅帽端甚至一度給出 10.0 滿分。JFrog 研究團隊實際反編 SQLite 原始碼、編譯乾淨環境跑 PoC，發現這些報告全部是 LLM 內容農場（LLM slop）：引用的函式在該版本根本不存在、PoC 跑起來完全沒當、連 line 行號都指向錯的地方。最具話題性的是 CVE-2026-51302，從 10.0 一路被降回 7.6 High。
事件始末：一次 AI 編造的漏洞海嘯
一次可疑的 GitHub 提交
JFrog 在 8 月 2 日注意到這個 GitHub 帳號，該帳號在幾天內設立、立刻發出 50+ 份 CVE 報告。其中 6 份瞄準 SQLite 3.41.0、3.51.2、3.51.3 三個版本，宣稱發現 use-after-free（UAF）漏洞。NVD 不到 24 小時內把這些 CVE 標記為 Critical，CISA ADP 也跟進。
SQLite 官方漏洞追蹤頁（sqlite.org/cves.html）是業界公認的「黃金來源」，但這些 CVE 沒有一個出現在該頁面上。
JFrog 動手反編驗證
JFrog 的驗證 SOP 包含四個步驟：
- 原始碼檢查：clone 官方
sqlite/sqlite並 checkout 對應版本 tag，比對漏洞描述與原始碼。 - 乾淨環境建置：在隔離 Docker 容器內編譯官方 SQLite release，避免環境污染。
- PoC 執行：把每份報告的 PoC SQL 字串丟進 AddressSanitizer（ASan）編譯的 SQLite binary，看會不會真的崩潰。
- NVD 與 GHSA metadata 稽核：交叉比對 CPE 模式與 advisory 描述。
結果：6 個漏洞全部不存在
研究的結論是這 6 個 CVE 全部不可重現：
- 引用的函式在該版本中根本不存在（例如
exprComputeOperands()是在 2025 年中才加進 SQLite）。 - 引用
json.c第 3555、3575 行，但 3.41.0 版本json.c總共只有 2706 行。 - 報告聲稱 3.51.3 修了某個 bug，但 diff 顯示
src/expr.c完全沒動。 - 全部 PoC 跑起來都沒當機，輸出正常結果。
JFrog 進一步用 GPTZero 掃描整批報告，發現全部都有 AI 生成內容的特徵；把多份報告合併時，AI 偵測器明確標示為「機器撰寫」。
6 個被拆穿的假 CVE 一覽
| CVE 編號 | 聲稱漏洞 | 原始 CVSS | JFrog 稽核發現 |
|---|---|---|---|
| CVE-2026-51302 | exprComputeOperands() UAF | 9.8 Critical | 該函式在 3.41 不存在 |
| CVE-2026-51303 | ExprListDelete() 反向引用 | 9.8 Critical | 3.51.2→3.51.3 expr.c 無任何改動 |
| CVE-2026-51300 | sqlite3ExprDelete() 洩漏 | 9.1 Critical | 引用行號 1012 / 1026 是 comment 與 malloc |
| CVE-2026-51297 | jsonBlobEdit() UAF | 8.8 High | 該函式在 3.41.0 尚未引入 |
| CVE-2026-51296 | jsonRemoveFunc UAF | 7.5 High | 引用行號超過檔案結尾 |
| CVE-2026-51304 | pOrderBy->nExpr UAF | 7.5 High | 函式簽章根本不正確 |
最具代表性的是 CVE-2026-51302。報告聲稱 sqlite3ReleaseTempReg() 會留 dangling pointer 給 exprComputeOperands()，但實際上 sqlite3ReleaseTempReg() 內部只把 register index 放回陣列供未來重用，不會做 heap 釋放。附上的 PoC 跑起來沒有任何 ASan 警告。
為什麼這件事重要
這不只是「某人亂送 CVE」的笑話，而是整套漏洞管理體系的信任危機。
NIST 經費縮減打開的破口
JFrog 直接點名事件根源：2024 年 2 月 NIST 宣布 NVD 計畫轉型，當時 NVD 每年手動驗證數千個 CVE，但面對暴增的 CVE 申報量，NVD 進入「暫停深入分析」狀態。CISA 與其他 Authorized Data Publishers（ADP）接手補位，但分散式審查累積成巨大 backlog，沒有任何一關要求附上可重現的 PoC。
- MITRE 公開提交表單沒有身份驗證
- CVE Numbering Authority（CNA）通常用榮譽制度運作
- 整條 pipeline 沒有強制要求 bug 復現步驟
一篇寫得「看起來像」漏洞報告的 LLM 農場文，能一路滑進 GHSA、下游資料庫、企業漏洞掃描器，全部不擋。
自動化修補反而變成攻擊面
更危險的是，當企業開始用 AI agent 自動 triage 與 patch 漏洞時：
- AI 看到一份「Critical CVE-2026-XXXXX」會嘗試定位被引用的函式
- 不存在的函式 → AI 自己猜測結構 → 生成錯誤的 patch
- 程式碼被改壞，反而引入新漏洞
Siami 編輯部看法：漏洞管理不能完全外包給自動化。企業導入 AI 修補流程前，必須先建立「Critical CVE 人工覆核」機制，否則一份假報告就能繞過整個防禦鏈。
數據解讀：假 CVE 的數量比你想的多
JFrog 檢視了該 GitHub 帳號總共 55 份報告：
- 54 份完全虛構
- 1 份包含真實 bug，但 CVE metadata 不可信
也就是說 98.2% 的內容是 LLM 農場，僅 1.8% 勉強找到可運作的真實問題。MITRE 已在事件後整批 reject 該帳號提交的 CVE（見 cvelistV5 commit 6a1b7cf）。
對照前一年 Google 「Big Sleep」AI 自主發現 SQLite CVE-2025-6965 的成功案例，同樣是 LLM 處理漏洞，差距竟如此懸殊——一個是「AI 發現真實漏洞並阻止被利用」，另一個是「AI 編造假漏洞並污染資料庫」。漏洞管理的兩面都已經被 LLM 強力介入。
怎麼辨識 LLM Slop CVE
JFrog 整理出 4 個紅旗指標，資安團隊可拿來過濾新進 CVE：
- 缺乏原廠背書：官方的 security advisory 頁（例如 SQLite 的
cves.html）完全沒提到這個 CVE。 - 沒有 commit hash 或 PR 連結：reference 欄位空空如也。
- metadata 自相矛盾：CPE 產品欄位空著，或版本範圍跟漏洞敘述對不上。
- 引用不存在的程式碼：函式在該版本沒出現、行號超過檔案結尾、或指向 comment 行。
實務建議流程：
- 對未知 / 未驗證來源發布的 Critical CVE 一律人工複查
- 確認 CVSS 分數與漏洞描述相符
- 評估自家環境是否真的受影響
- 在隔離環境跑原始 PoC，看能不能真的崩潰
業界討論與後續處置
Hacker News 社群（連結 49154332）對事件的討論聚焦在三個方向：
- 「script-kiddie 2.0」現象：沒受過軟體工程訓練的人靠 LLM 做出「自己無法理解」的東西。
- NIST 預算的政治問題：有用戶直接點名「NIST 經費被砍是直接原因」。
- 強制 patch 政策的困境：受合規要求必須 patch 所有 Critical CVE 的企業，會被這類假報告嚴重影響。
OSS-Sec 郵件列表中 Oracle 工程師 Alan Coopersmith 公開指出：MITRE 與多數 CNA 對自己不生產的程式碼核發 CVE 時，是基於榮譽制度相信提交者已驗證，因為 CNA 本身往往缺乏經費或環境去重現每份報告。
JFrog 已正式將審查結果通報給 GHSA、Red Hat 與 NVD；紅帽端的 CVE-2026-51302 已從 10.0 下調為 7.6 High。事件發生後，圍繞「LLM 對漏洞 pipeline 的雙面效應」的辯論在資安圈持續發酵。
參考來源
- JFrog Security Research 原始報告：https://research.jfrog.com/post/sqlite-critical-cves-or-llm-slops/
- OSS-Sec 郵件列表「Rejected CVE reports against SQLite, libraw, ESP32-audioI2S」：https://seclists.org/oss-sec/2026/q3/373
- MITRE CVE Project 整批 reject 紀錄：https://github.com/CVEProject/cvelistV5/commit/6a1b7cf5b6c9d917e51a0c9f2d3419fe5f27fde4
- SQLite 官方漏洞追蹤頁：https://sqlite.org/cves.html
- Hacker News 討論串：https://news.ycombinator.com/item?id=49154332
- NIST NVD 2024 年 2 月公告（背景脈絡）：https://nvd.nist.gov/general/news/nvd-program-transition-announcement
網友熱門留言 (5)