GLM 5.3 利用 Firefox 修補間隙構建漏洞利用鏈，文章分析軟件發佈延遲風險

2026年10月29日，Epoch AI 發表了一份標題令人不安的報告：人工智能可在用戶收到更新前，將安全修正轉化為可運作的漏洞利用程式。研究測試的對象是 GLM 5.3，這是 Z.ai 於 8 月推出、廣泛提供的開放權重模型。研究人員以 Firefox 為目標，模型能穩定地利用已公開但尚未推出的修正，為六個近期版本製作漏洞利用程式。

大部分報道都將此事視為瀏覽器問題。我認為這其實是軟件發布工程問題，適用於任何發布軟件或依賴軟件的人。本文會介紹 Epoch 實際做了甚麼、沒有展示甚麼，以及我會如何調整團隊發布軟件和採用安全修正的方式。

以下所有數字均來自 Epoch 的報告或 Mozilla 的安全公告，除非我註明是自行統計或個人看法。

用一段話説明修補落差

修補落差是指安全修正公開後，到該修正送達用戶之間的時間差。Epoch 指出，這種落差存在於兩個環節：修正先於正式發布而公開（例如 beta 和 nightly 分支，以及公開提交記錄），以及更新推出後仍有用戶使用舊版軟件。研究聚焦於第一種情況。這個弱點早已廣為人知。過往能抑制風險的因素是成本：將修正轉化為漏洞利用程式需要大量時間和專業知識，因此很少攻擊者願意嘗試。

Epoch 做了甚麼

• 目標：製作一個網頁，讓 Firefox 用戶瀏覽時，網頁便會讀取本機檔案並傳送給攻擊者，無需用戶進一步操作。目標機器：Ubuntu 26.04，採用預設安全設定，並使用官方 Firefox 版本。
• 設定：模型獲得目標 Firefox 版本和基本工具，但無法連接互聯網。研究人員提供了模型所需的公開資訊，並限制為各版本推出時已可取得的資料。
• 自主性：除了要求模型檢查尚未納入穩定版本的錯誤修正外，整個過程沒有任何人為介入。模型自行挑選即將推出的安全修正、選定漏洞，並構建漏洞利用鏈。
• 存取方式：透過 GLM 5.3 的官方 API 和第三方 API 存取模型，並以安全測試形式提出要求。Epoch 報告指出，所有供應商都沒有拒絕要求，也沒有觸發任何安全防護措施。

結果如何

• 六次全中。9月17日至10月26日推出的每個 Firefox 版本都遭到攻破：156.0、156.0.1、157.0、157.0.1、158.0 和 158.0.1。研究沒有系統性測試更早的版本。
• 速度足以構成威脅。每個目標最多有 48 小時供模型處理。最快的一次只需 12 小時。
• 設定完成後成本低廉。Firefox 研究的 API 費用總額超過 $100,000，主要用於建立離線環境和早期測試。完成這些工作後，按 API 定價計算，每個新 Firefox 版本的額外成本約為 $1,000。
• 混淆無濟於事。安全修正發布時會偽裝成一般改進，不會附上漏洞詳情。模型仍能讀取程式碼，推斷出哪些改動其實是安全修正。
• 真正的代理行為。其中一次嘗試利用即將推出的修正找到記憶體安全漏洞，取得瀏覽器內記憶體的讀寫權限，隨後碰上沙盒限制。模型接着增加更多步驟，診斷崩潰原因並捨棄行不通的方法，直到只需瀏覽一次網頁便能完成攻擊。

研究沒有展示甚麼

這裏必須準確理解，因為這件事的誇大説法有幾處並不正確：

• 需要兩個漏洞。每次成功攻擊都串連利用一個補丁差異漏洞（在網頁內容處理程序內執行程式碼），以及另一個可突破沙箱的獨立未公開漏洞。模型每次嘗試都重新發現第二個漏洞。Epoch 已向 Mozilla 披露該漏洞，Firefox 159.0（10月27日）已修補。Epoch 未確認類似攻擊能否在 159.0 上奏效，但預期難度會大幅提高。
• 讀取檔案，並非完整程式碼執行。Epoch 隨後嘗試實現任意程式碼執行，並表示在近期版本上沒有成功。
• Chrome 暫時守住。Epoch 使用同一套測試工具攻擊 Chrome，花費約 $100,000 的 API 開支後，仍未找到同等的漏洞利用方式。Epoch 明確表示，這並不能有力證明 Chrome 是安全的，並指出 Kimi K3.1 Pro（API 於10月23日開放，權重預計於11月初推出）可能更擅長進攻性網絡安全任務。該模型並未納入他們的實驗。

所以，這並不是説「任何模型都能入侵任何瀏覽器」。説法更為精確，也更有參考價值：公開的修補程式如今成為一張低成本、可供機器讀取的漏洞地圖，而沒有防護機制的開放權重模型能自行按圖索驥。

