當你的 Agent 發現漏洞

Anthropic 的研究科學家 Nicholas Carlini 將 Claude Code 對準 Linux 核心原始碼，要求它尋找漏洞。設定方式非常簡單：一個 10 行的 bash 腳本，加上一個使用 ASAN 檢測建置的 Docker 容器。逐一走訪原始碼檔案，請模型尋找錯誤，然後移動到下一個檔案。¹³

根據 Michael Lynch 對此場演講的撰文記錄：² 結果是在 NFSv4 LOCK replay cache 中找到一個可遠端利用的 heap buffer overflow，自 2003 年 3 月起即存在，比 Git 本身還早。兩個相互配合的 NFS client 只要用 1,024 位元組的 lock owner ID 溢出一個 112 位元組的緩衝區，就能讀取敏感的核心記憶體。Carlini 在同一輪掃描中至少另外找到四個核心漏洞。在另一項實驗中，同樣的方法論產出 122 個送交 Mozilla 的 crashing input，其中 22 個獲得了 CVE 編號。³ 他還提到「好幾百個當機案例」尚未有時間驗證與回報。²

Carlini 確認了這些漏洞並回報給維護者。他使用的是 Opus 4.6，也就是從業者每天用於程式碼審查、重構與功能開發的相同模型層級。Carlini 於 2026 年 4 月在 [un]prompted AI 安全研討會上發表了這些研究成果。¹

是的，AI agent 確實能找到人類專家數十年未發現的真實安全漏洞。 一位 Anthropic 研究員使用 Claude Code 搭配一個 10 行的 bash 腳本，發現了 Linux 核心中存在 23 年、可遠端利用的 heap buffer overflow，並從 122 個 crashing input 中催生出 22 個 Firefox CVE。此方法論不需要客製化框架：用 ASAN 檢測建置逐一走訪原始碼檔案，並提示模型去找錯誤即可。

TL;DR

Carlini 的方法論極為精簡：逐一走訪原始碼檔案，提示 Claude 在每個檔案中尋找漏洞，再以 ASAN 斷言驗證命中結果。Opus 4.6 找到的漏洞數量，遠多於 Opus 4.1（舊 8 個月）或 Sonnet 4.5（舊 6 個月），這暗示模型能力近期跨過了某個門檻。² 目前的瓶頸是人類驗證，而非 AI 發現。這項轉變對於從業者如何建構安全 hook、執行程式碼審查，以及思考 agent 輔助稽核，都有直接影響。

關鍵要點

• 安全工程師： 這項能力真實存在，且進步飛快。如果您執行 agent 輔助的程式碼審查，您的 PreToolUse 安全 hook 比以往更加重要。重點不是阻擋 Claude，而是管控它能用找到的東西做什麼。
• Harness 建構者： 驗證瓶頸（「好幾百個當機案例我還沒驗證」）本質上是 harness 問題。自動化分類、去重與嚴重性評級，就是下一層基礎設施。
• 其他所有人： 那個導致 446 倍效能退化的模型，同時也找出了 23 年人類審查未能發現的錯誤。兩者同時為真。

方法論

Carlini 的方法並不需要客製化的安全框架、微調模型或專門提示詞。他形容為「一個 10 行的 bash 腳本加上一個 Docker 容器」：³

1. 以 ASAN（AddressSanitizer）檢測編譯目標
2. 逐一走訪原始碼檔案，利用模型評估安全相關性
3. 對高相關性檔案，以奪旗賽（capture-the-flag）框架提示 Claude Code
4. 對每個目標進行多輪掃描（依程式碼庫規模 5 到 20 輪不等）
5. 使用自動化批判 agent 在揭露前驗證發現

奪旗賽框架相當關鍵。告訴模型「這段程式碼有錯誤」所啟動的模式，不同於「審查這段程式碼是否有問題」。開發者在日常使用中也注意到相同的模式：當您告訴 Claude「有個問題存在」時，它會比問「是否可能有問題」時找到更多問題。²

整輪掃描耗用的是 API 的 token，而非以人月計算。Carlini 使用一個通用型 agent CLI 就找到了五個確認的 Linux 核心漏洞與 22 個 Firefox CVE。³ 這與幫您寫單元測試、幫您格式化 import 的是同一款工具。

能力門檻

最令人震撼的發現是模型世代之間的落差。Carlini 嘗試用舊模型重現他的結果：²

• Opus 4.6（演講前約 2 個月發布）：找到 heap overflow 以及多個額外漏洞
• Opus 4.1（8 個月前）：只找到極少部分
• Sonnet 4.5（6 個月前）：只找到極少部分

在模型世代之間，某個門檻被跨越了。將複雜程式碼庫納入 context、跨函式邊界推理資料流、辨識細微規格不一致的能力，似乎是湧現而非逐步改進。

Carlini 直言：「我這輩子從來沒有找到過這種漏洞。這非常、非常、非常困難。但有了這些語言模型，我找到了一大堆。」²

悖論

那個導致效能退化的 agent 架構——118 個函式出現 3 倍到 446 倍不等的效能下降——同時也找到了數十年專家人工審查所遺漏的安全漏洞。這是同一能力剖面的兩個互補面向。漏洞研究本質上是針對已知類別（buffer overflow、use-after-free、整數有號性問題）的模式比對，這正是 LLM 的強項。⁴ 效能最佳化則需要完全相反的能力：針對特定執行 context、快取行為與演算法複雜度進行推理。模型能在數百萬行程式碼中辨識 buffer overflow，卻無法告訴您 hash map 在您的存取模式下比已排序陣列慢。請據此建構您的 harness：用安全 hook 標記發現，用效能 hook 在提交前進行量測。

