CVE-2026-98432：Ubuntu 與 RHEL 仍未有修補程式，而 Claude 模型已寫出漏洞利用程式

關於 CVE-2026-98432 的這兩項事實擺在一起，令人難以心安。它是 Linux 核心 IPv4 TCP 握手流程中的釋放後使用（use-after-free）漏洞，可透過網路觸及，無需登入，也無需互動，而核心 CVE 團隊給它評了 9.8 分。截至 2026 年 10 月 30 日，Ubuntu 尚未為 22.04、24.04、26.04 或 26.10 發布修復程式；Red Hat 則將 RHEL 8、9 和 10 列為受影響，既無修復程式，也沒有官方背書的緩解措施。第二項事實是，10 月 27 日，Anthropic 發表研究指出，一個尚未發布的 Claude 模型針對設有 MPTCP 監聽器的伺服器，產出了可用的概念驗證，能在未經身分驗證的情況下取得遠端 root——大約 48 分鐘即可洩漏核心位址，再過五分鐘便達成命令執行。

一個兩大企業級 Linux 廠商至今仍無法修補的漏洞，還伴隨著一支部分由機器撰寫、可實際運作的漏洞利用程式，這可不是例行性的「Patch Tuesday」。這正是那種會決定你的核心升級流程與你的代理程式存取原則究竟有沒有任何關聯的案例。

這個 bug，用一段話說明。

TCP 連線建立時，傳入封包所附的 IP 選項會交接給新的 socket，而非複製。若握手發生重傳，封包可能會由不同於擁有選項緩衝區的 CPU 處理——而第二個 CPU 可能讀取第一個 CPU 已釋放的記憶體。請求遷移路徑上也存在類似的競爭條件。受影響範圍始於核心 4.4，也就是說大多數仍在執行受維護核心的機器。上游修正（提交 code>e3f33b0a1d89/code>）會延後釋放選項緩衝區，直到其他核心都不可能再持有參照。

可利用性源自其機制：沒有身分驗證、沒有使用者互動、有可從網路觸及的路徑，以及可反覆重試的競態。Anthropic 自己對於這項 PoC 為何切實可行的總結，正是這個特性——輸掉競態只會讓一次握手失敗，而不會使機器崩潰，因此攻擊者會再試一次。

三家供應商，三個嚴重程度數字

評分拆分才是值得你內化的部分，因為它決定你的掃描器這週會不會開出一張工單。

• 核心 CVE 團隊 — 9.8，嚴重。可從網路觸及，無需權限，無需互動。

• Red Hat — 8.1，重要。該公司的立場是，這場競賽在實務上難以取勝。

• Ubuntu——高優先度，已檢查的頁面上並未公布數值評分。

9.8 與 8.1 之間的落差，並非對這個漏洞本身有歧見，而是對贏得一場競態的機率有歧見。兩種評分都站得住腳，而這個差異在實務運作上影響重大：一個附有公開 PoC 的 9.8 是緊急事件，一個需要艱難競態的 8.1 則是排入排程的修補。在有人於真實硬體上公布重現數據之前，最誠實的解讀是：這場競態是可以贏的，因為據報有一個前沿模型贏了它。

誰有解決方案，而誰沒有。

截至10月29日至30日，情況並不均衡，而這種不均衡恰恰會讓那些以為核心穩定就等於已修補核心的人措手不及。

• Debian 12 bookworm — 已於 6.1.190-1 透過 DLA-4841-1 修正。

• Debian 13 trixie — 已於 6.12.113-1 透過 DSA-6568-1 修正。

• Ubuntu 22.04、24.04、26.04、26.10 — 尚無已發布的修正；處理中。

• Ubuntu 16.04、18.04、20.04 — 存在漏洞，尚未發布修正。

• RHEL 8、9、10 與 OpenShift 4 — 受影響，尚無修正，且無 Red Hat 認可的緩解措施。

• RHEL 6 與 7 — 不受影響。

• Amazon Linux 2023 — 核心 6.18 回報已修正；Oracle Linux UEK 回報已修正；SUSE 回報部分版本已修正，其他版本仍在測試中，但未指明版本。

帶有修正的上游穩定版為 5.10.272、5.15.223、6.1.190、6.6.159、6.12.113、6.18.56、7.2.10 與 7.3——如果你是自己編譯核心，而非採用發行版套件，這就是你該對照自身建置版本核查的清單。

為什麼 MPTCP 不斷被提起

這個漏洞並非 MPTCP 專有，而這正是許多報導出錯的地方。Red Hat 會把任何可觸及的 TCP 服務視為可能的觸發因素。MPTCP 提供的是已證實的路徑，而提供流量的則是 Go：在核心開啟 MPTCP 時，Go 1.24 及更新版本會預設為 Linux 監聽 socket 啟用多路徑 TCP。Go 的安全團隊在 10 月 29 日針對這個組合提出警告。

