Linux TCP 漏洞 CVE-2026-98432 評 9.8 分：RHEL 已修補、Ubuntu 仍在測試，企業主機先查這 5 件事

文／Laban（優創智能 AI 導入工程師）

CVE-2026-98432 是 Linux 核心處理 IPv4 TCP 連線時的釋放後使用（use-after-free）漏洞，CVSS 評分 9.8，遠端、免驗證即可觸發，可能導致遠端執行程式碼。結論先講：只要 Linux 主機有任何對外開放的 TCP 埠就在影響範圍內，而且沒有可以靠調整設定擋住的方法，只能更新核心並重新開機。RHEL 8、9、10 已經能更新；Ubuntu LTS 的修補還在測試通道，這是這次最需要盯的地方。

本文寫給公司有 Linux 伺服器、VPS 或雲端主機的 IT 承辦人，以及想知道「這跟我有沒有關係」的老闆。本文整理各發行版的修補狀態、誰要先處理，以及 5 步驟自查。事件仍在發展中，以下事實截至 2026 年 11 月 9 日。

一、已知事實：漏洞是什麼、哪些版本已修補？

1. 漏洞成因

依 Ubuntu CVE 頁面（2026-11-07 更新）的說明：伺服器接受外部 IPv4 TCP 連線時，核心會把連線請求裡的 IP 選項直接交給新建立的 socket，沒有另外複製一份。如果用戶端在這段時間重送連線請求，另一個 CPU 可能還在讀取這份選項，而它已經被釋放，就形成釋放後使用。

報導指出，攻擊者可以對任何 TCP 埠送出帶有 IPv4 Record Route 或時間戳選項的封包來引發這個競態條件。主要攻擊路徑只影響 IPv4，不影響 IPv6。

2. 各發行版修補狀態

以下整理自 Ubuntu CVE 頁面（2026-11-09 查詢）與 netmag（2026-11-09，轉述 The Hacker News）的報導：

另外，依報導 Ubuntu 的 Cloud、FIPS 與即時核心（realtime）版本更新仍在開發中。

3. 分數與攻擊狀況

• 評分有變動：依報導，Red Hat 原本列為 5.9 分，之後上調到 9.8；Ubuntu 列為 Critical、CVSS 9.8；Amazon Linux 評 8.1，認為被濫用的後果是記憶體毀損導致系統崩潰。各家評分不同，以你所用發行版的公告為準。
• 沒有公開的攻擊通報：截至 2026 年 11 月 9 日，CISA 的已知被濫用漏洞（KEV）目錄（2026-11-06 版）沒有收錄這個 CVE。
• 但攻擊門檻正在下降：依報導，Anthropic 於 2026-10-27 表示，一個未發布的內部研究模型寫出了攻擊程式，鎖定啟用 MPTCP 監聽埠的 Linux 伺服器，概念驗證中 48 分鐘洩漏核心位址、再 5 分鐘取得 root，程式碼未公開。GitHub 上也已有能觸發競態條件的驗證程式，但沒有實作程式碼執行。

二、這次和上次 Linux 核心漏洞有什麼不同？

10 月的 ZDI 誤發 Linux 核心漏洞報告事件，難處是「細節公開、修補還沒出」，而且 9.0 分的漏洞只影響有啟用 ksmbd 的機器，多數主機可以先排除。

這次剛好相反：修補已經有了，但影響範圍幾乎是所有對外服務的 Linux 主機，而且不同發行版的修補進度差很多。用 RHEL、Debian、SUSE 的，今天就能更新；用 Ubuntu LTS 的，要等正式通道推出，中間這段空窗只能靠縮小暴露面撐著。

停用 MPTCP 不是解法

依報導，部分來源建議沒辦法立即更新的管理員停用 Multipath TCP（MPTCP）。Canonical 的說明是：漏洞在 IPv4 TCP 路徑，不在 MPTCP，安裝安全更新是唯一適當的解決方案。Anthropic 的攻擊程式鎖定 MPTCP 監聽埠，是它選擇的攻擊路徑，不代表關掉 MPTCP 就安全。我們不建議把停用 MPTCP 寫進處理紀錄當成「已緩解」。

三、誰要先處理？

判斷方法只要問一個問題：「這台 Linux 主機，網際網路上的人連得到它的哪個 TCP 埠？」 有任何一個，就要排進更新。

四、5 步驟自查與更新

步驟 1：盤點 Linux 主機與對外開放的埠

列出公司所有 Linux 伺服器、VPS 與雲端主機，記下發行版與版本（cat /etc/os-release）、核心版本（uname -r），以及對外開放的 TCP 埠（ss -tlnp，再對照雲端安全群組或防火牆規則）。

步驟 2：依發行版確認是否有修補可裝