驗證瓶頸

Carlini 最具揭露性的一段自白是：「我手上有一大堆 Linux 核心錯誤無法回報，因為還沒驗證。」²

瓶頸現在位於分類，而非發現。找出潛在漏洞的成本，低於確認它們是否為真實漏洞。這樣的倒置為安全團隊帶來了新的基礎設施問題：

發現是自動化的。一個 agent 可以在幾小時內掃完一個程式碼庫。

驗證是人工的。每個潛在漏洞都需要概念驗證、影響評估，以及負責任揭露流程。

分類則是落差所在。將數百個 agent 產生的發現，分類為真實漏洞、誤報以及低嚴重性雜訊，目前尚無成熟的工具可用。

這個模式與 agent 輔助的程式碼審查相互呼應：agent 產出原始輸出的速度，快過人類評估的速度。價值不在於生成本身，而在於處理、過濾與分派輸出的基礎設施。

對 harness 建構者而言，這意味著下一個高價值的 hook 不是安全掃描器，而是安全分類系統：去重、嚴重性評級、誤報過濾與自動產生概念驗證。管控 agent 輸出的治理 hook，比掃描能力本身更重要。

這對從業者意味著什麼

如果您在生產環境程式碼庫上執行 Claude Code，您已經在運行一套能找到真實漏洞的系統。問題不在於這項能力是否存在，而在於您的 harness 能否處理 agent 找到的東西。

三個實務性的行動：

在您的審查流程中加入安全掃描。 Write/Edit 上的 PostToolUse hook 可以對變更的檔案觸發有針對性的安全掃描。該 hook 從 stdin 讀取檔案路徑（Claude Code 會將事件 JSON 透過 stdin 傳給 hook）：

#!/bin/bash
# .claude/hooks/security-scan.sh
FILE_PATH=$(jq -r '.tool_input.file_path // empty' < /dev/stdin)
[ -z "$FILE_PATH" ] && exit 0
[ ! -f "$FILE_PATH" ] && exit 0

claude -p "This file has a security vulnerability. Find it and describe the impact: $FILE_PATH" \
  --output-format json >> .claude/security-findings.jsonl 2>/dev/null &
exit 0  # non-blocking, runs in background

{
  "hooks": {
    "PostToolUse": [{
      "matcher": "Write|Edit",
      "hooks": [{ "type": "command", "command": ".claude/hooks/security-scan.sh" }]
    }]
  }
}

上述 hook 只是起點，並非可直接用於生產。您需要加上去重、嚴重性過濾與流量限制。但其核心模式呼應了 Carlini 的方法論：以有針對性的提示詞在檔案上迴圈。³

建構分類基礎設施。 沒有經過嚴重性分級的原始漏洞發現，就只是雜訊。如果您的 agent 每輪掃描產出 50 個發現，您需要在人類看到清單之前先自動去重並排序優先級。這個瓶頸是 harness 問題，不是模型問題。

接受這個悖論。 同一個需要效能護欄的模型，在安全模式比對上卻確實出色。設計您的 harness，以發揮強項並彌補弱項。安全 hook 負責掃描。效能 hook 負責量測。品質 hook 負責驗證。每個都涵蓋其他 hook 所遺漏的面向。

這個 23 年的 Linux 漏洞並非藏匿起來。它就明擺在那裡，處在數千名工程師讀過的一個檔案中。模型之所以找到它，是因為大規模的模式比對正是這類系統所擅長。重點不是 agent 在安全方面比人類更強，而是 agent 涵蓋了不同的表面——而同時協調兩者的 harness，才是讓這個組合可靠的關鍵。

更新（2026 年 4 月 7 日）： Anthropic 發表了 Project Glasswing，一個名為 Claude Mythos 的新模型，將 Carlini 的做法擴展至橫跨所有主要平台的數千個 zero-day 漏洞。Mythos 目前仍僅限 12 個合作夥伴使用，未對外公開。以上內容涵蓋 Carlini 的原始研究；後續文章則涵蓋其產品化過程。

資料來源

常見問題

我可以用 Claude Code 重現 Carlini 的做法嗎？

Carlini 已在 podcast 訪談中記錄了方法論。³ 核心迴圈為：以 ASAN 編譯、逐一走訪原始碼檔案、以奪旗賽框架提示 Claude、驗證命中。Carlini 表示，Opus 4.6 找到的漏洞遠多於舊模型，因此使用其他模型世代的結果可能會有差異。

這是否代表 AI agent 在找安全錯誤上勝過人類？

並非如此。它代表 agent 涵蓋不同的表面。Agent 擅長在大規模程式碼庫中針對已知漏洞類別進行模式比對。人類則擅長理解新型攻擊向量、業務邏輯缺陷，以及依賴 context 的安全屬性。兩者結合遠勝於單獨任一方。

我該擔心攻擊者使用這項能力嗎？

Carlini 明確警告「一波巨浪即將到來」。這項能幫助防禦者找到漏洞的能力，同樣可供攻擊者使用。不對稱之處在於，防禦者可以自動化分類與修補，而攻擊者仍需要開發 exploit。但發現端的落差正在縮小。