「210 萬台裸跑」怎麼算出來的：CVE-2026-98432 的掃描數字與修補狀態

CVE-2026-98432 的 210 萬台來自 MPTCP 可達性掃描，未確認核心是否修補，也沒有全部辨識為 Ubuntu。前篇〈Linux TCP 漏洞與修補檢查〉漏查部分已發布套件，這篇補上原始出處，並釐清停用 MPTCP 能處理的範圍。

210 萬量到什麼

Hutchins 原貼文說，他們在 10 月 30 日掃描 port 443，約 2,102,043 個端點可建立 MPTCP 連線，要求完成 TLS 的較深入測量則得到約 762,774 個端點。他隨即寫「Neither scan can confirm that these are unpatched kernels」，意思是兩次掃描都無法確認核心尚未修補，兩個數字不能相加或換算成未修補比例。

同文的 Mastodon 貼文發布於台北 11 月 3 日 14:44，文中的掃描活動觀察日是 11 月 2 日，自家測量則是 10 月 30 日。這些是他報告的數字，貼文未附資料集，本次也未獨立重現，不能當成 11 月 5 日的即時統計。

MPTCP 要開在哪裡

MPTCP 專案文件在 kernel build configuration 段將 Debian、Ubuntu、Red Hat、Fedora 列為通常已編入支援的發行版，CentOS Stream 9 與 10 的設定也明列 CONFIG_MPTCP=y，但這只回答核心有沒有這項功能。

上游 sysctl 文件寫 net.mptcp.enabled 預設為 1，控制各 network namespace 能否建立 MPTCP socket；RHEL 文件卻明載產品預設關閉。Debian 是否另用 sysctl 覆寫預設，查核時找不到可讀的套件來源，因此 Hutchins 所說 Debian 預設啟用，目前只能確認編入支援這一層，不能把上游預設當成發行版實測結果。Ubuntu、Fedora 的現行 sysctl 預設也未逐一核實，SUSE、Amazon Linux 與 Alpine 則沒有足夠的一手組態證據可在此列出。管理者仍應查自己使用的核心套件與 namespace，發行版名稱不足以代替主機設定。

這也解釋了為何專案頁把 Red Hat 列在支援清單，產品文件卻說預設關閉，兩份文件各自回答不同問題，不能任取一句替所有發行版下結論。

Go 1.24 release notes說，Linux 支援且允許 MPTCP 時，ListenConfig 預設使用它。GODEBUG 文件將預設值列為 multipathtcp=2，只開 listener，dialer 不在其中；GODEBUG=multipathtcp=0 可關掉預設，主模組宣告的舊 Go 版本也可能沿用舊行為。Go 團隊另說 net.ListenConfig.SetMultipathTCP 與 net.Dialer.SetMultipathTCP 能逐 socket 覆寫，不能概括成所有 Go 程式都會開啟。

net 套件文件也說明，主機沒有 MPTCP 或對端不支援時會退回 TCP，逐 socket 設定無法越過核心是否允許的限制。讀到 sysctl 為 1，只表示可以建立，還要確認程式是否要求使用，以及實際建立了什麼 listener。

Caddy v2.11.7 宣告 go 1.26.0，關閉預設的 PR未合併，維護者在 issue建議由系統管理者處理。所以 Caddy 用戶該逐台檢查實際建立的 listener，但不能因此把每個 Caddy instance 都算成符合利用條件。

Hutchins 寫「believed to require MPTCP」，意思是當時認為需要 MPTCP；Red Hat RHSB則說預設關閉 MPTCP 的 RHEL 仍受影響。兩者須放回不同層次閱讀：前者對應已展示的利用條件，後者談漏洞本體，本文不據此裁定誰對，也不將展示條件當成完整受影響範圍。

同一份 RHSB 明載，net.mptcp.enabled=0 不影響既有 socket，原先啟用 MPTCP 的服務要重啟，系統仍須修補。ss 手冊中的 ss -Mlnp 只列目前 network namespace 的 MPTCP listener 與可取得的程序資訊，不能證明外網可達、核心未修補或利用成功，空表也不能證明安全，還須確認工具與核心支援診斷功能。其中 -M 選 MPTCP、-l 選監聽狀態，-n 不解析名稱、-p 顯示程序，其他容器的 namespace 不會自動一起列出，不能把單次指令當成整台主機的盤點。

