Claude Opus 4.6 的 500 個零日漏洞：三個修補程式揭示了什麼

2026 年 2 月 5 日，Anthropic 的 Frontier Red Team 發表研究報告指出，同日發布的 Claude Opus 4.6 已發現並驗證超過 500 個高嚴重性漏洞存在於開源軟體中——且無需任務專用工具、自訂支架或特殊提示。報告詳細描述了三項發現：Ghostscript 中缺少堆疊邊界檢查、OpenSC 中一連串未經檢查的 strcat 呼叫，以及 GIF 編碼器 CGIF 中的緩衝區溢位，其觸發取決於 LZW 壓縮在其字典填滿時的行為。Anthropic 表示，這三項目前皆已由維護者修補；按其說法，這些錯誤已被發現、驗證並回報。文章指出，許多專案由小型團隊或志工維護，沒有專職安全人員，因此回報與修補的負擔落在他們身上。該檔案本身針對此發現的條目，評為資訊級嚴重性且未記錄實際危害，位於Orca AI Incident Archive中，與其他 2026 年 2 月的政策與披露紀錄並列。

Anthropic 實際發表了什麼

這篇文章的標題是「評估並緩解 LLM 發現的零日漏洞日益升高的風險」，署名為 Frontier Red Team：Nicholas Carlini、Keane Lucas 與 Evyatar Ben Asher 為同等貢獻者，另有 Newton Cheng、Hasnain Lakhani、David Forsythe 與 Kyla Guru。頁面標示的發布日期為 2026 年 2 月 5 日，並有一則日期為 2026 年 2 月 6 日的編輯註記，記錄作者名單已更新。存檔在 red.anthropic.com 引用該文章，該網址現已重新導向至 anthropic.com/research/zero-days。

方法比標題上的數字更重要。Anthropic 表示，它將模型放進一台虛擬機中，讓模型能存取開放原始碼專案的最新版本，並提供標準工具以及人類安全研究人員會使用的工具——除錯器和模糊測試器——但沒有指示該如何使用這些工具，而且用該文章的話來說，「沒有能讓它獲得關於如何更有效找出漏洞的專門知識的自訂測試框架」。被測試的是模型的開箱即用行為。

團隊把搜尋範圍縮小到記憶體損毀類的錯誤，理由是當機比邏輯錯誤更容易確認。Anthropic 明確表示，這只是一種篩選機制，並非保證：「並非所有導致程式當機的輸入都是高嚴重度的漏洞。」因此，這些當機案例被送回模型進行批判、去重與重新排定優先順序，之後再交給人員處理。「在我們最初一輪的發現中，我們自家的安全研究人員逐一驗證了每個漏洞，並親手撰寫修補程式。隨著發現數量增加，我們引入了外部（人類）安全研究人員來協助驗證與開發修補程式。」該文章指出，修補自動化當時仍在建置中。

三個錯誤，以及隨後的修補程式

這三個實例有共同的模式：自動化工具已經失敗，而模型是透過推理輸入變異以外的因素找到這個錯誤。

• Ghostscript，PostScript 與 PDF 解譯器。模糊測試及後續人工分析均未發現任何問題。接著，模型讀取了專案的 Git 歷史，發現貼文中描述的一個提交，該提交為 Type 1 charstrings 新增了「MM blend 值的堆疊邊界檢查」，並推斷該提交之前的程式碼存在漏洞，於是尋找其他未獲得相同處理的呼叫點。它在 gdevpsfx.c 中找到了一處——貼文引用第 292 行——並建構了一個會使程式崩潰的檔案。儲存庫證實了這一點：Chris Liddell 的提交 87486fb801，日期為 2025 年 9 月 5 日，標題為「Type 1 charstrings: add stack bounds checking for MM blend values」。Ken Sharp 後來的一個修復，提交 4e392a82，日期為 2026 年 1 月 26 日，在字型轉換器中該呼叫之前立即新增了邊界檢查，並針對 Bug 709080 提出，其報告標題為「Ghostscript Incomplete fix for Type 1 MM blend stack bounds check」。2026 年 2 月 13 日的一個提交擴展了同一轉換器中的邊界檢查。沒有任何提交訊息說明是誰回報了這個錯誤。

