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

> CVE-2026-98432 的 210 萬是 MPTCP 可達數，無法證明全是未修補的 Ubuntu。本文對照研究者原文、RHEL 勘誤與 Ubuntu 發布紀錄，釐清掃描數字、修補管道及緩解限制。

原文：https://sheng.page/posts/cve-2026-98432-scan-counts-and-patch-streams/ · 發布：2026-11-05 · 作者：Sheng

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

## 210 萬量到什麼

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

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

## MPTCP 要開在哪裡

[MPTCP 專案文件](https://www.mptcp.dev/setup.html)在 kernel build configuration 段將 Debian、Ubuntu、Red Hat、Fedora 列為通常已編入支援的發行版，[CentOS Stream 9](https://gitlab.com/redhat/centos-stream/src/kernel/centos-stream-9/-/raw/main/redhat/configs/common/generic/CONFIG_MPTCP) 與 [10 的設定](https://gitlab.com/redhat/centos-stream/src/kernel/centos-stream-10/-/raw/main/redhat/configs/common/generic/CONFIG_MPTCP)也明列 `CONFIG_MPTCP=y`，但這只回答核心有沒有這項功能。

[上游 sysctl 文件](https://www.kernel.org/doc/html/latest/networking/mptcp-sysctl.html)寫 `net.mptcp.enabled` 預設為 1，控制各 network namespace 能否建立 MPTCP socket；[RHEL 文件](https://docs.redhat.com/en/documentation/red_hat_enterprise_linux/9/html/configuring_and_managing_networking/getting-started-with-multipath-tcp_configuring-and-managing-networking)卻明載產品預設關閉。Debian 是否另用 sysctl 覆寫預設，查核時找不到可讀的套件來源，因此 Hutchins 所說 Debian 預設啟用，目前只能確認編入支援這一層，不能把上游預設當成發行版實測結果。Ubuntu、Fedora 的現行 sysctl 預設也未逐一核實，SUSE、Amazon Linux 與 Alpine 則沒有足夠的一手組態證據可在此列出。管理者仍應查自己使用的核心套件與 namespace，發行版名稱不足以代替主機設定。

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

[Go 1.24 release notes](https://go.dev/doc/go1.24)說，Linux 支援且允許 MPTCP 時，`ListenConfig` 預設使用它。[GODEBUG 文件](https://go.dev/doc/godebug)將預設值列為 `multipathtcp=2`，只開 listener，dialer 不在其中；`GODEBUG=multipathtcp=0` 可關掉預設，主模組宣告的舊 Go 版本也可能沿用舊行為。[Go 團隊](https://www.openwall.com/lists/oss-security/2026/10/30/1)另說 `net.ListenConfig.SetMultipathTCP` 與 `net.Dialer.SetMultipathTCP` 能逐 socket 覆寫，不能概括成所有 Go 程式都會開啟。

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

[Caddy v2.11.7](https://raw.githubusercontent.com/caddyserver/caddy/v2.11.7/go.mod) 宣告 `go 1.26.0`，[關閉預設的 PR](https://github.com/caddyserver/caddy/pull/8335)未合併，維護者在 [issue](https://github.com/caddyserver/caddy/issues/8334)建議由系統管理者處理。所以 Caddy 用戶該逐台檢查實際建立的 listener，但不能因此把每個 Caddy instance 都算成符合利用條件。

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

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

## 轉述多加了哪些判斷

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

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

## 修補要對到產品流

[Red Hat CVE API](https://access.redhat.com/hydra/rest/securitydata/cve/CVE-2026-98432.json) 已列出 11 月 1 日的主線勘誤，套件省略 epoch 與架構：

| 套件流 | 修補套件 | 勘誤 |
| --- | --- | --- |
| RHEL 8.10 | `kernel-4.18.0-553.182.1.el8_10` | [RHSA-2026:93414](https://access.redhat.com/errata/RHSA-2026:93414) |
| RHEL 9.8 | `kernel-5.14.0-687.64.1.el9_8` | [RHSA-2026:93412](https://access.redhat.com/errata/RHSA-2026:93412) |
| RHEL 10.2 | `kernel-6.12.0-211.72.1.el10_2` | [RHSA-2026:93413](https://access.redhat.com/errata/RHSA-2026:93413) |

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

[Canonical](https://ubuntu.com/blog/fixes-available-in-proposed-pocket-for-cve-2026-98432) 將 Ubuntu 26.10 的 `7.3.0-10.10` 列為已修補，[Launchpad source](https://api.launchpad.net/1.0/ubuntu/+archive/primary?ws.op=getPublishedSources&source_name=linux&exact_match=true&version=7.3.0-10.10) 與 [generic binary 紀錄](https://api.launchpad.net/1.0/ubuntu/+archive/primary?ws.op=getPublishedBinaries&binary_name=linux-image-7.3.0-10-generic&exact_match=true&version=7.3.0-10.10&ws.size=300)確認已進 Updates 與 Security；22.04、24.04、26.04 的對應 `linux` 修補仍只在 Proposed，預設更新不選入，其他 kernel flavour 要另查。

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

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

## 緩解與利用證據的界線

[AWS](https://aws.amazon.com/security/security-bulletins/2026-160-aws/) 的 IPv4 options 過濾範例須另存才跨重開機保留，Network Firewall 需 strict order，stateless pass 會跳過規則。容器也要檢查流量實際走過的 namespace，不能只看主機有沒有規則。

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

[Red Hat 的容器說明](https://access.redhat.com/security/vulnerabilities/RHSB-2026-016)指出，node 規則只處理經過 host network namespace 的流量，pod-to-pod 尚無現成緩解，逐 pod 套規則還有建立與重新排程時的空窗。

AWS 公告仍表示沒有利用證據，[CISA KEV](https://www.cisa.gov/sites/default/files/feeds/known_exploited_vulnerabilities.json) 本次版本 `2026.11.03` 共 1,767 筆，未收錄此 CVE，兩者都不能排除其他地方已有利用。Hutchins 提到 DoS PoC，並說當時沒有已知公開 RCE exploit，這是有時點限制的觀察。

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

## 補充筆記

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

## 延伸閱讀

- [Hutchins 的 X 原文](https://x.com/MalwareTechBlog/status/2117508092321747077)與 [Mastodon 同文](https://infosec.exchange/@malwaretech/117551155941056123)保留完整限定語。
- [Go 安全團隊說明](https://www.openwall.com/lists/oss-security/2026/10/30/1)區分已展示的利用與漏洞本體。
- [Red Hat RHSB](https://access.redhat.com/security/vulnerabilities/RHSB-2026-016)說明 socket 生效範圍及容器過濾限制。
- [Red Hat CVE API](https://access.redhat.com/hydra/rest/securitydata/cve/CVE-2026-98432.json)是官方的勘誤與產品狀態資料，比概述頁更早列出修補版號。
- [Launchpad 發布紀錄](https://api.launchpad.net/1.0/ubuntu/+archive/primary?ws.op=getPublishedSources&source_name=linux&exact_match=true&version=7.3.0-10.10)是 Ubuntu archive 的套件發布證據，可對照 CVE tracker 的標籤。
- [AWS 公告](https://aws.amazon.com/security/security-bulletins/2026-160-aws/)說明各服務的處置責任與緩解限制。
- [CISA KEV JSON](https://www.cisa.gov/sites/default/files/feeds/known_exploited_vulnerabilities.json)是官方目錄快照，引用時要連同版本號。
- 〈[Linux TCP 漏洞 CVE-2026-98432：AWS 與 Ubuntu 公告說了什麼？](/posts/linux-cve-2026-98432-what-to-check/)〉是本站前篇，修補狀態表已更正。

> 想法與技術判斷出自 Sheng，和 Claude 一起起草 · 題目由 Sheng 選定，事實查核 Grok（grok-4.7）與 Codex（gpt-6-astra），決策與大綱 Claude Fable，內文與二審 Codex（gpt-6-astra）；資料查核至 2026-11-05 02:59（台北時間）。