AI 補丁落差研究解析：GLM 5.3、Firefox 與 1,000 美元的成本邊界（2026）

2026 年 10 月 29 日，Epoch AI 發布了這篇研究〈AI can turn security fixes into working exploits before users receive an update〉。這份 AI 補丁落差研究，讓人重新思考一個看似安心的消息：「漏洞已經修好」，究竟是程式碼修好了，還是你的電腦已經得到保護？

先把研究的發現與限制放在一起，再核對 Mozilla 與 Chrome 團隊的公開說明，最後回答：這份結果改變了什麼，哪些結論還下得太早。

AI 補丁落差：補好了，為什麼仍有空窗？

可以把軟體更新想成換鎖。維修師傅已經做出新鎖，甚至公開了改了哪個零件；但新鎖還在送往住戶的路上。這段期間，舊鎖仍在服役，公開的修改又可能讓旁人猜到舊鎖哪裡薄弱。

這就是 patch gap。Google 的 Chrome 安全團隊也明確描述：修補進入公開程式碼後，攻擊者可能在修補到達使用者電腦前反向分析。因此，程式碼合併、正式版發布、使用者完成更新，是三個不同時點。Epoch 這次聚焦前兩者之間的空窗；把所有責任都歸給「使用者不更新」，會看錯它測的問題。

研究觀察到了什麼？先保留測試條件

這次的新消息是研究披露，而非新模型上市。Z.ai 的 GLM-5.3 官方模型卡已提供本機部署文件與權重入口。可下載權重，與只在一家供應商的服務內使用模型，有不同的部署與管控邊界；不過 Epoch 的這次實驗使用的是第一方及第三方 API，不能改寫成「在一般筆電實測」。

依 Epoch 的方法與結果，研究者在隔離、無網路環境提供工具及各目標版本發布當時已公開的材料，讓 GLM 5.3 自主迭代。報告列出的六版是 156.0、156.0.1、157.0、157.0.1、158.0、158.0.1；環境為 Ubuntu 26.04、預設安全設定與官方 Firefox。團隊回報，造訪模型建出的頁面後，可讀取本機檔案並傳出。這是研究團隊的觀察，本文未重現攻擊。

原文安全附錄還披露，部分故障測試環境曾讓 Agent 在沙箱外採取動作，團隊因而暫停測試；據報告，事件不涉及網路連線或惡意行為。這提醒我們，隔離是設計目標，仍須持續驗收。「自主」描述的是任務開始後的工作，仍須把研究者搭環境、選材料和定義成功的工作算進來。模型外面那一圈工具、狀態與執行流程，可參照 Agent Harness 的分工；研究成績應連同這些條件一起讀。

AI 補丁落差的 1,000 美元，是哪一本帳？

The attacks took substantial effort for the model to develop.

中文：模型為了開發這些攻擊，也投入了相當多的工作。

Epoch AI，Results

原文回報：給模型的時間上限是 48 小時，最快一次約 12 小時。Firefox 研究的 API 總支出超過 10 萬美元，包含前期摸索與離線環境建置；約 1,000 美元是環境建好後，每攻下一個新版本的邊際 API 成本。這些數字來自同一份研究，並非外部審計的通用價目。

把它想成開工廠：設計產線的費用，與產線運作後多做一件產品的費用，回答不同問題。用「人人花 1,000 美元就能入侵任何瀏覽器」概括，會同時抹掉前置投入、目標差異與成功條件；只盯著十萬美元，又會漏掉流程一旦可重用，後續成本可能下降的意義。

最重要的限制：成功依賴一條漏洞鏈

依原文及註腳，成功鏈串接了補丁落差漏洞與另一個未公開漏洞，後者讓讀檔得以跨過沙箱邊界。團隊稱已通報 Mozilla，並在 10 月 27 日的 Firefox 159.0 修補該漏洞。Mozilla 的 159 安全公告可獨立確認發布日期與修補版本；這份公告本身並未替 Epoch 公開整條實驗鏈的對應關係。

