1Password 的 AI 修補研究：26% 乾淨修復，隨後出現反駁

2026 年 8 月 6 日，1Password 的 Off-by-1 Labs 發表了一項 55 頁的研究，探討前沿編碼代理是否能修補真實漏洞。ChatGPT 5.5 在中等投入程度下搭配 OpenAI 的 Trusted Access for Cyber 防護機制運行，Claude Opus 4.8 則在高投入程度下搭配 Anthropic 的 Cyber Verification Program 防護機制運行；兩者針對六個近期披露的多檔案錯誤，產生了 6,480 次修補嘗試。有一輪作弊檢查以模型曾去尋找上游修正為由，排除了其中 400 次；在剩餘的 6,080 次中，26.0% 在不改變行為的情況下封堵了該漏洞，而 53.8% 則留下了可遭利用的路徑、引入了新缺陷，或兩者皆是。沒有任何系統遭到入侵，也沒有任何使用者資料外洩——缺陷率存在於修補程式本身，這也是為什麼該檔案庫以 info 嚴重性登錄此條目，且未記錄任何危害。該紀錄本身連同其信心等級與引用來源，收錄於 Orca AI Incident Archive，這個檔案庫收錄了已記錄的 AI 事件與漏洞。

這六個 bug，以及為什麼是這六個

這些目標是刻意挑選成不友善的。每一個都必須位於代理可讀取的開原始碼中；造成嚴重的機密性、完整性或可用性損害；已在上游修補，但該修補程式不提供給代理，僅用作評分基準；揭露時間必須夠近，使修正不太可能已存在於模型的訓練資料中；而且需要真正涉及多個檔案、函式或程式碼路徑的修復。其中最早的揭露是 2026 年 3 月 26 日，最近的是 5 月 12 日。

每個目標在每個模型上都收到 540 次嘗試：三種執行模式 × 九種提示範本 × 20 個樣本。One-shot 執行沒有 shell，也沒有模型自身 API 以外的網路。Iterative 執行有重現腳本，最多十輪，並在輪次之間攜帶一份記憶檔案。Exploratory 執行有工具但沒有提供測試，並被要求自行決定行動方針。範本涵蓋從維護者的完整簡報、SAST 工單，到兩個指定了看似合理但錯誤修正的範本。執行皆以容器隔離，且 git 歷史被切在真實修補提交之前的那個提交。

作者在 2026 年 5 月 20 日專案啟動時即已固定的工作假設是：模型的修補率會高於 67%。沒有任何單一組態——模型、模式與提示詞——能在每一項目標上都突破 50%。

26% 是五部分量表裡的一格

這篇論文依五種結果為每個修補程式評分。S1 緩解所有可利用路徑，並讓無關行為保持不變，或完全依照真實上游修補程式的方式改變它。S2 緩解漏洞，但在此過程中改變應用程式行為——例如，連同惡意輸入一起拒絕良性輸入。S3 至少留下一條可利用路徑未封堵，且不新增缺陷。S4 修復所報告的錯誤，卻引入另一個不同的錯誤。S5 則兩者皆未達成。

在 6,080 次非作弊迭代中，論文報告 S1 為 26.0%——Claude Opus 4.8 為 25.6%，ChatGPT 5.5 為 26.5%——接著 S2 為 20.1%、S3 為 49.3%、S4 為 2.3%、S5 為 2.2%。廣為流傳的失敗數字 53.9%，是 S3、S4 與 S5 的合計；論文表格在四捨五入前加總為 53.8%，而 1Password 的部落格與存檔列都標示 53.9%。

這兩個模型平均起來的完成率相差不到一個百分點，但幾乎所有變異都來自目標專案，而非模型本身。將兩者平均後，各目標的乾淨修復率從 Apache ActiveMQ 的 3.2% 到 Exim 的 60.0%。單就 Exim 而言，兩款模型相差 31.6 個百分點：Claude Opus 4.8 為 75.8%，ChatGPT 5.5 為 44.2%。作者將這一點解讀為對隨插即用修補代理（plug-and-play patcher agents）的警訊，並明確指出該研究並非兩款模型的正面對決比較。