因此，「停用 MPTCP」移除的是 Anthropic 所展示的那條路徑，而不是漏洞本身。這是一項站得住腳的臨時措施，但有個具體但書：它值得今天就在 Go 服務上實施，且不能取代已修補的核心。

檢查很短：

• code>ss -Mltnp/code> — 列出目前正在使用 MPTCP 的通訊端。

• code>net.mptcp.enabled/code> — 核心功能是否整體啟用。

• code>net.ipv4.tcp_migrate_req/code> — 預設為關閉；如果你曾開啟它，請再次關閉。

就 Go 而言，code>GODEBUG=multipathtcp=0/code> 在執行階段，或 code>godebug/code> 這一行設定於 code>go.mod/code>，可讓該二進位檔選擇退出。

這些說法都沒有獲得廠商背書。Red Hat 明確表示，目前沒有任何緩解措施能符合其自身標準；這句話比列出一堆充滿希望的替代方案更有用。

Anthropic 實際發表了什麼

這項研究範圍狹窄且具體。一個尚未發布的 Claude 模型，在取得 CVE 以及一個帶有 MPTCP 監聽器的目標後，產生了一條利用鏈，約在 48 分鐘內洩漏出核心位址，並在大約五分鐘後達到命令執行。Anthropic 尚未公布該漏洞利用程式，而截至 10 月 29 日，無論是廠商或 CVE 記錄都未通報任何野外攻擊；該漏洞不在 CISA 的 KEV 目錄中。10 月 30 日，一個第三方 GitHub 儲存庫發布了用於觸發競態條件與記憶體洩漏的實驗室工具——一套重現測試框架，但尚未達到完整的程式碼執行。

那個組合才是有趣的部分。能力已被展示，武器則被保留，而關鍵細節——把脆弱競態變成可靠競態的重試特性——已以文字形式公開。任何能重現該競態的人，現在都知道為何值得堅持下去。

本週該做什麼

• 在有修正程式可用時，進行修補並重新開機。已安裝但尚未重新開機的核心修正程式不算修正；驗證方式為 code>uname -r/code>.

• 若你的發行版沒有修補程式——Ubuntu 22.04 至 26.10、RHEL 8 至 10——現在就決定：你要採用廠商的即時修補、改用已修復的版本，還是接受在 Go 服務上關閉 MPTCP 所帶來的曝險。

• 盤點 MPTCP 的暴露情形，而不是假設它已關閉。預設值是在 Go 裡變更的，不是在您的組態設定中；而預設值的變更在組態差異比對中是看不出來的。

• 演練重新啟動。這類修復需要完整重新啟動，而損失最多時間的組織，正是那些在維護時段才發現自身容錯移轉方案的組織。

這個 CVE 實際上提出的兩個問題

第一點是關於漏洞利用程式的生成，而且這不是哲學問題。有一個模型在不到一小時內，於一個具有特定啟用設定的目標上，找到了一組許多研究人員都未能找到的序列。無論這項漏洞利用程式是否公開，時間線已經改變：從公開公告到可運作的漏洞利用程式之間的窗口，現在是以會閱讀該公告的模型來衡量。

第二點要談的是：當廠商無法修補時，「修補」究竟意味著什麼。把核心一併交給你的發行版，和真正含有修正程式的核心，並不是同一個物件；而對這篇文章的大多數讀者來說，這個漏洞恰恰就活在兩者之間的落差裡。OrcaRouter AI Incident Archive 會把這類事件對照其原始出處、嚴重程度與信心水準加以索引；一旦新聞熱潮過去，這才是值得留存下來的那個版本。

不該做的事，就是把它歸類為「等供應商」。供應商自己的頁面就說，目前還沒有任何東西好等。

資料來源說明：此機制、自核心 4.4 起受影響的範圍、上游提交 code>e3f33b0a1d89/code>，以及穩定版本清單與緩解指引，均取自 2026 年 10 月 30 日所閱讀的 CVE 記錄與各發行版公告。9.8、8.1 與 Ubuntu High 評級分別為核心 CVE 團隊、Red Hat 與 Canonical 所給。各發行版的修補狀態取自 Debian 的 DLA-4841-1 與 DSA-6568-1、Red Hat 與 Ubuntu 的 CVE 頁面，以及同日廠商聲明。概念驗證時程、48 分鐘與五分鐘的數字，以及重試特性，係 Anthropic 10 月 27 日的研究，該研究未公開漏洞利用程式。10 月 30 日的實驗室儲存庫被描述為第三方所有，並非我們所有。