對照第一節的表格。RHEL 查是否已套用對應的 RHSA；Debian、SUSE、Oracle Linux、Amazon Linux 查各自的安全公告；Ubuntu 看 CVE 頁面 的狀態欄，從「Vulnerable」變成「Fixed」才代表正式通道有更新。

步驟 3：安裝核心更新並重新開機

核心更新要重新開機才會生效，只裝套件不重開等於沒修。排好維護時段，先更新對外服務的主機；重開後再跑一次 uname -r，確認核心版本已經是修補後的版本。使用 Livepatch、KernelCare 等即時修補服務的，確認服務商是否已涵蓋這個 CVE。

步驟 4：修補前先縮小暴露面

還不能更新的主機（例如 Ubuntu LTS 正式通道尚未推出），先把不必要對外的埠關掉：SSH 只允許公司 IP 或改走 VPN、資料庫不對外、管理介面放到內網。這不能修好漏洞，但能減少能連到主機的人。這是爭取時間，不是緩解完成，紀錄上要寫清楚。

步驟 5：問代管服務商兩個問題

網站或系統放在代管主機、VPS 平台、雲端服務的，請服務商回覆：一、是否已套用 CVE-2026-98432 的核心更新；二、何時重新開機或已經重開。共用主機與容器平台的核心是多個客戶共用的，這兩個問題值得主動問，而不是等公告。

五、給老闆的判斷：這次要不要找人處理？

不需要懂核心，只要回答三個問題：

1. 公司有幾台 Linux 主機對外提供服務，各由誰負責？ 答不出來，先做盤點。
2. 哪幾台用的是 Ubuntu LTS？ 這幾台要有人每天追蹤正式更新。
3. 更新後誰負責在一週內重新開機並確認版本？ 沒有指定的人，就是下一次事件的破口。

我們在處理 BIND DNS 漏洞 與 PHP2Shell 網站漏洞 時看到的狀況一樣：修補本身不難，難的是沒人知道主機在哪、誰該按下重開機。

如果你不確定公司有哪些 Linux 主機對外開放，或外包商、代管服務商是否已經更新，歡迎填寫諮詢表單。請留下主機用途與目前的維護單位，我們會先協助盤點主機與負責人，再建議要立即更新、先縮小暴露面，還是改用代管服務。

驗收標準：讀完本文後，你應該能回答三個問題——公司有哪些 Linux 主機對外開放 TCP 埠、每台的發行版是否已有正式修補、更新並重開機的負責人與完成日期。三題都有答案，這次事件的處理就有了著落。

免責說明：本文依據 Ubuntu CVE 頁面（2026-11-07 更新）、Red Hat 安全公告、CISA KEV 目錄（2026-11-06 版）與 netmag（2026-11-09，轉述 The Hacker News）的報導整理，資料截至 2026 年 11 月 9 日。CVSS 分數與修補狀態以各發行版官方公告為準。文中步驟為一般性建議，執行前請依自身環境評估。

參考來源

• Ubuntu，〈CVE-2026-98432〉，2026-11-07 更新：https://ubuntu.com/security/CVE-2026-98432
• Red Hat，〈RHSA-2026:93412〉（RHEL 9），2026-11-01：https://access.redhat.com/errata/RHSA-2026:93412
• CISA，〈Known Exploited Vulnerabilities Catalog〉，2026-11-06 版：https://www.cisa.gov/known-exploited-vulnerabilities-catalog
• 吳明宜，〈Linux核心TCP漏洞風險值達9.8　Red Hat已釋出RHEL 8到10修補〉，網路資訊雜誌（netmag），2026-11-09：https://netmag.tw/2026/11/09/rhel-patches-9-8-linux-tcp-flaw
• The Hacker News，2026-11（netmag 所列原始來源，本文未能直接讀取）：https://thehackernews.com/2026/11/red-hat-patches-98-rated-linux-tcp-rce.html

相關推薦與延伸閱讀

• Linux 核心漏洞被提早公開怎麼辦？ZDI 誤發 5 份未修補報告，先查 ksmbd 與提權漏洞：2026 年 10 月 21 日，趨勢科技 ZDI 把 5 份未修補的 Linux 核心漏洞報告寄到公開郵件清單，其中 2 個 ksmbd 漏洞 CVSS 9.
• BIND 漏洞 CVE-2026-94300 自查與修補：DNS 伺服器要升到 9.20.30，9.18 沒有修補版：CVE-2026-94300 是 ISC 於 2026 年 10 月 21 日公開的 BIND 9 高風險漏洞，CVSS 8.1，重放 GSS-TSIG 簽章訊
• PHP2Shell 漏洞自查與修補：中小企業官網今天就要做的 5 件事：PHP2Shell 是 PHP 官方 2026 年 10 月 21 日修補的兩個核心漏洞，不用登入就可能被遠端接管伺服器。官網用 WordPress 或虛擬主機