轉述多加了哪些判斷

International Cyber Digest 將掃描簡化成攻擊者活動，HKEPC 貼文再引用它，原文對住宅代理與 VPN 流量的描述是觀察，將來源歸為威脅行為者則帶有推測，沒有確認入侵，這個保留語在轉述時也應留下。關鍵差異有四處：

「210 萬台正在網絡上裸跑中」放在 Ubuntu 敘述裡，改變了掃描對象與數字口徑，原文只支持 MPTCP 可達。
「官方仍未推出正式的安全修補檔案」概括過廣，Ubuntu 26.10 已有正式套件，部分 LTS 則仍在測試管道。
「僅需在 TCP 連線建立的三向交握」即可取得 root，省略了利用條件，Anthropic 的研究展示針對有 MPTCP listener 的主機，不能套用到任一交握。
「極易被黑客組織武器化」缺乏所引來源支持，Hutchins 轉述的難度很高，國家支持的行為者可能有足夠資源，也是他的推測，沒有成功利用的證據。

修補要對到產品流

Red Hat CVE API 已列出 11 月 1 日的主線勘誤，套件省略 epoch 與架構：

套件流	修補套件	勘誤
RHEL 8.10	`kernel-4.18.0-553.182.1.el8_10`	RHSA-2026:93414
RHEL 9.8	`kernel-5.14.0-687.64.1.el9_8`	RHSA-2026:93412
RHEL 10.2	`kernel-6.12.0-211.72.1.el10_2`	RHSA-2026:93413

11 月 4 日的 RHSA-2026:94996 對應 RHEL 8.6 特定延伸支援流與 kernel-4.18.0-372.227.1.el8_6，OpenShift 4／5 RHCOS 仍列受影響，不能概括成全部修完。

Canonical 將 Ubuntu 26.10 的 7.3.0-10.10 列為已修補，Launchpad source 與 generic binary 紀錄確認已進 Updates 與 Security；22.04、24.04、26.04 的對應 linux 修補仍只在 Proposed，預設更新不選入，其他 kernel flavour 要另查。

Ubuntu CVE tracker 此時仍把 26.10 標為處理中，與發布紀錄不一致。source 的發布時間是台北 10 月 29 日 06:19 進 Updates、11 月 2 日 20:22 進 Security，查核應保留這種差異，不能只憑頁面更新日期決定哪個狀態較可靠。

這些正式發布早於前篇台北 11 月 4 日 01:18 的查核截止，屬於漏查，不能只說文章過時。發布紀錄也不代表主機已用新核心啟動，更新並重開機後，仍要用 uname -r 比對廠商版號。

緩解與利用證據的界線

AWS 的 IPv4 options 過濾範例須另存才跨重開機保留，Network Firewall 需 strict order，stateless pass 會跳過規則。容器也要檢查流量實際走過的 namespace，不能只看主機有沒有規則。

同份 AWS 公告對 ALB、CloudFront 與 NLB TLS 不必立即處置的建議，以後端不直接接受不受信任來源的 TCP 為前提，仍建議自管後端在 30 天內更新，有其他公開入口時要另查。

Red Hat 的容器說明指出，node 規則只處理經過 host network namespace 的流量，pod-to-pod 尚無現成緩解，逐 pod 套規則還有建立與重新排程時的空窗。

AWS 公告仍表示沒有利用證據，CISA KEV 本次版本 2026.11.03 共 1,767 筆，未收錄此 CVE，兩者都不能排除其他地方已有利用。Hutchins 提到 DoS PoC，並說當時沒有已知公開 RCE exploit，這是有時點限制的觀察。

公開專案中有作者自述只重現 UAF 的專案，也有檢查封包過濾的工具，本次只讀說明、未執行，不能用專案名稱判定已有完整 RCE，也不能用過濾結果替核心背書。

補充筆記

掃描可達數無法換算成未修補台數。
核心編入支援、sysctl 允許建立與實際 listener 是不同檢查。
停用 MPTCP 要處理既有 socket，仍須更新核心。
修補須對照產品流，並確認執行中的核心。