CVE-2026-111497：一個 Brotli 漏洞、九個執行環境，以及發現它的 Codex 代理程式

CVE-2026-111497 棘手的地方在於，它不是單一產品裡的單一漏洞。它是 Google 的 Brotli 解壓縮器中的一個越界寫入，而相同的錯誤可透過至少八個內嵌該程式庫的獨立執行環境與代理伺服器觸及——Node.js、.NET 與 ASP.NET Core、Python 的 Brotli 與 brotlicffi、Bun、Envoy、Istio，以及純 Go 實作。Wiz 的量測結果顯示，91% 的雲端環境處於風險之中，並指出其中 82% 公開暴露 Node.js。CISA 已將其加入「已知遭利用漏洞」清單，而微軟也針對 .NET 與 Visual Studio 發布了緊急修補程式。

故事的後半段講的是發現者是誰：根據 Wiz 的報告與上游致謝名單，發現者是 OpenAI Codex Security 的 Khai Tran 與 Sylvie Mayer。那是一個 AI 安全代理團隊，而它發現的漏洞，位於網路上被嵌入得最廣泛的單一解壓縮函式庫中。

這個 Bug 會做什麼

當伺服器送出code>Content-Encoding: br/code> 時，幾乎所有 HTTP 堆疊都會解壓縮 Brotli。格式錯誤的壓縮串流會在解壓縮期間造成越界寫入，而 CVSS v4 分數為 9.2。受影響範圍為 Brotli 1.0.3 至 1.2.0，已於 1.0.10、1.1.1 和 1.2.1 中修正。

它之所以是一項計畫而非一張工單，是因為這個函式庫在每個執行環境裡都是以 vendored 方式內嵌、靜態連結或重新實作，因此每種情況下的修正都得經由不同的發布列車送達——有時甚至完全不會到來，因為某個語言的標準發行版有自己的副本。

修補程式清單，那才是有用的部分

以下每一項數據均來自 Wiz 的諮詢摘要及各專案的發布公告，查閱日期為 2026 年 10 月 30 日。

• Google Brotli / libbrotli — 受影響版本為 1.0.3–1.2.0，不含已修補的向後移植版本；已於 1.0.10、1.1.1、1.2.1 修正。

• Python Brotli — 受影響版本為 1.0.3–1.2.0；已於 1.2.1 修復。 brotlicffi — 受影響版本為 1.0.3–1.2.0.x；已於 1.2.1.0 修復。

• Node.js — 受影響版本為 22.x、24.x 與 26.x；已於 22.23.4、24.22.1 與 26.12.1 修正。

• Bun — 受影響版本為 1.0.21–1.4.3；已於 1.4.4 修復。

• Envoy Proxy — 受影響版本：1.36.11、1.37.7、1.38.5、1.39.2；已於 1.36.12、1.37.8、1.38.6、1.39.3 及 1.40.0 修復。

• Istio — 受影響版本為 1.29.0–1.29.8、1.30.0–1.30.5、1.31.0–1.31.1；已於 1.29.9、1.30.6 和 1.31.2 修復。

• andybalholm/brotli (Go) — 受影響版本為 v1.2.7 之前；已於 v1.2.7 修復。

Node.js 那一列，是決定大多數人這週怎麼過的關鍵。執行於 22.22.x 的服務即使應用程式碼從未提及 Brotli，仍會透過其 HTTP 堆疊暴露，因為解壓縮會在呼叫你的處理常式之前發生。這也解釋了業界為它冠上的三個名稱：Node 路徑的 Node2Shell、Check Point 所記錄的代理路徑的 HTTP2Shell，以及 JFrog 從更全面角度提出的 Brotli2Shell。

為什麼「91%」才是值得爭論的數字

Wiz 的資料描述的是 Wiz 客戶的雲端資產，而非整個網際網路。計算有多少環境在某處含有易受攻擊的程式庫，並不等於計算有多少可遭利用的服務，而兩者差異很大：桌面應用程式內建、從不解壓縮不受信任輸入的 Brotli，只是一項發現，不是漏洞。這項統計更有用的版本範圍更窄——也就是接受來自不受信任來源之壓縮輸入的服務，而這基本上涵蓋每一個公開 HTTP 端點終止於 code>br/code>.

