AI 自寫的零日漏洞被抓了:文字裡的「幻覺 CVSS 分數」成為破案線索

Q: 「**LLM 寫的程式碼**」用肉眼真的看得出來嗎?

**經過訓練可以,但需要練習**。一般工程師看「**LLM 寫的程式碼**」會覺得「**怪怪的但說不出哪裡**」——**這個直覺就是 LLM 指紋的初步感知**。 具體的可學特徵:**(1) 過度工整的文件字串 + 型別註記**、**(2) 變數命名過於描述性**(`current_user_authentication_token` 而非 `tok`)、**(3) 過度錯誤處理**、**(4) 註解過於「教學」**(寫為什麼而非做什麼)、**(5) 函數拆分過於整齊**(每個函數正好做一件事,沒有人類的「**算了一起寫一寫**」)。 **這些特徵跟「**好程式碼風格**」高度重疊**——所以辨識的關鍵是「**情境**」:漏洞利用程式碼出現這些特徵是異常,正式產品程式碼出現這些特徵是正常。**LLM 鑑識的技巧不是看「**好不好**」,是看「**符不符合該場景的人類習慣**」**。

Q: 那 LLM 寫的漏洞利用跟人類寫的,殺傷力誰大?

**短期人類大,長期可能 LLM 大**。 **短期(2026)**:**人類專業駭客寫的漏洞利用**仍更精簡、更難偵測、針對性更強。LLM 寫的漏洞利用多數還有「**通用性過度、針對性不足**」的問題。 **長期(2027+)**:**LLM 的優勢是「**規模 + 速度**」**——可以同時為 50 個漏洞寫 50 個利用程式,人類沒這個帶寬。**如果 LLM 寫的漏洞利用平均殺傷力是人類的 60%,但數量是 50 倍,總威脅是「**60% × 50 = 30 倍**」**——這個算術很可怕。 **結論**:單一 LLM 漏洞利用可能比人類弱,**但 LLM 攻擊的「**規模壓力**」是新威脅**。防禦端要做的不是「**比每個漏洞利用都防得住**」,是「**用 AI 防禦對抗 AI 攻擊的規模**」——這也是 [IBM Autonomous Security Assistant](autonomous-ai-cyber-attacks/) 等產品的價值。

Q: 我自己用 ChatGPT 寫程式碼,會被誤判成「**疑似惡意 AI 攻擊**」嗎?

**目前不會,因為情境不同**。LLM 鑑識的「**疑似 AI 生成**」判斷只是第一層篩選,**真正的判斷在「**上下文**」**: - 你的程式碼上傳到 GitHub 公開倉庫、是工具軟體或網頁應用——**沒人會關心** - 你的程式碼出現在某零日漏洞利用中、嘗試攻擊一個正式服務系統——**會被深入調查** **問題不是「**程式碼是不是 AI 寫的**」,是「**這段 AI 寫的程式碼出現在哪裡、做什麼**」**。**個人正常使用 LLM 寫程式不用擔心**——但**未來企業、政府機關採用 AI 寫的程式碼前,要做「**LLM 鑑識 + 安全審查**」會變新常規**。 對開發者的具體建議:**不要直接把 LLM 生成的程式碼合併進正式服務而不審查**——這不只是品質問題,也是供應鏈安全問題。**程式碼審查流程要加入「**AI 生成程式碼審查**」這個步驟**。

5/11 Google 威脅情報組首次確認:攻擊方用大語言模型寫的 2FA 繞過零日,被文件字串過於工整與幻覺出來的 CVSS 分數出賣。AI 攻擊出現指紋。

發佈於： 2026-05-14

進階資安 Google 威脅情報零日漏洞

⚡ 重點摘要（TL;DR）