因此要把「已修補這條鏈中的關鍵漏洞」與「往後所有同類攻擊都失效」分開。Epoch 在發文時尚未確認 159.0 上能否成功做出同類攻擊；它也明寫，對近期 Firefox 尚無任意程式碼執行的成功結果。內容程序內取得執行能力，與在使用者系統任意執行程式，屬於不同層次；研究展示的檔案外洩已經嚴重，無須再把成果加碼。

Chrome 的比較也有界線：團隊回報另花約 10 萬美元 API 費，仍未在相似設定做出等價成果。這支持「本次兩個目標的觀察不同」，不能推成 Chrome 永遠安全，也不能把 Firefox 六個相關版本當成六套完全獨立的防禦架構。

拒絕機制與現實危害，仍要分別量

Epoch 還回報，以安全演練包裝這次 API 任務時，未遇到拒絕或供應商限制。這是特定測試條件下的觀察，不能替所有供應商、提示或日期作保證。更值得追問的是：服務端的使用管控、模型本身的行為、下載權重後的部署控制，各自能管住哪一層？

能做出攻擊，與現實中造成多少損害，中間還隔著目標分布、接觸使用者、更新速度、偵測與應變。Nathan Lambert 10 月 30 日的反思同樣強調，漏洞能力與實際傷害之間還有多個環節。這個區分有價值；但也不應把尚未看到大規模損害，當成技術能力不存在的證明。

AlphaLab 的判讀：該縮短的是交付時間，也該提高證據標準

一、我同意：公開修補應被視為安全交付事件

一份差異檔可以同時是維護者的成果與攻擊者的線索。若工具能更快讀懂差異，防禦流程就應把「什麼時候公開」與「什麼時候可部署」排在同一張時程表上。這不等於把整個開源專案關起來；對敏感修補採取協調發布，以及縮短測試、簽署、分發的等待，都值得按效果評估。

這也不是等到這份報告才開始的工作。Mozilla 5 月的發布流程公告規畫自 Firefox 151 起增加每週小版本發布機會，並保留依品質跳過的裁量。Google 的安全文章則表示，除了每週安全更新，還在試行每週兩次。發布頻率有幫助，實際修補到達時間才是驗收結果。

二、我存疑：從一次攻擊評估，直接算出開放權重的淨危害

本研究的題目是能否攻破指定目標；它沒有同時量出防禦者多修了多少漏洞、縮短多少暴露時間、承擔多少誤報。要回答開放權重究竟使社會更安全或更危險，應把這些帳放回來。把所有好處或所有壞處歸給模型開放方式，都超出了這份實驗能識別的因果範圍。

同理，模型發布者的能力宣傳不能替代獨立驗證；第三方研究的成功也不自動變成無條件的能力保證。最有用的下一份證據，是修補後的重新測試、跨平台比較，以及更多不同軟體的結果，並公開足夠的條件供外界判讀。

三、我會追：修補後，這條攻擊鏈還剩多少可行性？

研究最值得繼續對帳的問題，是關鍵環節被封住之後，原有流程需要多少時間與成本，才能找到另一條路。若同設定在修補後失敗，那是防禦有效的證據；若改用其他漏洞再成功，則要重新記錄前置材料、嘗試次數與成本。不要把前一條鏈的成功收據，直接貼到下一個版本。

今天能做什麼：使用者驗更新，維護者驗交付

若你使用 Firefox，先依 Mozilla 的更新說明檢查版本並完成所需重啟；官方下載版可從「關於 Firefox」檢查，Linux 發行版套件與 Microsoft Store 安裝則走各自更新渠道。確認執行中的版本，比只看到「已下載」更接近真正的完成。

維護軟體的團隊，可以先挑一項已修補的高風險問題，留下「首次公開、正式發布、受管裝置完成套用」三個時間點，再找等待最久的一段。對可能串接的漏洞，評估整條鏈是否已被阻斷，不用單看修了幾張工單。

若團隊也在導入 Agent，將對外連線、檔案存取與停止權限寫成可驗收的控制，可接著看 safeagents 的警告與阻擋測例及 拒絕之後仍須驗收的隔離邊界。那些測例處理的是各自的系統邊界，不是這次瀏覽器漏洞的修補工具。