有兩件事讓實際利用顯得可信，而不只是理論上的可能：CISA 將其加入 KEV 目錄，意味著已觀察到實際利用；而蜜罐操作者也記錄到嘗試。當某個漏洞跨入「已遭實際利用」這一欄，修補期限就不再是你變更控制流程的行事曆，而是別人的。

發現是半衰期較長的那部分。

前沿模型的安全團隊在一個十年來已有數千人讀過的解壓縮函式庫中，發現了一個記憶體安全漏洞。這不是某個廠商很聰明的故事，而是關於覆蓋率的陳述。靜態分析多年來一直針對 Brotli，模糊測試框架也已存在，而這個漏洞卻躲過了這兩者——同時，一個以理解意圖的方式閱讀程式碼的代理找到了它，並產出了上游已接受的修正。

不對稱性是把雙面刃。能找到這類錯誤的同樣能力，也會在你交付的程式碼中找到它。對任何操作代理式編碼的人來說，問題不在於代理能否發現越界寫入；而在於這項發現是否會先送到你手上，而不是先落到別人手裡。

該做什麼，按輕重緩急排序

• 修補你實際執行的執行階段。上面的函式庫清單是依據；先從負責終止公開流量的那些開始。

• 接著尋找內嵌的副本。容器基礎映像、靜態二進位檔、WASM 建置產物與各語言 wheel 各自帶有自己的 Brotli，而它們都不會出現在應用程式的套件管理器稽核中。本週發布的一款儲存庫層級清單掃描器會遍歷檔案系統，並對它找到的每一份 Node、Bun 與 Brotli 副本進行評分；比起自己從頭打造一個，這是更快的起點。

能重建就重建，別只做修補。在已建置的成品裡替換靜態連結的程式庫，正是最容易不小心出貨半修好二進位檔的地方。

• 如果你將 Envoy 或 Istio 作為邊緣代理執行，請將這些代理程式修正視為整組修正中的最高優先事項：代理會代表其後方的所有項目進行解壓縮。

• 請另外檢查您的 .NET 環境。Microsoft 的修補程式涵蓋 .NET 與 Visual Studio，而正確的版本是執行階段更新，而非變更套件參考。

這對我們的讀者而言處於什麼樣的位置

這個部落格大多談的是模型能力、價格與路由。這件事會放在這裡，是因為有這麼一句話：這個缺陷是由 AI 代理發現的，而能找到這類錯誤的系統類型，正是我們的讀者正在接入自身管線的系統類型。一個在 CI 中針對你的相依套件執行的儲存庫掃描代理，如今已是一項安全控制措施，而它與撰寫你的程式碼的是同一個代理執行環境。

OrcaRouter 的 Agent Firewall 會在工具與 MCP 呼叫執行之前先進行評分，而這正是限制代理影響範圍（blast radius）的控制機制；它並不會讓代理的調查發現變得正確，而關於這個 CVE 的任何說法，也都不是在宣稱繞送模型能降低供應鏈風險。本週真正值得帶走的重點更為狹窄、也更可驗證：如果你讓代理取得儲存庫的讀取權限來找出錯誤，請確認它所提出的修補程式已被釘選（pinned），並確認你自己技術堆疊底層的執行環境已經推進到超過 1.0.3–1.2.0 的版本。

值得記住的模式是：這個漏洞存在於沒有人主動選擇的程式碼裡。Brotli 是隨著某項執行階段功能而來的遞移相依套件，在八個地方依各自不同的時程獲得修復，而且還會持續隨著本週之前就已建置的基礎映像檔一起出現。供應鏈應變多半就是一種紀律：找出那些你並未親自安裝的副本。

來源說明：受影響與已修復版本矩陣、執行階段清單，以及 91%/82% 的曝險比例數據，均來自 Wiz 於 2026 年 10 月 30 日所讀取的公告摘要；已修復版本則來自各專案自身的發布版本。9.2 的 CVSS v4 分數來自 CVE 記錄。發現歸功於 OpenAI Codex Security 的 Khai Tran 與 Sylvie Mayer，此資訊來自 Wiz 的撰文與上游致謝名單。CISA 的 KEV 清單與 Microsoft 的 .NET 修補程式分別為各自組織的公告；除公告摘要外，本文並未將兩者作為原始文件閱讀。inventory-scanner 的描述是第三方 GitHub 專案自身的描述。