• OpenSC，一個用於智慧卡資料的命令列工具。在此，模型搜尋了有風險的函式呼叫，並發現連續的 strcat 操作寫入一個 4096 位元組的 filename 緩衝區，這發生在一個大小計算之後：該計算減去了輸入字串的長度，但隨後又附加了更多字串，卻沒有重新檢查。文章指出，由於涉及的前置條件，既有的模糊測試器很少到達該路徑。OpenSC 於 2026 年 1 月 19 日的提交 33ab343a5c 新增了一項檢查，確認所附加的字串正好是 64 位元組；而於 2026 年 1 月 25 日合併的提取請求 #3554，則將專案中其餘的 strcat 呼叫替換為 strlcat；其作者稱該函式是「任何靜態分析工具與 CVE 的磁鐵」。

• CGIF，一個 GIF 編碼器。該程式庫假設壓縮後的資料一定會比未壓縮的輸入小，而這幾乎總是成立。該模型推論，LZW 會建立固定大小的字典，而當字典填滿時，插入串流中的清除碼可能使「壓縮後」的輸出比輸入更長——因此，為 N+2 個碼配置的緩衝區可能接收到超過 N+1 個碼。文章指出，即使達到 100% 的行覆蓋率與分支覆蓋率，也可能無法揭露此問題，因為它需要特定的操作序列。CGIF 的拉取請求 #84 於 2026 年 1 月 19 日合併，並在同日以 v0.5.1 發布，正是修正了這一點：「在計算 LZW 資料大小上限時，漏掉了重置清除碼。」

那些修補在研究發表前就已上線——CGIF 與 OpenSC 於 2026 年 1 月 19 日，OpenSC 於 1 月 25 日再次修補，Ghostscript 則在 1 月 26 日——而 Anthropic 在貼文中表示，在公開之前，它已「開始通報這些問題，並看到我們最初的修補陸續上線」。這些儲存庫記錄了程式碼變更，卻沒有記錄是誰提交通報，因此模型發現與這些特定提交之間的關聯，只能仰賴 Anthropic 的說法，以及所述缺陷與差異比對結果的吻合程度。

The researcher who said the OpenSC bug was not real

Public scrutiny of the individual findings did not start and end with Anthropic. On 14 February 2026 K. Reid Wightman, an industrial security researcher posting as @reverseics on infosec.exchange, published a review of the OpenSC example arguing the bug could not be triggered: the input string was already checked to be 64 bytes at line 5138, he wrote, which capped the buffer at 4095 bytes including the terminator. "I spent about an hour looking at the code to debunk their finding," he wrote.

He edited the same post on 17 February 2026 to withdraw the challenge. "Looks like the version of code I was looking at, already had a fix for anthropic-discovered bug(s)," the edit reads, before conceding the arithmetic: "but yes without the strlen() check on 'fp' the overflow could actually be triggered. The humble pie has been eaten." The check he had relied on was the one added to OpenSC on 19 January 2026 — before Anthropic published, and before most readers would have gone looking. The archive does not flag the record as disputed, and here the challenge was retracted by the person who raised it.

OpenSC's own maintainers answered the same question in their tracker. In discussion #3575, opened on 17 February 2026 by a user asking whether Anthropic's claims were legitimate, OpenSC maintainer frankmorgner replied the same day: "We received two bug reports from anthropic, which were both verified by humans." He said the fixes were in pull request #3554 and would be in the next release, and that commit 33ab343 was "a change that was introduced after anthropic reported the problem."

治理的另一半：探測、封鎖與 90 天