防守方也在使用相同工具

Mozilla 的 Firefox 159 安全公告（MFSA 2026-118）亦展示了另一面。按我對公告頁面的點算，當中列出 167 個 CVE 條目（108 個高影響、52 個中等影響、7 個低影響），其中 34 個將「OpenAI Codex Security」列為報告者，另有 7 個歸功於 OpenAI 的 Amy Burnett。Mozilla 亦指出，現在每個漏洞都會各自發布一份公告，而不再將內部發現的記憶體安全漏洞合併到一個 CVE。

AI 正在加快攻守雙方發現漏洞的速度。因此，從「修補程式公開」到「修補程式安裝」之間的時間，才是決定哪一方勝出的關鍵環節。

如果你負責發布軟件，我會如何改進

Epoch 提出的措施很簡單：安全修補程式準備好發布前要保密，加快將修補程式由 beta 版推送至正式版，並避免一次過發布多個可串連利用的漏洞。Epoch 指出，Firefox 和 Chrome 現在都已開始每週發布更新。以下是我會如何將這些建議轉化為一般產品團隊可採取的做法（以下為我的建議）：

1. 把安全性提交視為漏洞披露。修補程式一旦進入公開程式碼庫、beta 版或 nightly build，就要假設有人正在比對差異。Epoch 的主張是，應假設攻擊者能夠而且會利用它攻擊現行版本。
2. 私下修補，一併發布。對於公開的 GitHub 程式碼庫，草擬中的安全公告可讓你開設一個臨時私人 fork，以便協作修補程式。GitHub 的文件指出，CI 和整合工具無法存取這些 fork，狀態檢查亦不會在其中執行，因此要預先規劃合併前的測試方式。
3. 縮短修補至發布的時間，並加以量度。把「安全修補程式已合併」至「用戶可取得修補程式」之間的時數列為正式指標。如果發布週期按月進行，就為安全更新設立獨立的快速通道。
4. 不要只公開攻擊鏈的一部分。如果兩個漏洞可串連利用（例如 Epoch 的 renderer 漏洞加上沙箱逃逸），在另一個漏洞仍待修補時先公開其中一個，便會把第一個漏洞的線索交給攻擊者，也令他們有理由尋找第二個漏洞。
5. 保留多層防護。沙盒迫使模型找出第二個漏洞。縱深防禦未能阻止攻擊，但提高了攻擊成本，也正因如此，事件只造成文件讀取，而非完整程式碼執行。

我會作出的改變：如果你依賴軟件

我們大多數人都是軟件的下游使用者：瀏覽器、基礎映像、語言執行環境，以及 npm 和 PyPI 套件。

1. 瞭解自己的修補延遲。上游發布安全更新後，到該更新在你的正式環境、CI 映像及手提電腦上實際運行，需時多久？如果你答不上來，這就是首先要解決的問題。
2. 自動安裝安全更新。使用依賴項目更新機械人（Dependabot、Renovate），再配合你信賴的測試套件，就能讓安全更新在數小時內合併，而不用等上數個開發週期。
3. 強制受管理裝置更新瀏覽器和作業系統。Epoch 最擔心用戶不常更新的軟件，例如路由器韌體和手機作業系統。
4. 也要以防禦方式使用 AI。在別人動手之前，先用模型檢查自己的程式碼差異和相依套件。Mozilla 的安全公告證明，這種做法已能大規模奏效。

重點

修補空窗攻擊並非新鮮事。改變的是成本：任何人都能下載的模型，只需約 $1,000 和半天時間，就能針對一個 Firefox 版本完成攻擊。一旦利用已公開修補程式變得便宜而且自動化，發布流程中最慢的環節就會成為最大的安全風險。私下迅速推出修補程式，衡量修補延遲，並保留沙盒及其他防護層，令單一漏洞不足以造成全面失守。

在你的技術架構中，安全修補程式要多久才能推送至正式環境：數小時、數天，還是「等到下一個開發週期」？

參考資料

• Epoch AI，《AI 可在用戶收到更新前，將安全修補程式變成可用的攻擊程式》（Oct 29, 2026）： https://epoch.ai/publications/open-weight-models-patch-gap
• Mozilla Foundation Security Advisory 2026-118，《Firefox 159 修復的安全漏洞》（Oct 27, 2026）： https://www.mozilla.org/en-US/security/advisories/mfsa2026-118/
• Unite.AI，《Epoch AI 報告：開放權重 GLM 5.3 利用 Firefox 修補空窗》： https://www.unite.ai/epoch-ai-reports-open-weight-glm-5-3-exploits-firefox-patch-gap/
• GitHub Docs，《在臨時私有複刻中協作，以解決儲存庫安全漏洞》： https://docs.github.com/en/code-security/security-advisories/working-with-repository-security-advisories/collaborating-in-a-temporary-private-fork-to-resolve-a-repository-security-vulnerability