5/11 Google 威脅情報組(GTIG)公布:首次確認攻擊方用 AI 模型寫出在野部署的零日漏洞,目標是一個熱門開源管理工具的 2FA 繞過
Google 從程式碼裡的 LLM 文字特徵抓到攻擊方:**(1) 文件字串過於工整教科書化、(2) 一個幻覺出來的 CVSS 分數、(3) 變數命名極度 Python 風格化**
Google 確認**不是 Gemini 也不是 Anthropic Mythos**——可能是中國未公開模型或開源微調版本,但 LLM 的「**文字風格指紋**」很難改
Google 跟未具名廠商靜默修補,**在大規模利用前打掉攻擊鏈**——這是「**AI 防禦先一步**」的首例公開案例
跟 4/15 FortiGate 案的對比:那次 AI 攻擊鏈成功攻陷 600 台設備、Mandiant 事後發現;這次 5/11 是 Google 提前發現、阻斷在「**大規模利用事件**」之前
對企業資訊部門:修補速度仍是第一道防線,但「**LLM 鑑識**」(分析疑似 AI 生成的程式碼特徵)變成新興技能

5 月 11 日，Google 威脅情報組(GTIG)公布一個分水嶺案例:首次確認攻擊方用 AI 模型寫出實際部署到野外的零日漏洞利用程式——目標是一個熱門開源管理工具的 2FA（雙因素認證）繞過漏洞。

重點不是「AI 寫了利用程式」（過去 12 個月已有理論能力）,是「Google 從程式碼裡的 LLM 文字特徵抓到攻擊方」，並且在大規模利用前完成靜默修補。

跟 4/15 FortiGate 自主 AI 攻擊鏈那次「事後發現」不同，這次是「事前攔截」——AI 防禦第一次在公開案例上贏過 AI 攻擊。但贏的方式很意外：不是靠資安掃描工具，是靠「讀懂 LLM 的寫字習慣」。

📋 5/11 事件核心事實

項目	內容
公布單位	Google 威脅情報組(GTIG)
攻擊目標	熱門開源管理工具（廠商未具名）
漏洞類型	2FA 繞過（雙因素認證繞過）
首例宣稱	第一個確認在野部署的 AI 自寫零日漏洞利用程式
AI 模型	不是 Gemini、不是 Anthropic Mythos（具體來源 GTIG 未公開）
辨識特徵	文件字串過於工整、幻覺 CVSS 分數、變數命名極度 Python 風格
應對	跟廠商靜默修補，在大規模利用前打掉攻擊鏈
影響評估	Google「相信已在攻擊行動取得進展前打斷」

最值得記的是 GTIG 在程式碼裡看到一個「幻覺 CVSS 分數」——攻擊方的利用程式有文件字串註解寫「CVSS 分數： 9.8（嚴重）」，但這個 CVE 編號根本還沒分配 CVSS 分數——是大語言模型自己編造的。這是 LLM 胡謅的典型痕跡。

🕵️ LLM 程式碼的「文字風格指紋」

GTIG 在 5/11 報告與後續 Google Cloud Security Blog 揭露的辨識特徵：

(1) 文件字串過於工整、教科書化 LLM 寫程式時習慣加詳盡文件字串（因為訓練資料的 Python 教學文件、Stack Overflow、GitHub 說明檔都這樣寫）。人類駭客寫漏洞利用程式為了精簡，通常省略文件字串或寫很短。過度的「教育意義」是 LLM 露馬腳的特徵。

(2) 幻覺出來的 CVSS、CVE 資訊 LLM 不知道「這個 CVE 真實的 CVSS 分數」，但被訓練成「遇到 CVE 就要附 CVSS」，於是編造一個合理數字。人類駭客要嘛抄真實值、要嘛根本不寫。

(3) 變數命名極度結構化 def exploit_target(target_host: str, target_port: int = 443) -> ExploitResult: 這種完整型別註記 + 文件字串 + 回傳型別的程式碼，在正式產品 Python 是常見的，在野外漏洞利用程式碼是異常——駭客通常用 def x(h,p=443): 這種精簡寫法。

(4) 過度的錯誤處理 LLM 訓練資料的「好程式碼」都有大量 try/except、紀錄訊息、邊界條件處理。漏洞利用通常設計成「爆了就爆了」的最小可行版本——大量錯誤處理在利用程式上是違反直覺的。

