漏洞簡介
CVE-2026-98432 是 Linux 核心 IPv4 TCP 交握程式碼中的競爭條件，可導致 use-after-free。此錯誤邏輯自 Linux 4.4 起便已存在。當新連線完成時，核心會將待處理請求的 IP 選項轉移到新 socket，但未進行複製。若該 socket 在另一個 CPU 仍使用這些選項回應重傳連線請求時被銷毀，核心便會讀取已釋放的記憶體。IPv6 不受此特定競爭條件影響。核心 CVE 小組將此問題的 CVSS 分數評為 9.8，視攻擊複雜度為低。部分發行版最初給予較低分數，理由是贏得競爭條件較困難，但 Red Hat 後來已調整評估，趨向較高分數。
上游修正已在十月初套用，並回溯至維護中的穩定核心分支。Debian、Oracle Linux（其 UEK 核心）以及部分 Amazon Linux 與 SUSE 套件已推出修正核心。截至 2026 年 11 月初，Ubuntu 的支援版本（包括近期 LTS 與雲端版本）以及 Red Hat Enterprise Linux 8、9 與 10 仍將此問題列為易受攻擊或進行中，尚未釋出修正套件。RHEL 7 不受影響，因為其核心不含易受攻擊的程式碼。
已展示的遠端 Root 攻擊利用 multipath TCP（MPTCP）監聽器作為進入點。Anthropic 未公開的研究模型產生了兩階段攻擊：先洩漏核心指標以繞過 KASLR，然後利用同一 use-after-free 覆寫回呼並以 root 執行指令。CVE 記錄與核心修正均未提及 MPTCP；此關聯來自 Anthropic 的說明文件。底層錯誤存在於一般 IPv4 TCP 連線建立，因此未使用 MPTCP 的服務並非自動安全。MPTCP 設定僅提供了展示完整 Root 攻擊的可靠途徑。
實際後果是任何接受 IPv4 TCP 連線的 Linux 主機，在核心更新前均處於暴露狀態。已證明的最高優先攻擊面，是任何開啟 MPTCP 監聽器的行程。這正是近期 Go 執行環境預設行為立即相關的原因。
為何 Go 服務成為實際暴露面
自 Go 1.24 起，標準函式庫在 Linux 上只要核心支援，便預設為監聽器啟用 Multipath TCP。此變更僅適用於伺服器端。撥號器除非明確設定，否則仍使用一般 TCP。因此，類似 `net.Listen("tcp", …)` 的常見呼叫便會建立 MPTCP 監聽 socket，而應用程式中無需出現任何 MPTCP 相關程式碼。大多數 Go HTTP 伺服器、gRPC 服務、反向代理，以及使用 Go 1.24 或更新版本建立的自訂監聽器，因此均暴露了 Anthropic 模型用以取得遠端 Root 的確切設定。
此預設由 `multipathtcp` GODEBUG 設定控制，在 Go 1.24 中設為 listeners-only。操作人員可透過兩種方式覆寫：在執行階段設定環境變數 `GODEBUG=multipathtcp=0` 以停用監聽器與撥號器的 MPTCP；在主模組的 `go.mod` 檔案中加入 `godebug multipathtcp=0`（或使用 `//go:debug` 指示詞）則在建置階段設定相同行為。對 `ListenConfig` 或 `Dialer` 明確呼叫 `SetMultipathTCP` 會覆寫 GODEBUG 值，因此這些位置必須另外稽核。Go 安全團隊指出逐個程式停用是脆弱的緩解措施：單一剩餘的 MPTCP 監聽器便足以重新引入已展示的攻擊途徑，而底層核心錯誤並不限於 MPTCP。
偵測相當直接。指令 `ss -Mltnp`（或 `ss -lnMp`）會列出 MPTCP 監聽器及其擁有行程。在典型的 Go 服務中，輸出會同時顯示一般 TCP 監聽器（`ss -tlnp` 等工具所見）以及對應的 MPTCP socket。套用 `GODEBUG=multipathtcp=0` 並重新啟動行程後，MPTCP 項目應會消失。在系統層級，`sysctl net.mptcp.enabled=0` 可防止建立新的 MPTCP socket，但現有監聽器會維持直到其行程重新啟動。這些步驟移除了已證明可被利用的設定。它們無法修復核心中的 use-after-free，因此仍是過渡措施，直至安裝修正核心並重新啟動主機為止。
攻擊程式碼未公開，但地圖已公開
Anthropic Frontier Red Team 公開了 CVE-2026-98432 有效遠端 Root 攻擊的高層次說明，但保留了攻擊程式碼、測試時使用的精確核心版本與設定，以及任何可立即執行的概念驗證。所公布的是成功途徑的清晰描述：以 MPTCP 監聽器為進入點，重複贏得 IPv4 TCP 交握競爭以洩漏核心指標並繞過 KASLR，接著利用同一 use-after-free 覆寫回呼指標並以 root 執行任意 shell 指令。說明指出失敗的競爭條件只會中止個別連線嘗試，而不會讓系統崩潰，允許攻擊者無限重試。在報告的實驗執行中，位址洩漏約需 48 分鐘，指令執行再多 5 分鐘。
該描述已足以作為他人開始工作的地圖。幾年前，將此類說明轉化為可靠的遠端 Root 攻擊需要專業的核心知識與長時間的手動迭代。如今可將相同文字提供給如 Qwen 等具能力的開放權重模型，在容易取得的 GPU 叢集上執行。這些模型不會在第一次嘗試便產生完整攻擊，但能大幅降低探索、除錯與優化的成本。多個獨立團隊現可並行執行該搜尋，從而降低先前將此類工作限制在少數研究者的門檻。
至今公開材料仍有限。研究工具包已展示觸發競爭條件並取得記憶體洩漏的能力，但尚未有任何工具宣稱重現 Anthropic 所述的完整 KASLR 繞過與 Root 載荷階段。尚未有野外利用報告，此問題亦未出現在 CISA 的已知被利用漏洞目錄中。因此，現實預期並非立即湧現公開攻擊，而是從地圖公布到獨立可用版本出現的時間明顯縮短。對於仍暴露 MPTCP 監聽器的 Go 服務操作人員，此時間間隔正是過渡緩解措施最重要的時期。
Kubernetes 與服務網格的現實情況
此漏洞存在於節點執行的 Linux 核心。它在 IPv4 TCP 交握期間被觸發，任何封包到達容器、sidecar 或應用程式之前。容器映像、pod 安全情境與服務網格設定因此無法彌補此差距。節點上安裝修正核心（後續重新啟動，或供應商提供的即時修補若存在）仍是最終解決方案。在該核心到位前，排程至該節點的每個 pod 均繼承底層主機的暴露風險。
許多 Kubernetes 控制平面元件、operator 與自訂控制器均以 Go 撰寫。當這些二進位檔以 Go 1.24 或更新版本建置時，除非明確停用，否則會繼承 MPTCP 監聽器預設。以近期 Go 撰寫的工作負載行為亦相同。Envoy（大多數服務網格使用的資料平面代理）預設不會啟用 MPTCP。其支援是一項必須在設定中開啟的明確監聽器選項。因此，網格本身很少是已展示攻擊面的來源，而位於網格後方或旁邊的 Go 服務則經常是。
網路原則、相互 TLS 與 sidecar 攔截均在核心已接受並處理 TCP 交握之後才運作。它們無法阻止發生在交握內部的 use-after-free。能夠連上節點監聽埠的攻擊者可嘗試競爭條件，無論最終流量是否會被網格加密或授權。對平台團隊的實際意義是，網格控制對許多其他威脅仍具價值，但無法取代節點核心修補，或移除 Go 元件中 MPTCP 監聽器的過渡步驟。在仍自行於 Ubuntu 或 RHEL 上執行叢集的環境中，節點核心的時程仍是操作人員的責任。
等待核心修正期間的過渡措施
第一個實務步驟是盤點。在每個節點執行 `ss -Mltnp`（或 `ss -lnMp`）以列出所有 MPTCP 監聽器及其擁有行程。將這些行程與已知的 Go 二進位檔交叉比對。對於任何以 1.24 或更新版本建置的 Go 服務，透過檢查環境或建置時使用的 `go.mod` 檔案，確認 MPTCP 預設是否仍處於啟用狀態。此舉可快速區分 Anthropic 已展示的設定與僅受較廣泛 use-after-free 影響的一般 TCP 監聽器。
若 Go 服務可重新啟動，請停用預設。在行程環境中設定 `GODEBUG=multipathtcp=0`，或在主模組的 `go.mod` 中加入 `godebug multipathtcp=0` 並重新建置。重新啟動後，再次執行 `ss` 指令確認 MPTCP socket 已消失。在完全未使用 MPTCP 的主機上，`sysctl -w net.mptcp.enabled=0` 可防止建立新的 MPTCP socket。但現有監聽器會維持直到行程重新啟動，因此僅設定 sysctl 並不足夠。這些變更無需等待發行版核心即可移除已展示的 Root 途徑。
額外強化措施可在未修補核心仍存在期間降低成功競爭條件的機會。在主機防火牆或網路邊緣過濾攜帶 IPv4 選項（Record Route 或 Timestamp）的傳入封包，可限制核心 CVE 小組用於評分的其中一項條件。監控重複失敗的交握或意外的核心記錄項目可提供早期訊號，雖然攻擊設計為避免讓系統崩潰。若供應商針對特定 CVE 提供即時修補，請套用它。以上措施均無法修復 use-after-free 本身。
上述所有步驟均屬過渡。它們縮小或移除已證明可產生遠端 Root 的設定，並可能使其他利用嘗試更為複雜。它們無法消除底層核心錯誤。單一被忽略的 MPTCP 監聽器、明確的 `SetMultipathTCP(true)` 呼叫，或未來不再需要 MPTCP 的攻擊改良，均可能重新開放暴露。唯一持久的解決方案是節點上安裝並執行修正核心。在 Ubuntu 與 RHEL 推出這些套件前，盤點與停用措施仍是操作人員可用的最高槓桿控制。
對平台團隊的意義
CVE-2026-98432 具體說明了組織自行執行 Kubernetes 叢集時仍須承擔的剩餘責任。服務網格原則、網路控制與容器強化可處理許多應用層威脅，但它們將節點核心的時程留在操作人員手中。Ubuntu 與 RHEL 尚未針對此問題釋出修正套件，而 Debian 與其他部分發行版已推出。節點仍使用前述發行版的團隊因此面臨較長的暴露窗口，相比已包含上游修正的基礎映像或託管平台。對基於合規或支援理由而標準化使用 Ubuntu 或 RHEL 的銀行、保險公司及其他受監管操作人員而言，該窗口是操作事實而非抽象風險。
此事件亦突顯現代執行環境中沉默預設的累積效應。Go 決定在監聽器上啟用 MPTCP 是基於效能與未來相容性理由，且已有文件記錄。但實際上，它產生了廣泛部署的設定，與已展示的遠端 Root 途徑完全吻合，卻未經應用程式擁有者任何明確要求。其他堆疊中亦存在類似預設。將語言與執行環境行為視為容器內部實作細節的平台團隊，可能錯過僅在核心漏洞公布後才會顯現的主機層級暴露。包含節點核心版本與長期執行服務有效 socket 選項的盤點流程，可減少此類意外。
最後，公開技術地圖與廣泛可用的開放權重模型的結合，縮短了過渡控制足以應付的時間間隔。已將節點核心修補納入可預測節奏，或使用安全回應較快的發行版核心的組織，能以較少干擾吸收此類問題。仍在等待 Ubuntu 或 RHEL 套件的組織，必須將 Go MPTCP 預設視為立即、可逆的控制措施，直至核心更新準備完成。更廣泛的教訓是，商品化 Kubernetes 並未消除擁有主機作業系統生命週期的必要。它只是改變了該擁有權變得可見的時點。
結論與後續步驟
優先順序明確。每個節點上的修正核心是唯一能關閉 use-after-free 的措施。在 Ubuntu 與 RHEL 推出這些套件前，最高槓桿的過渡控制是從 Go 服務及其他開啟它們的行程中移除 MPTCP 監聽器。此步驟消除了 Anthropic 模型用以取得遠端 Root 的設定。它無法修復核心錯誤，亦無法防護未來所有可能的攻擊改良，但能有意義地縮減已證明的攻擊面。
立即檢查成本低廉。在每個節點使用 `ss -Mltnp` 列出 MPTCP 監聽器，找出任何 Go 1.24 或更新版本的二進位檔，並套用 `GODEBUG=multipathtcp=0`（或對應的 `godebug` 指示詞）後重新啟動。若未使用 MPTCP，請設定 `net.mptcp.enabled=0` 並確認無監聽器殘留。記錄目前核心版本與發行版的公告狀態，以便最終套件出現時無需額外探索即可套用。這些動作在大部分機群上可在數小時內完成，並在供應商核心準備期間爭取時間。
對在 Kubernetes 上執行 Go 工作負載的團隊而言，此事件提醒即使在服務網格部署後，節點核心的更新仍是操作人員的責任。網格控制對許多其他威脅仍具意義。它們無法取代核心更新或短期移除已展示的 MPTCP 攻擊面。將主機作業系統生命週期視為第一級平台關注的組織，將能以較少干擾吸收此類問題。仍將其視為外部依賴的組織，將在公布後才發現，安靜修復的窗口已大幅縮窄。實際的下一步是今天執行盤點，並在 Ubuntu 與 RHEL 核心套件出現後立即將其置於關鍵路徑上。
參考資料
The Hacker News，「Linux Kernel TCP Flaw With 9.8 CVSS Score Affects Ubuntu, Red Hat and Other Distributions」，2026 年 10 月 29 日。
Anthropic Frontier Red Team 研究揭露（多份同期報導引用），2026 年 10 月 27 日。
Go 安全團隊於 golang-announce / oss-security 就 CVE-2026-98432 與 MPTCP 預設發佈的通知，2026 年 10 月 29 日。
Linux 核心 CVE 記錄 CVE-2026-98432（kernel.org CNA）。
Ubuntu CVE 追蹤器與 Red Hat CVE 頁面關於 CVE-2026-98432（截至 2026 年 11 月初的狀態）。
Debian、Oracle Linux、Amazon Linux 與 SUSE 的修正套件發行公告。