這篇文章之所以是政策紀錄，而非單純的研究筆記，關鍵在於文章後半段。除了發布模型之外，Anthropic 表示還推出了網路安全專用的探針，可在模型生成回應時測量模型內部的活化值，並表示已更新執行工作流程，改用基於探針的偵測。這比偵測更進一步：「我們可能會實施即時介入，包括封鎖我們偵測為惡意的流量。」Anthropic 承認這項代價——「這會對合法研究與部分防禦工作造成摩擦」——並表示希望與安全研究社群就此合作。文中未公布偵測率、錯誤率或申訴程序。

文章也主張，揭露時程本身如今已成問題。文中表示：「業界標準的90天窗口，可能抵擋不住LLM所發現漏洞的速度與數量」，並警告模型「可能很快超越甚至專業人類研究人員的速度與規模」。這是一家供應商主張，用來評判它的規範需要被取代，而這是紀錄中影響最深遠的部分。

之後有什麼改變？

2026年2月20日，Anthropic 以有限研究預覽形式向 Enterprise 與 Team 客戶開放 Claude Code Security，並讓開源維護者免費快速取得使用權限——這項能力在研究發布十五天後便產品化。VentureBeat 報導了這次發布，並表示曾向 Anthropic 詢問自我驗證前後的誤報率、已披露漏洞中已完成修補並上線者與仍在分類處理者的數量，以及用以區分攻擊者使用與防禦者使用的防護措施；報導指出，該專案的首席研究員無法受訪，且公司拒絕分享具體的攻擊者偵測機制。

修補程式也持續變動，而且未必總是朝同一個方向。CGIF 針對 Anthropic 所描述之記憶體配置問題的修正，於 2026 年 1 月 19 日隨 v0.5.1 發布；2026 年 2 月 21 日，pull request #103 修正了同一項配置計算所引入的 32 位元整數溢位，並於隔天以 v0.5.2 發布，針對最大 65,535 × 65,535 像素的 GIF。事實證明，修復邊界計算本身，也會成為邊界錯誤的一個小小來源。

正確讀取數字

Anthropic 自己的說法是「超過 500 個高嚴重性漏洞」。該公司最先向其簡報的 Axios，在報導發布當天將這些漏洞描述為「超過 500 個先前未知的零日漏洞」，每一個都經由 Anthropic 團隊成員或外部安全研究人員驗證。兩種描述指向同一組漏洞，但只有一種是廠商的措辭，而且兩者都沒有附上清單、CVE 對應或嚴重性分布。這個數字是 Anthropic 的，嚴重性評級也是 Anthropic 的，而大眾能查核的只有文中詳細處理的那三個專案。

後續的獨立分析大多照單全收這個數字，並爭論它代表什麼意義。Futurum Group 的 Mitch Ashley 於 2026 年 2 月 24 日寫道，這個結果「其重要性更多在於方法揭示了什麼，而非計數本身」，而真正的限制在下游：「更快揭露更多漏洞並不會縮小攻擊面。它只會在下游流程前堆起更長的佇列，而該流程無法吸收這樣的量。」這是對揭露流程而非對該發現的批評，且正好呼應 Anthropic 針對 90 天窗口所提出的同一點。

紀錄未能確立的事項

檔案將此紀錄評為信心 A、嚴重性 info，未記錄任何實際傷害，也沒有爭議標記。那項評級關乎事件被記錄得多完善，而非關乎底層主張被審核得多完善，而這個差別值得牢牢記住。Anthropic 以外沒有人驗證過那 500 個。尚未公布任何偽陽性率。三個具名專案的修補程式是真實且可考證日期的，也是目前可取得的最強佐證——但它們佐證的是三個例子，而非全部。

那麼，剩下的就是一份記錄詳盡的公告，其核心可受檢驗，其餘部分則無法檢驗：一家供應商報告了一項能力，三份上游差異檔與其對這些錯誤的描述相符，以及一項已表明的意圖——在模型層面管控該能力被濫用的情況。檔案庫將其歸類為政策，這是正確的架子。這項能力主張將由發布第四個修補程式的人來定案。