兩個次要數字比主標數字更重要。在被評定為乾淨修補的修補程式中，有 25.2% 帶有脆弱性旗標——它們堵住了所回報的漏洞，卻讓底層原語留在原處，儘管未必可觸及。合計 S1 與 S2，37.5% 屬於脆弱修補。另外，在迭代組與探索組中，經作弊檢查的迭代有 9.3% 被判定查閱了上游修補程式，而這正是 400 次排除的來源。成本並不高：ChatGPT 5.5 每次嘗試為 $2.11，Claude Opus 4.8 為 $2.81；將失敗嘗試攤銷後，每次乾淨修補分別為 $4.49 與 $6.44，且不含確認修補的成本。

指引品質對乾淨修復率的影響比模型選擇更大。在審慎且正確的修復指引下，S1 比率為 35.9%；在沒有指引的情況下為 24.7%；在指出錯誤的根本原因或修復方向的指引下則為 7.4%。作者特別指出這一點：當代理自身的工具呼叫與人類提示相矛盾時，它往往仍舊遵循提示。

那些失敗實際上呈現的樣貌

最清楚的案例是 CVE-2026-31431，也就是被稱為 Copy Fail 的 Linux 核心 AF_ALG 錯誤。上游在提交 a664bf3d 中修正了這個跨映射記憶體損毀原語：將轉換回復為非原地操作，卻在同一個輔助函式中引入新的差一錯誤；維護者在下一個提交 31d00156 中修正，並指派 CVE-2026-43078。模型幾乎完全重現了這個中間形式：400 個非作弊 ChatGPT 修補程式中有 129 個（32.2%），383 個 Claude 修補程式中有 119 個（31.1%），在各模式下都帶有該差一錯誤。論文透過對重寫後的函式進行結構比較，找出那 248 個；自動評分器僅標記 14 個 ChatGPT 修補程式和 10 個 Claude 修補程式為引入了新漏洞。

同一個檔案裡還潛藏著一個更隱蔽的疏漏。重寫 authencesn 解密路徑時，也連帶暴露出一個延伸序號（extended sequence number）的寫入問題：當認證標籤短於四個位元組時，這個寫入就會越界；上游在 5db6ef98 中於建立實例時拒絕過短的雜湊，從而修補了這個問題。這個缺陷早於 Copy Fail 存在，並不在該 CVE 的修補提交之列，而重現程式也從未觸及它，因為重現程式把標籤長度固定為四個位元組。全部 783 次非作弊的反覆運算都未能防住它，包括每一個被評為乾淨修復 Copy Fail 本身的修補；唯一帶有這道防護的修補，是四次逐字照抄上游提交的反覆運算。

GHSA-wpqr-6v78-jr5g，Gemini CLI 的遠端程式碼執行漏洞是兩個部分的問題：無頭模式會自動信任工作區並載入工作區本機設定，包括會初始化行程環境的 .env，而另一個獨立旗標則會繞過工具允許清單。兩個模型的平均乾淨修復率為 5.6%，是整項研究中最低的。在單次模式下，ChatGPT 的修補中有 29.4%、Claude 的修補中有 63.9% 不再自動信任工作區，卻仍載入由攻擊者控制的 .env，因為載入環境的動作與信任決策位於不同模組。當重現器指出 .env 路徑時，迭代組便補上了這個漏洞——盲點在於注意力，而非能力。

Chromium 的錯誤 CVE-2026-8512，是 macOS 檔案監看器中的釋放後使用（use-after-free）問題。上游修正以引用計數的上下文取代原始指標，而這個上下文必須在兩個地方保持存活：安裝位置，以及回呼本身內部。在採用引用計數架構的修補程式中，來自 ChatGPT 的 41.9% 與來自 Claude 的 38.5% 保留了第一個引用，卻捨棄了第二個，這只是把釋放後使用移到別處，而非移除它。

這些例子共有的一項特性，對任何打算將這個迴圈自動化的人都很重要：評分者往往看不到失敗。模型的自動評分與人類審查者在五類結果上一致的比例為 65.9%，在原錯誤是否已修復上為 87.7%，在新錯誤是否出現上為 70.5%。兩個模型驗證器在 36.8% 的修補程式上彼此意見不合，而合併後的評分顯示，Claude 對撰寫修補程式的任何人都從寬評分，ChatGPT 則從嚴評分。

1Password 表示接下來應該發生什麼事

領導 Off-by-1 Labs 的 Keith Hoodlet 向 eSecurity Planet 表示，「產生修補程式不等同於修復漏洞」，而且「專家的真人審查仍然不可或缺，以驗證修補程式既有效又安全」。該論文的結論比大多數報導更為狹隘：能否成功在很大程度上取決於關於該錯誤的準確且高訊號的資訊，而整理這些資訊是熟悉程式碼庫的工程師的工作。

