Linux 核心的漏洞很多，但能從網路遠端直接打進來、又不需要任何帳號的並不常見，這次的 CVE-2026-98432 就是這一類。
這個漏洞藏在 Linux 核心處理 IPv4 TCP 連線建立的程式碼裡，從 4.4 版就存在。Red Hat 評為 CVSS 9.8、嚴重等級 Critical；Anthropic 也表示自家尚未公開的 Claude 研究模型，寫出了利用這個漏洞取得 root 權限的攻擊程式。我們來看看這個漏洞的影響範圍、該更新到哪個版本，以及還沒辦法更新時可以先怎麼擋。
漏洞重點整理
| 項目 | 內容 |
|---|---|
| CVE 編號 | CVE-2026-98432 |
| 漏洞類型 | 釋放後使用（Use-After-Free），起因是競爭條件 |
| 影響範圍 | Linux 核心 4.4 起的版本 |
| 嚴重程度 | CVSS 3.1 分數 9.8，Red Hat 評為 Critical |
| 攻擊條件 | 遠端、不需權限、不需使用者互動 |
| 核心社群公告 | 2026 年 10 月 15 日 |
| Red Hat 安全公告 | RHSB-2026-016，10 月 30 日發布 |
漏洞怎麼發生
依 Linux 核心 CVE 公告的說明，問題出在 TCP 三向交握（three-way handshake）處理 IP 選項（IP options）的地方：
- 伺服器收到連線請求後，會把請求裡的 IP 選項資料交給新建立的連線使用，但沒有另外複製一份。
- 如果這時另一顆 CPU 剛好在處理同一個連線請求的重送封包，就會去讀這份資料。
- 兩邊沒有互相等待，資料可能已經被釋放，另一邊卻還在讀，形成釋放後使用。
核心社群的修法，是讓這兩份 IP 選項資料等到 RCU 寬限期（RCU grace period）結束後才釋放，確保沒有人還在讀取。
MPTCP 沒開就安全嗎？
這是這次最容易誤解的地方。
Anthropic 展示的攻擊程式，目標是有開啟多路徑 TCP（Multipath TCP，MPTCP）監聽的伺服器，因此不少報導把「啟用 MPTCP」寫成攻擊條件。
但 Red Hat 在 RHSB-2026-016 公告中明確表示，啟用 MPTCP 並不是這個漏洞的前提；只要收到的連線請求帶有 IPv4 選項，再加上封包重送或 socket 遷移造成的競爭情況，就可能觸發。Red Hat 也特別說明，預設沒有啟用 MPTCP 的 RHEL 一樣受影響。
所以「我的伺服器沒有用 MPTCP」不能當作不用更新的理由。
哪些版本要更新
最直接的做法：用發行版的套件更新核心，再重開機
大多數伺服器用的是發行版（Ubuntu、Debian、RHEL、AlmaLinux 等）提供的核心，最直接的做法就是等發行版推出修補後，用套件管理工具更新核心：
# Debian、Ubuntu
sudo apt update && sudo apt upgrade
# RHEL、AlmaLinux、Rocky Linux
sudo dnf update kernel核心更新後要重新開機，新核心才會生效。只裝好套件、沒有重開機，跑的還是舊核心。
先查自己用的是哪個核心
用這行指令可以看到目前正在執行的核心版本：
uname -r這裡有個容易搞錯的地方：發行版的核心版本號，不能直接拿來和核心社群的版本比大小。
發行版會把修補「回補」到自己維護的舊版本核心上，所以版本號看起來很舊，實際上可能已經修好了。例如 iThome 整理的資料中，AlmaLinux 9 已修補的核心版本是 5.14.0 開頭，數字比核心社群的 6.12 小很多，但已經包含這次的修補。
所以用發行版核心的人，判斷方式是：
- 用
uname -r查出目前的核心版本。 - 到自己發行版的安全公告，找 CVE-2026-98432 對應的修補版本。
- 目前版本等於或高於公告的版本，而且已經重開機，才算修補完成。
以 Red Hat 為例，RHSB-2026-016 公告表示 RHEL 8、9、10，以及使用 RHEL CoreOS 的 OpenShift 4 都受影響，正在加速推出修補；其他發行版（Debian、Ubuntu、SUSE、AlmaLinux、Rocky Linux 等）請到各自的安全追蹤頁面查詢。
自己編譯核心：對照核心社群的修補版本
如果是自己從核心社群下載原始碼編譯，才直接對照 Linux 核心 CVE 公告列出的修補版本。
核心版本號的格式是「主版本.次版本.修正版」，前兩段是分支，最後一段是修正版。查法是先找到自己的分支，修正版等於或高於下表就已修補，低於就要更新。
舉例來說，目前是 6.12.110，分支是 6.12，表格寫 6.12.113，110 小於 113，代表還沒修補。
| 核心分支 | 已修補的最低版本 |
|---|---|
| 6.12 | 6.12.113 |
| 6.18 | 6.18.56 |
| 7.2 | 7.2.10 |
| 7.3 | 7.3-rc7 |
資料來源：Linux 核心 CVE 公告。
表上沒有的舊分支（例如 5.10、5.15、6.1、6.6），核心社群公告說明修補之後可能再回補，最新狀態以 CVE 官方紀錄為準。
NAS 與網通設備
NAS、路由器、防火牆這類設備的系統裡面也是 Linux 核心，但使用者沒辦法自己換核心，只能等原廠推出韌體更新。
iThome 整理了各發行版、NAS、網通設備與雲端服務的修補狀態，台灣常見的群暉、威聯通、兆勤等廠商都在清單內，有使用這些設備的讀者可以到文末連結查看，再以原廠公告為準。
還沒辦法更新：Red Hat 的暫時緩解方式
Red Hat 提供的緩解方式，是用 nftables 規則丟棄帶有 IP 選項的 IPv4 TCP 封包。以下規則取自 Red Hat 公告，存成 cve-2026-98432.nft：
table inet cve_2026_98432 {
chain input {
type filter hook input priority -310; policy accept;
ip protocol tcp ip hdrlength > 5 counter drop
}
}先檢查語法、再套用，最後確認規則有生效：
sudo nft --check --file cve-2026-98432.nft
sudo nft --file cve-2026-98432.nft
sudo nft list table inet cve_2026_98432更新核心後，可以用這行移除規則：
sudo nft delete table inet cve_2026_98432套用前有幾件事要注意，這些都是 Red Hat 在公告中提醒的：
- 這條規則重開機後就會消失，不是永久設定。
- 可能影響需要 IP 選項的正常服務，建議先在測試環境確認。
- 這只是暫時緩解，不能取代更新核心。
關掉 MPTCP 有用嗎？
有些組織建議用 sysctl -w net.mptcp.enabled=0 關閉 MPTCP。Red Hat 的公告提到這種做法，但也說明它不是完整的緩解方式，因為漏洞本身不需要 MPTCP 就能觸發。
公告另外提到可以用 ss -Mlnp 查看系統有沒有 MPTCP 監聽，但這只能當參考，查不到 MPTCP 監聽不代表沒有風險。
Anthropic 說了什麼
依 CSO Online 的報導，Anthropic 表示用尚未公開的 Claude 研究模型，針對有 MPTCP 監聽的 Linux 伺服器寫出了零點擊（zero-click）攻擊程式，從洩漏核心記憶體、繞過 KASLR，到以 root 身分執行指令，大約花了 53 分鐘。
截至撰稿時，我們沒有找到 Anthropic 公開攻擊程式碼的紀錄，也沒有在 Red Hat 公告或 CISA 已知遭利用漏洞清單中看到這個漏洞已被實際利用的說明。
不過，AI 能在這麼短的時間內把漏洞變成可用的攻擊程式，代表從漏洞公開到被利用的時間可能越來越短，更新的速度也要跟著加快。
參考資料與延伸閱讀
- CVE-2026-98432: ipv4: free inet_opt and ireq_opt after an RCU grace period（Linux 核心 CVE 公告）
- RHSB-2026-016 Use-after-free in kernel IPv4（Red Hat）
- CVE-2026-98432（Red Hat CVE 頁面）
- CVE-2026-98432（CVE.org）
- Anthropic AI model finds Linux kernel bug that leads to remote root access（CSO Online）
- Linux核心IPv4 TCP連線漏洞影響廣泛，多家廠商陸續推出修補（iThome）
發佈留言