(5) 過度註解、註解語言模式 LLM 註解習慣性用「這個函數處理…」「注意…」「重要：…」這種固定句式。人類駭客註解通常更口語、更短、更隨意。

這些單獨來看都不確診，組合起來形成「疑似 LLM 生成」的特徵向量。GTIG 內部估計這個特徵向量的準確度約 85-92%——夠高到可以做「值得進一步調查」的訊號，但不夠高到可以做「法庭證據」。

🧪 為什麼 LLM 文字指紋這麼難擦掉？

理論上攻擊方知道 LLM 有特徵後，可以「手動清掉」這些特徵——但實務上有三個原因讓這件事很難：

(1) 自動化跟手動清理的拉扯 攻擊方用 LLM 寫漏洞利用的目的就是「自動化、規模化」。如果每個利用程式還要人工去清 LLM 特徵，就失去自動化優勢。這個矛盾在「攻擊成本」與「不被偵測」之間，沒有完美解。

(2) LLM 的「思考結構」會殘留 即使把文件字串全刪、變數重命名，LLM 的「程式結構」（怎麼拆函數、怎麼處理流程控制、怎麼設計抽象層）仍會殘留教科書式的痕跡。這個比表面特徵更難改。

(3) 訓練 LLM 寫「像人類駭客」的程式碼會被偵測到 攻擊方可以微調 LLM 學「駭客寫法」，但這個微調行為本身會在程式碼中留下不同的特徵——「像人類但不夠像」的恐怖谷效應。GTIG 可以針對這種特徵也建偵測模型。

結果是:LLM 鑑識跟深偽偵測類似——「軍備競賽」，但比深偽偵測有利於防守方（因為程式碼比影像更結構化、特徵更明顯）。

⚔️ 跟 4/15 FortiGate 案的對比

這兩個案例放在一起看，可以看出 AI 攻防的「第一回合」與「第二回合」:

維度	4/15 FortiGate 案	5/11 GTIG 案
發現時機	事後(Unit 42 觀察到攻擊已進行)	事前(Google 在大規模利用前發現)
AI 角色	自主執行完整攻擊鏈（掃描 → 漏洞利用 → 橫向移動）	自主寫漏洞利用程式碼（部署仍人工）
AI 模型來源	Mandiant 評估未公開中國實驗室模型	GTIG 確認非 Gemini、Mythos,來源未公開
影響規模	55 國 600 設備被攻陷	在大規模利用前被打掉
防禦勝負	防禦輸（事後才知道）	防禦贏（攔在前面）
辨識方式	攻擊行為模式（規模、速度）	程式碼文字風格（文件字串、CVSS 幻覺）

這兩個案例的對比說明 AI 攻防的格局:

攻擊端的優勢：速度、規模、不疲勞——適合「大規模自動化攻擊」
防禦端的優勢:LLM 的「文字、結構指紋」、長期累積的攻擊模式資料庫
誰先嘗試新戰術，誰就有先發優勢——但雙方都在加速演化

🌍 攻擊方是誰？三個可能性

GTIG 報告刻意模糊「攻擊方是誰」，但業內推測有三個可能性：

可能性 1：中國實驗室開源模型微調

DeepSeek V4、Qwen 36 等開源模型 + 紅隊資料微調
攻擊方可能是「獨立駭客團體」或「準國家行為者」
跟 4/15 FortiGate 案的攻擊方可能有關聯

可能性 2：俄羅斯駭客團體用商用 LLM

用 GPT-4、Claude（透過越獄或介面濫用）
但 GTIG 明確排除 Mythos、Gemini，且 OpenAI 也未承認異常
較低可能性

可能性 3：商業犯罪集團用未公開模型

自家訓練的「犯罪用 LLM」（類似 WormGPT、FraudGPT 系列的進化版）
商業犯罪集團跟國家準入的灰色地帶
跟 4/30 Arup 深偽詐騙案的攻擊模式有相似性

Mason 的判斷:可能性 1（中國微調開源模型）機率最高。原因：

DeepSeek、Qwen 的中文與英文程式能力都足以寫漏洞利用
開源模型可以微調學特定任務，客製性高
中國實驗室模型不受 OpenAI、Anthropic 安全護欄限制
攻擊方需要「便宜、夠強、無監督」的模型——這幾個條件指向開源微調