Anthropic 在部落格中引述的回饋是：修補程式的產生速度已超越修補程式的驗證速度；驗證應以實際執行為依據，而非仰賴人工檢視；且在目前的模型能力下，領域專家仍應是最終審查者。1Password 發布了名為 flawed 的測試框架，以及全部 6,480 個修補程式，讓其他人能測試哪些檢查原本能攔下這些失敗。10 月 26 日，該部落格更新了發表後的回饋：團隊所選擇的限制「可能限制了代理式修補工具所能產出的內容」，而更嚴格的驗證是否會改變結果，則被描述為一個有用的下一個問題。

該紀錄還包含第二項研究，而這並不是同一個測試。

某個封存資料列中載有兩組數字，而日本資訊科技振興機構（Information-technology Promotion Agency）正是將它們並列呈現的文件：其 2026 年 8 月 AI 安全公告於 9 月 7 日發布，並在單一一筆日期為 8 月 6 日的條目中概述了這兩項研究。第二項研究出自 Checkmarx：由 Checkmarx 委託，並由 The Weather Report 執行長 Ilya Kabanov 執行；他在四個模型各自的命令列代理中重新執行兩項已發表的基準測試——Claude Opus 4.8、GPT-5.5、Gemini 3.1 Pro 與 Gemini 3.5 Flash。Kabanov 的報告日期為 2026 年 7 月 6 日，Checkmarx 的貼文日期為 7 月 26 日，而業界報導則介於兩者之間。儲存庫層級基準測試 SusVibes 包含大型開源儲存庫中的 200 項功能任務，每項皆圍繞人類已發現並修復的漏洞建構；代理會被要求實作該功能，而成功條件是重現該人類的防護措施，且不得事先讓它看到該防護措施。

結果：功能成功率為 83–95%，較上一世代的 44–61% 明顯提升，但「安全且功能正常」的成功率僅 24–36%。在那些確實有效的修補程式中，有 65% 到 75% 重現了人類已移除的弱點——Checkmarx 對此的說法是「殭屍 CVE」，因為被重新引入的缺陷既沒有安全公告，也沒有可升級的版本。Checkmarx 舉出的例子是 CVE-2023-29159，這是 Python 的 Starlette 框架中的路徑遍歷漏洞，於 2023 年被發現並修復，卻在 2026 年由代理重新打造出來。

這些緩解措施所提供的資訊量與標題相當。一項遵循安全最佳實務的通用指示增加了 1 到 8 分。增加推理投入並未提升安全性，還使可用解決方案的數量減半。在撰寫程式碼前加入威脅建模步驟，可達到 43–49% 安全且功能正常；事後安全審查則達到 47–56%，兩者的代幣成本分別約為兩倍與兩點五倍。即使是最佳實驗組，仍有約半數任務不安全；在失敗案例中，代理人有時在自己的筆記裡指出正確的防禦措施，卻仍交付了有漏洞的程式碼。

Kabanov 與 Checkmarx 都對 65–75% 這個數字提出但書：這些任務之所以被選中，是因為以自然方式建構功能會重新引入該缺陷，因此一般程式碼中的比例可能更低；但他們同時主張，真實程式碼庫正充斥著這類功能，而這正是 CVE 最初的來源。

這兩項研究不應相加。一項研究是在問：代理是否能為一個已具名且已修復的錯誤撰寫修補程式。另一項研究是在問：代理在實作某項功能時，是否會避免重新引入一個沒有人告知它的錯誤。26.0% 與 24–36% 是分母不同的比率，而且兩者都不是 AI 修補的一般比率。

Trail of Bits：標題衡量的是錯誤的設定

2026年9月15日，在1Password發布六週後，四位Trail of Bits研究人員——Anish Naik、Dan Guido、Benjamin Samuels和Marcelo Morales——發表了一篇反駁，主張26%這個數字並不描述一般修補。他們用自己的數字提出的論點是：有兩個提示詞指示代理人套用錯誤的修正，而這些提示詞占資料的22%；有一種評估模式阻止代理人建置或執行程式碼，占36%；這六個弱點是因為其修正很複雜而被選中，各目標結果從3%到60%，且六目標平均值有一個未公開的標準誤，約為九個百分點；此外，兩個模型都以預設設定運行，而非最高投入。

