AI幻覺漏洞報告攻陷開源界：SQLite 六個重大 CVE 全是假的
事件日期：2026 年 7 月 30 日｜發稿日期：2026 年 8 月 5 日
不能直接相信。2026 年 7 月 30 日，JFrog 安全研究團隊實測證實，NVD 上六個 SQLite「重大漏洞」的技術內容是 AI 生成的幻覺：引用的函式在該版本不存在、宣稱的修補從沒發生、附上的攻擊程式碼跑不出任何崩潰。
後面會一直用到幾個縮寫：CVE（漏洞編號）、NVD（收錄這些編號的公共漏洞資料庫）、CVSS（隨編號給出的嚴重度分數，本次事件中 9.8 被標為 CRITICAL、7.5 被標為 HIGH）、PoC（報告者附上、用來證明漏洞可被觸發的驗證程式）。這幾個詞的細部定義屬業界通用說法，不在 JFrog 這份報告的敘述範圍內，各機構的官方文件才是權威出處；本文只使用 JFrog 報告中實際出現的用法。
這件事值得台灣中小企業老闆花十分鐘讀完，因為它示範了一個新的花錢陷阱：一份看起來完整、有編號、有評分、有公共資料庫背書的資安報告，內容可以整份是空的。
SQLite 那六個「重大漏洞」是真的嗎？
不是真的。JFrog 逐一比對原始碼與實際執行 PoC 後，六份報告全部被推翻。SQLite 是那種你平常不會注意到、卻塞在瀏覽器、手機 App 與嵌入式裝置裡跑的資料庫引擎，所以「SQLite 出現 9.8 分重大漏洞」這種消息會瞬間引發整個產業的更新動員。
事情從一個新開的 GitHub 帳號開始。JFrog 指出，帳號 programmervuln/cveadvisory- 在數日內發布了一批 SQLite 漏洞公告，而這只是該帳號送出的 50 多個 CVE 的一部分——JFrog 認為除了其中一個之外，其餘同樣是 AI 生成的無效內容。
| 時間 | 發生什麼 |
|---|---|
| 過去數日內 | 新建 GitHub 帳號批次發布 SQLite 漏洞公告，屬同批 50+ CVE 之一 |
| 隨即（JFrog 原文用「quickly」） | NVD 標記為 Critical，CISA 的 ADP 機制表示同意 |
| 7 月 29 日 | JFrog 調查 CVE-2026-51302 時，看到 Red Hat 給出 10.0 Critical |
| 7 月 30 日 | JFrog 公開查核結果，六份報告的技術內容全數不成立；同日再看，該分數已下修至 7.6 High |
最關鍵的一條旁證：這些編號沒有任何一個出現在 SQLite 官方漏洞公告頁。JFrog 直接把該頁形容為追蹤 SQLite 真實漏洞的黃金標準。官方沒認，第三方資料庫卻標成重大，這個落差本身就是警報。
JFrog 是怎麼證明這些 CVE 是假的？
用四道實體檢驗，不靠推論。JFrog 建了一套隔離測試流程：clone 官方 sqlite/sqlite 原始碼庫、切到報告指名的版本標籤（version-3.41.0、3.51.2、3.51.3）、在 Docker 容器裡乾淨編譯官方釋出版、然後把每份公告的 PoC SQL 語句原封不動餵進去，全程掛上 AddressSanitizer 監控記憶體錯誤。
JFrog 明講 AddressSanitizer（ASan）在這套流程裡的角色是「偵測記憶體錯誤」的檢測層（工具本身的完整原理請以其官方文件為準）。這六份公告宣稱的全都是 UAF（use-after-free，使用已釋放記憶體）類型的漏洞，掛著這層檢測跑 PoC，結果是沒有任何一個觸發崩潰。
三個最有代表性的破口：
CVE-2026-51302（宣稱 9.8 分）——函式根本還沒被寫出來。 公告說漏洞發生在 exprComputeOperands() 這個函式裡。JFrog 查出這個函式在 SQLite 3.41 中不存在，它是 2025 年年中才被加進原始碼（commits e24f20a、280559b）。更根本的問題是，公告指控的 sqlite3ReleaseTempReg() 這個函式從頭到尾不做記憶體釋放，它只是把暫存暫存器的索引丟回陣列裡回收再用——設計上就不可能發生 UAF。PoC 執行結果：查詢正常跑完，沒有崩潰。
CVE-2026-51303（宣稱 9.8 分）——連修補都是編的。 公告說這個漏洞在 3.51.3 版被修掉了。JFrog 把 3.51.2 跟 3.51.3 拉出來 diff，src/expr.c 這個檔案在兩版之間一行都沒改。至於公告聲稱的父結構反向參考指標，在 Expr、Select、Window 三個結構裡都不存在。附的 PoC 是無效 SQL，在解析階段就被擋下來，根本走不到它宣稱的執行邏輯。
CVE-2026-51300（宣稱 9.1 分）——行號指到不相干的地方。 公告言之鑿鑿指出 expr.c 第 1012 行與 1026 行有問題。JFrog 打開來看：一行是註解，一行是記憶體配置呼叫，兩行都跟公告描述的刪除邏輯無關。
| CVE 編號 | 宣稱的漏洞 | 宣稱 CVSS | 查核發現 |
|---|---|---|---|
| CVE-2026-51302 | exprComputeOperands() 的 UAF | 9.8 CRITICAL | 引用了不存在的函式 |
| CVE-2026-51303 | ExprListDelete() 反向參考 UAF | 9.8 CRITICAL | 宣稱的修補不存在 |
| CVE-2026-51300 | sqlite3ExprDelete() 的 UAF | 9.1 CRITICAL | 引用的行號與漏洞無關 |
| CVE-2026-51297 | jsonBlobEdit() 造成的 UAF | 8.8 HIGH | 引用了不存在的函式 |
| CVE-2026-51296 | jsonRemoveFunc 的 UAF | 7.5 HIGH | 引用了不存在的程式碼行 |
| CVE-2026-51304 | pOrderBy->nExpr 釋放後存取 | 7.5 HIGH | 函式是真的，參數數量錯了 |
資料來源：JFrog Security Research，2026 年 7 月 30 日
最後一項最值得玩味。CVE-2026-51304 引用了一個真實存在的函式，但參數數量是錯的——這正是 AI 生成內容的典型指紋：名字對、脈絡對、細節錯。JFrog 另外把這批公告丟進 GPTZero（AI 內容偵測工具）測試，全部被判定為 AI 生成；把所有公告合併成單一檔案後，AI 生成警告更明顯。
為什麼 NVD、CISA、Red Hat 都先信了？
因為現行流程是先登錄、先給分、後查證，而查證這一段沒有人做。以本案觀察，CVE 提交只要格式完整、敘述在技術上讀起來合理，就足以進入資料庫並取得編號——這段流程解讀由本文根據本案結果推得，JFrog 原文並未逐字說明。NVD 接著補上分數與 CPE（受影響產品的識別字串），CISA 的 ADP 機制再疊加補充意見——JFrog 的原文只寫到「CISA's ADP agreed」，這個縮寫的正式全稱與職權範圍請以 CISA 官方文件為準，本文不代為認定。
這整條鏈上沒有任何一關會去 clone 原始碼、編譯、跑 PoC。JFrog 這次做的就是那道沒人做的工，而它的成本高到不可能套用在每一筆提交上——建隔離環境、切三個版本標籤、編譯、跑 ASan、比對 diff、逐筆檢視 CPE 中繼資料，這是研究團隊等級的投入。
JFrog 也記錄到中繼資料本身的異常：有的公告 CPE 被硬釘在 3.41.0，有的中繼資料自相矛盾，有的廠商與產品欄位直接是 n/a 佔位符。這些訊號在自動化流程裡不會擋人，卻是人眼掃過去就會起疑的東西。
Red Hat 從 10.0 下修到 7.6 這個動作，說明評分方自己也在回頭修正。滿分 10.0 是資安界最強的動員訊號，它在真實性未經任何實證的情況下被發出去了。
LLM Slop 是什麼？跟一般的誤報差在哪？
LLM Slop 是 JFrog 這篇標題直接使用的說法，指大型語言模型大量產出、表面完整但內容空洞或錯誤的填充式內容。它跟傳統誤報的差別在於「可信度的偽裝程度」。
| 比較維度 | 傳統掃描誤報 | AI幻覺漏洞報告（LLM Slop） |
|---|---|---|
| 產生原因 | 規則過寬、比對到相似模式 | 模型依統計慣性生成看似合理的技術敘述 |
| 外觀完整度 | 通常只有一行告警與規則編號 | 有背景、有機制分析、有程式碼片段、有 PoC |
| 內容可驗證性 | 指向真實存在的程式碼位置 | 函式、行號、修補版本可能整組虛構 |
| 產出成本 | 需要維護規則庫 | 幾乎為零，可批次量產 50+ 筆 |
| 對維護者的負擔 | 掃一眼即可排除 | 必須動用實際編譯與測試才能推翻 |
| 破壞方式 | 浪費少量時間 | 消耗高階人力、污染公共資料庫、稀釋真警報 |
真正的傷害在最後一列。開源專案的維護者多半是志工，他們的時間是這個產業最稀缺也最沒有價格標籤的資源。當假報告的產出成本趨近於零、推翻成本卻需要一個研究團隊，這條不對稱曲線會直接壓垮維護能量。而每一次假警報都在教整個產業「重大 CVE 可以先觀望」——真的漏洞來的時候，動員速度就慢了。
這對台灣中小企業意味著什麼？
意味著你買資安服務時，付的錢可能買到一份沒人驗證過的 AI 產出。這件事會用兩種方式打到你的帳上，跟它發生在美國開源圈沒有關係。
第一種：委外健檢的空包彈。 台灣中小企業做資安健檢，多半是專案外包、看報告驗收。當報告方把 AI 掃描結果直接排版出貨，你收到的是一疊有 CVSS 分數、有 CVE 編號、看起來很嚇人的清單。你不會有能力逐條重現，你只會看到「重大：7 項」然後開始緊張、開始追加預算。JFrog 這次的案例證明，這疊東西可以整份不成立。
第二種：內部合規的假動作。 有些公司導入 AI 程式碼掃描工具是為了通過客戶查核或供應鏈要求。如果團隊把工具輸出當成結論、沒有人工複核，那麼你花錢買的是一份自我安慰——真漏洞被淹在誤報堆裡，沒人看得出來。
我的立場很明確：AI 掃描的輸出只能當線索，定案要靠人。付錢驗收的標準應該是「可重現」，不是「發現幾條」。 按發現條數計價的資安報價，在 AI 時代等於直接付錢請人灌水。
落到可執行的層面，三件事今天就能做：
- 改合約條款。 資安健檢合約寫明：每一項發現需附可在指定環境重現的 PoC，重現不了的不計入交付項目；報告需標明每項發現的驗證方式（人工複核／動態測試／僅靜態掃描）。
- 改驗收方式。 挑三條評分最高的發現，要求對方當場在你的環境重現。做不到就退回重做。這一招對真做事的廠商毫無殺傷力，對灌水的廠商是致命的。
- 改內部流程。 任何 AI 工具產出的資安結論，在進入修補排程之前必須有一個人簽名，而且簽的內容要具體到「我確認這個位置的程式碼真的長這樣」這種程度；一句「我看過」不算數。
這套邏輯不只適用資安。任何被 AI 大量產出、外觀完整、驗證成本高的東西——市場報告、競品分析、法遵檢核清單——都適用同一條規則：看起來越完整、越該問「這條怎麼驗」。 我們在做 AI 內容與 AEO 佈局時守的是同一條線，數字沒有出處寧可不寫。
收到一份 AI 資安報告，怎麼在半天內驗真假？
用五道關卡，不需要資安工程師也能跑完前三關。JFrog 的方法論拆開來，中小企業可以做到的版本長這樣：
關卡一：查官方公告頁。 拿報告裡的 CVE 編號，去該軟體官方的安全公告頁搜尋。SQLite 有 sqlite.org/cves.html。第三方資料庫標重大、官方頁完全沒有記載，這是最強的紅旗。
關卡二：搜函式名稱。 把報告點名的函式名字複製起來，去官方原始碼庫搜尋，切到你實際使用的版本標籤。這一步在 GitHub 網頁上就能做，不用會寫程式。函式在你的版本裡不存在，這份報告對你就是廢紙。
關卡三：查修補紀錄。 報告如果宣稱「此漏洞已於 X 版修復」，去比對 X 版與前一版的變更紀錄，看被指控的檔案有沒有真的被改動。JFrog 就是靠這一步戳破 CVE-2026-51303。
關卡四：要求重現。 把 PoC 丟給報告方，要求在乾淨環境當場重現。這是唯一能百分之百定案的關卡。
關卡五：看中繼資料異常。 廠商欄位是 n/a、CPE 被硬釘在某個舊版本、同一份公告內的敘述互相矛盾——這些單看都稱不上致命證據，但三個湊在一起就該全面複查。
前三關加起來大約半天，成本是一個行政人員的時間。相較於按重大漏洞數量追加的資安預算，這是全公司投報率最高的半天。
那該不該乾脆停用 AI 做程式碼掃描？
不該。停用 AI 掃描等於用一個問題換另一個問題——回到人工抽查，覆蓋率反而更低。
這次事件的因果很清楚：出事的環節是「AI 產出未經驗證就對外發布並被公共資料庫吸收」，也就是流程上少了一道實證關卡。AI 有能力讀程式碼這件事，在這個案例裡沒有被推翻。AI 掃描擅長的是廣度——它能在幾分鐘內掃過人力幾週才能覆蓋的程式碼量，把可疑點全撈出來。它不擅長的是定案，因為它會在細節上生成統計上合理、事實上錯誤的內容，這次那個「函式對、參數數量錯」的 CVE 就是標本。
正確的分工：AI 負責撈，人負責定。 中間那道「在真實環境重現」的關卡，是整條流程裡唯一不可外包給模型的部分。把它拿掉，工具就從省時裝置變成噪音產生器；把它留著，AI 掃描仍然是中小企業能買到最划算的資安工具之一。
這件事的真正結論
公共資安資料庫的信任模型，在生成式 AI 的產出成本面前已經失效了。它建立在一個假設上：提交一份技術上完整的漏洞報告需要真本事，所以格式完整大致等於內容可信。這個假設在 2026 年不再成立。
六個假 CVE 被 NVD 標為 Critical、被 CISA 的 ADP 同意、拿到 Red Hat 的 10.0 滿分，最後被一個願意花時間 clone 原始碼、編譯、跑 ASan 的研究團隊推翻。整條鏈上，唯一有效的品管是那道最貴、最慢、最不 scalable 的人工驗證。
對經營者的意義只有一句：在 AI 時代，「可驗證」取代「看起來專業」成為唯一的採信標準。 收到任何外觀完整的 AI 產出，第一個問題永遠是「這條怎麼驗」，第二個問題是「驗不出來的話，誰負責」。把這兩個問題寫進合約與驗收流程，你就不會為空包彈付錢。
常見問題
Q：AI 生成的資安漏洞報告可以直接相信嗎？
A：不能。2026 年 7 月 30 日 JFrog 的實測顯示，六份被 NVD 標為重大的 SQLite 漏洞報告，引用的函式在該版本根本不存在、宣稱的修補在原始碼 diff 裡查無痕跡、附的 PoC 在 ASan 環境下跑不出任何崩潰。AI 產的漏洞報告只能當「待查線索」，通過原始碼比對與 PoC 重現才算成立。
Q：這次 SQLite 的六個 CVE 現在算數嗎？
A：以 JFrog 的查核結果看，這六個編號的技術內容站不住。它們全都沒有出現在 SQLite 官方的漏洞公告頁（sqlite.org/cves.html），�� JFrog 把該頁形容為追蹤 SQLite 真實漏洞的黃金標準。其中 CVE-2026-51302 的 Red Hat 評分已從 10.0 Critical 下修到 7.6 High，顯示評分方自己也在回頭修正。
Q：為什麼 NVD 和 CISA 也會標錯？
A：因為現行流程是先登錄、先給分、後查證。以本案觀察，CVE 提交只要格式完整、敘述像那麼回事就會進庫，NVD 與 CISA 的 ADP 機制在分數這一關做的是形式檢查，不會有人去 clone 原始碼、編譯、跑 PoC——這段流程解讀由本文根據本案結果推得，JFrog 原文並未逐字說明。JFrog 這次做的正是那道沒人做的工，成本高到不可能對每筆提交都做。
Q：小公司沒有資安工程師，怎麼自己驗？
A：三個不需要資安專業的動作就能擋掉多數假報告：一，去該軟體的官方漏洞公告頁查有沒有這個編號；二，把報告裡點名的函式名稱丟進官方原始碼庫搜尋，看在你用的那個版本裡存不存在；三，要求報告方提供可重現的 PoC 與重現環境。三關過不了兩關，這份報告先不付錢也不修。
Q：該不該停用 AI 程式碼掃描工具？
A：不該。這次出事的環節是「AI 產出直接當結論對外發布」，AI 掃描工具本身在這件事裡沒有被推翻。AI 掃描的正確用法是當廣度篩選器——它負責把可疑點全撈出來，人負責在真實環境裡重現。把驗證關卡拿掉，工具就從省時變成製造噪音。
Q：委外資安健檢時，合約要怎麼寫才不會收到空包彈？
A：寫三條。第一，每一項發現必須附可在指定環境重現的 PoC，重現不了的不計入交付項目。第二，報告需標明每項發現的驗證方式（人工複核、動態測試、僅靜態掃描），不得只給一個 CVSS 分數。第三，付款與驗收綁定重現結果，而非發現數量——按條數計價會直接誘發灌水。
AIRUN 對抗式創業體檢 AgentFlow Solutions（双云行銷試運行）