🛡️ 對企業防禦的啟示

(1) 修補速度仍是第一道防線 這次 GTIG 能阻斷是因為「第一時間跟廠商合作修補」。沒有快速修補流程的組織，即使有 LLM 鑑識工具也救不了。

(2) LLM 鑑識變新興技能 過去資安人員需要懂逆向、惡意程式分析。現在多一個技能：讀懂程式碼的「LLM 痕跡」——這變成事故響應團隊的標準能力。訓練資源還很少，先學的人有先發優勢。

(3) 不要只依賴單一偵測 LLM 文字指紋的準確率 85-92%,不夠高到可以單獨做判斷。必須跟「行為分析」「漏洞利用模式」「網路流量異常」交叉比對。

(4) 開源工具與資料庫 GTIG 預期在 Q3 2026 釋出一個「AI 生成程式碼偵測器」開源工具，讓中小企業也能用。現在的暫代方案：用商用 AI 程式碼分析工具(GitHub Advanced Security、Snyk Code AI)做初步篩。

(5) 法律與歸因問題 「LLM 寫的漏洞利用」——責任歸屬怎麼分？攻擊方還是模型供應商？這個法律問題還沒判例。預期 12-24 個月內會有第一個 LLM 攻擊歸屬訴訟，為未來的 AI 攻擊歸責建立先例。

💡 Mason 的判斷

5/11 案例是「AI 防禦的第一個明確勝利」，但是是局部勝利、不是結構性勝利。三個觀察：

(1) 「LLM 鑑識」是真實有效的技術，但壽命有限 攻擊方知道指紋後會調整。目前 LLM 寫程式的「文字風格指紋」可能在 12-18 個月內被攻擊方「清乾淨」。這場戰的「特徵庫」必須持續更新。

(2) 防禦端真正的優勢是「規模 + 累積」 Google、Microsoft、Anthropic、Mandiant 各自有龐大的「程式碼風格資料庫」——LLM 生成跟人類寫的對比樣本。這個累積規模，小型攻擊方很難複製。長期防禦端有結構性優勢。

(3) 對台灣中小企業仍是壞消息 這個案例的勝利是美國大廠的勝利——Google 有資源做 LLM 鑑識、有跟廠商合作的能力、有威脅情報網。台灣中小企業沒這些。「AI 攻擊規模化、AI 防禦集中化」會擴大企業之間的資安差距，台灣中小企業仍是最脆弱的一群。

🇹🇼 對台灣的延伸

短期(2026)：觀察期

台灣大型科技業（台積電、聯發科、廣達）資安團隊應訂閱 GTIG 報告與 Mandiant 威脅情報
中華電信、遠傳、台灣大的「代管資安服務」開始加入 LLM 鑑識服務
預期 2026 下半年會有「台灣首例 AI 自寫漏洞利用」被發現

中期(2026-2027)：工具普及

GTIG 開源工具釋出後，台灣資安廠商（如趨勢科技、奧義智慧、戴夫寇爾）會跟進
政府應強制公部門資安預算編列「LLM 鑑識工具」——尤其健保、戶政、稅捐
預期 2027 開始，「懂 AI」資安人才薪資會明顯高於傳統資安

長期(2027+)：結構性變化

「AI 對 AI 的資安戰場」會成為資訊預算的主軸——台灣資安預算佔比預期從 1.5% 升到 3-5%
法律框架要跟上——台灣對「AI 自主行為的法律責任」需要立法，目前完全空白

🎯 不同角色的建議

給企業資安長 / 資安主管:

訂閱 GTIG、Mandiant、Anthropic 威脅報告——這三家的威脅情報最即時
這個月做「AI 漏洞利用偵測」能力盤點——你的資安監控中心能不能識別 LLM 生成的程式碼？
跟資訊部門對齊「修補速度指標」——CVE 公布到修補部署應該縮到 48 小時內（中大型企業）

給資安從業者:

學 LLM 鑑識是個高投資報酬投資——目前懂的人極少，12-24 個月內市場需求會爆發
工具與資源：OpenAI、Anthropic 都有公開威脅報告；arXiv 上「LLM 程式碼作者識別」相關論文加速累積中
不要忽略「社交、法律、政策」層面——純技術的 AI 防禦不夠，要懂歸因、究責、跨國協作

給政策制定者:

台灣應跟進美國 CAISI 模式——建立國家級「AI 攻擊評估與通報」中心
對「AI 自主行為」的法律責任做立法準備——攻擊方、模型提供方、平台方各自的責任邊界
國際合作：加入美國 CISA、Mandiant、GTIG 等的威脅情報共享網

給一般使用者、開發者:

你寫的開源工具如果被廣泛使用，它可能就是下個 AI 攻擊目標——加強 2FA 與認證機制
如果你開發雲端軟體服務，現在就要規劃「AI 探測下的快速修補流程」——靜態安全掃描已不夠
個人：啟用 passkey 取代 2FA(2FA 繞過攻擊就是針對這塊)，減少 LLM 對你的攻擊面

❓ FAQ

「**LLM 寫的程式碼**」用肉眼真的看得出來嗎？

經過訓練可以，但需要練習。一般工程師看「LLM 寫的程式碼」會覺得「怪怪的但說不出哪裡」——這個直覺就是 LLM 指紋的初步感知。

具體的可學特徵：(1) 過度工整的文件字串 + 型別註記、(2) 變數命名過於描述性(current_user_authentication_token 而非 tok)、(3) 過度錯誤處理、(4) 註解過於「教學」（寫為什麼而非做什麼）、(5) 函數拆分過於整齊(每個函數正好做一件事，沒有人類的「算了一起寫一寫」)。

這些特徵跟「好程式碼風格」高度重疊——所以辨識的關鍵是「情境」：漏洞利用程式碼出現這些特徵是異常，正式產品程式碼出現這些特徵是正常。LLM 鑑識的技巧不是看「好不好」，是看「符不符合該場景的人類習慣」。

那 LLM 寫的漏洞利用跟人類寫的，殺傷力誰大？

短期人類大，長期可能 LLM 大。

短期(2026):人類專業駭客寫的漏洞利用仍更精簡、更難偵測、針對性更強。LLM 寫的漏洞利用多數還有「通用性過度、針對性不足」的問題。

長期(2027+):LLM 的優勢是「規模 + 速度」——可以同時為 50 個漏洞寫 50 個利用程式，人類沒這個帶寬。如果 LLM 寫的漏洞利用平均殺傷力是人類的 60%，但數量是 50 倍，總威脅是「60% × 50 = 30 倍」——這個算術很可怕。

結論：單一 LLM 漏洞利用可能比人類弱，但 LLM 攻擊的「規模壓力」是新威脅。防禦端要做的不是「比每個漏洞利用都防得住」，是「用 AI 防禦對抗 AI 攻擊的規模」——這也是 IBM Autonomous Security Assistant 等產品的價值。

我自己用 ChatGPT 寫程式碼，會被誤判成「**疑似惡意 AI 攻擊**」嗎？

目前不會，因為情境不同。LLM 鑑識的「疑似 AI 生成」判斷只是第一層篩選，真正的判斷在「上下文」:

你的程式碼上傳到 GitHub 公開倉庫、是工具軟體或網頁應用——沒人會關心
你的程式碼出現在某零日漏洞利用中、嘗試攻擊一個正式服務系統——會被深入調查

問題不是「程式碼是不是 AI 寫的」，是「這段 AI 寫的程式碼出現在哪裡、做什麼」。個人正常使用 LLM 寫程式不用擔心——但未來企業、政府機關採用 AI 寫的程式碼前，要做「LLM 鑑識 + 安全審查」會變新常規。

對開發者的具體建議：不要直接把 LLM 生成的程式碼合併進正式服務而不審查——這不只是品質問題，也是供應鏈安全問題。程式碼審查流程要加入「AI 生成程式碼審查」這個步驟。

Sources:

№ · further reading