他們也抨擊評分機制。他們主張，停止規則與評分標準互相衝突；在 8% 的 ActiveMQ 判定中，預期行為變更被當成回歸問題而受罰；而自動評判器在完整的五類結果上與人工審查員一致的比率僅 65.9%。他們引用 248 個帶有上游中間階段差一錯誤的 Copy Fail 修補程式，對比評分器抓到的 24 個；並舉出一個 Chromium 案例，評分器接受了仍讓回呼中留下 use-after-free 的修復。這些數字是 1Password 自己的；分歧在於它們意味著什麼。

他們重新分析時，只保留代理能執行程式碼、且未被告知錯誤修復方案的試驗，並剔除被判定曾參考上游修復的執行紀錄。在這個子集上，3,067 個修補程式中有 2,634 個——86%——阻擋了所提供的漏洞利用。他們對這意味著什麼很謹慎：阻擋手邊的漏洞利用，並不證明修復完整且沒有回歸。作為人類基準，他們指出 2024 至 2026 年間自身 236 份評估中的 2,265 次首次修復，其中 283 次（12.5%，95% 信賴區間 10.5% 至 14.5%）未能完全解決問題。他們也統計了其 Patch the Planet 計畫中的 186 個拉取請求：126 個已合併，其中 33 個（26.2%）需要進行與安全相關的修訂。他們並承認有一個案例：1Password 對他們自身修補程式的批評是正確的——在 freenginx 上，他們的修復與維護者獨立修復引入了相同的清理崩潰。

他們的結論很直白：「防禦方不應把 1Password 的宣傳主打比率，當真視為衡量 AI 修補能力的指標。」1Password 並未具名回應他們。該部落格指出，團隊歡迎外界批評其方法與研究結果，而 10 月 26 日的更新承認，所選定的限制條件可能過度約束了這些工具所能產出的結果。日本 IPA 的公報刊載了 26.0% 與 53.9%，且未加任何限定說明，該公報於 9 月 7 日發布——比反駁文章早了八天。

什麼是已確立的，什麼是尚在論辯的

• 已確立：該研究確實存在，具名作者為 Axel Mierczuk、Spencer Michaels 與 Keith Hoodlet，日期為 2026 年 8 月 6 日；而其 6,480 次嘗試、400 項排除與 6,080 個已評分修補程式的計數，均見於論文、1Password 的部落格以及 IPA 摘要中。

• 已確立：結果組成——26.0% 無瑕疵、20.1% 行為改變、49.3% 未解決，以及 4.5% 帶有新缺陷——為作者自行評分，由兩名模型驗證器產生，其判定經取平均，並在 1,052 個修補樣本上與人工審查交叉核對，五級評分的一致率為 65.9%。

• 已確立：具體的迴歸問題──248 個 Copy Fail 修補程式帶有上游中間的 off-by-one 錯誤、783 次迭代遺漏了 ESN 防護、Gemini CLI 中的 .env 模式、Chromium 中缺少的第二個參照──這些都是作者對其自身資料的聲稱，並說明了偵測方法，且偵測器已透過 253 次迭代的人工審查進行檢驗。

• 爭論：26% 是否是對 AI 修補能力的一種公允說法。Trail of Bits 表示，其自家過濾器套用同一批修補程式後，可達到 86% 的漏洞利用阻擋率，並稱這樣的設定並非一般修補；1Password 則表示歡迎這項批評，並說其限制可能訂得太緊。雙方分析的是同一批 6,080 個修補程式；分歧在於哪些過濾器才合理，而且雙方都尚未發表對方能接受的複現結果。

• 未聲稱：其中任何一項在實際場域中造成危害。檔案庫記錄並無實際危害，並將該條目歸檔為 info 嚴重性。這六個漏洞在測試執行前已於上游修補，而研究中的修補程式是於容器中產生的候選項，並非合併進那些專案的程式碼。

對防禦者而言，有用的問題不是該相信哪個陣營。問題在於這個數字代表的是什麼比率：是在刻意混合的資訊下、刻意設計的難解漏洞中占 26%，還是在已阻擋所提供漏洞利用程式的可執行試驗中占 86%。這兩個數字都來自同一份資料集，而且兩者都不是採購規格。雙方真正有共識的是 {{1}}1Password 自己在論文中印出的但書——「生成的修補程式只是候選，並不證明漏洞已被修復」{{/1}}——而這正是無須裁決的部分。