【資安快訊】2026十一月 Linux 核心 TCP 重大 CVE-2026-98432 漏洞警報！

本文由 耘鼎科技 GERTECH 整理撰寫分享

發布日期：2026/11/05

事件分類：漏洞預警

風險等級：Critical（最高等級）

原始來源：官方 CVE 紀錄 CVE-2026-98432

本文同時整理 Akamai、AWS、MikroTik、CloudLinux、Ubuntu、Red Hat、NetApp 與 iThome 的公開說明。各項資訊以來源頁面當時的更新日期為準，見文末免責聲明。

---

重點整理

• 出了什麼事？ Linux 系統最底層的「核心」在處理網路連線時有一個程式缺陷。攻擊者不需要帳號密碼、也不需要任何人點連結，只要能從網路連到你的伺服器，就有機會讓伺服器當機、洩漏記憶體裡的資料，最壞情況可能被遠端控制。
• 誰要擔心？ 公司裡跑 Linux 的伺服器、雲端主機、容器節點，以及內部用 Linux 打造的路由器、儲存設備。一般 Windows 電腦和 Mac 不在這次範圍內。
• 嚴重程度？ 國際通用評分 CVSS 9.8 分（滿分 10）。目前還沒有發現實際被攻擊的案例，攻擊程式也還沒公開，但這隨時可能改變。
• 要做什麼？ ① 找出所有從外部連得到的 Linux 主機與設備；② 安裝廠商已釋出的核心更新，而且一定要重新開機；③ 還沒有更新可裝的設備，先把管理介面關到只有內部管理網路才連得到。

---

先搞懂幾個名詞

讀後面的內容前，先認識這幾個詞，會好讀很多：

---

事件摘要

CVSS 9.8 分是怎麼來的？

評分向量是 CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H，翻成白話：

---

這個漏洞到底怎麼發生？

用一個比喻說明：

伺服器接到一通新的 TCP 連線請求，請求上附了一張「備註紙」（IPv4 選項）。核心把這張備註紙共用給新建立的連線。

問題在於：如果電腦裡另一顆處理器剛好同時還在讀這張備註紙，而這邊已經先把紙丟掉了，另一邊就會讀到已經被回收的記憶體。

這就是「釋放後使用」。攻擊者能做的，是故意大量送出帶有備註（例如 Record Route、Timestamp）的連線請求，賭那個剛好撞在一起的瞬間。

• 為什麼 IPv6 沒事？ IPv6 是把備註複製一份給新連線，各看各的，不會共用同一張紙。
• 上游怎麼修？ 改成「等其他人都讀完了，才把紙丟掉」。修補由 Eric Dumazet 提交。
• 還有一條類似的路：Akamai 指出，若開啟「TCP 請求遷移」功能（net.ipv4.tcp_migrate_req=1，作用是當某個聆聽中的程式關閉時，把排隊中的連線請求轉給另一個程式），也有類似的提早丟掉問題。

要碰得到這個漏洞，攻擊者需要同時滿足：

1. 能把 IPv4 TCP 封包送到你的主機；
2. 你的主機核心是 4.4 以後且尚未修補；
3. 主機上有程式正在聆聽 TCP（例如網站、SSH）。

這件事靠「時機剛好」。一次沒撞上，通常只是那次連線沒建立起來，攻擊者可以再試。

---

可能造成什麼影響

1. 伺服器當機、服務中斷：Red Hat、AWS、MikroTik 都把系統不穩或自動重開列為可能後果。對網站、郵件、VPN、儲存管理介面來說，就是停擺。MikroTik 說多數情況下不明顯，最壞是路由器不穩或重開。
2. 記憶體資料外洩或被破壞：AWS 與 Red Hat 列為直接後果。這是漏洞「做得到」的事，不代表已經有人受害。
3. 特定條件下被遠端控制：目前只是「有研究者這樣宣稱，部分廠商公告轉述」。
   • Anthropic 的說法限定在有 MPTCP 聆聽的主機。
   • Go 安全團隊於 2026/10/29 補充：缺陷本身並不專屬於 MPTCP，沒開 MPTCP 的系統仍可能遭受類似攻擊。
   • CloudLinux 表示無法重現遠端取得 root。
   • 攻擊程式尚未公開。
4. 單純「路過」的流量不會觸發：MikroTik 說明，只有「打到路由器自己提供的 TCP 服務」才會觸發；只是被路由器轉送出去的流量不會。同理，打到儲存設備的管理埠，跟打到它後面的主機，是兩回事，要分開評估。

以上為潛在風險分析，並非已確認之攻擊結果。

---

風險評估：到底多危險？

兩種看法同時成立：

• Red Hat：要穩定做到執行任意程式，仍需要精準控制記憶體配置。但他們仍評為 Critical，因為不需要特殊前提，而且核心可能立刻當掉。
• CloudLinux：每次都要碰上時間點，並不容易。

所以結論是：它不是「送一個封包就穩拿 root」，但也絕不是「不好打，可以排到下一季」。 攻擊者失敗的代價很小，可以一直重試；而且攻擊程式現在沒公開，不代表下週也不會公開。

誰最該優先處理？

同時符合這三點的主機排第一：

• ✅ 核心尚未修補
• ✅ 有 IPv4 TCP 埠從網際網路或不受信任的網路連得到
• ✅ 有 MPTCP 聆聽

⚠️ 特別注意 Go 語言寫的服務：從 Go 1.24 起，Go 程式在 Linux 上的聆聽預設自動啟用 MPTCP。就算沒有人在設定檔裡寫過 MPTCP，你的機器也可能有 MPTCP 聆聽。

四種常見環境怎麼看

---

目前仍待確認的四件事

1. 遠端控制在一般環境能否穩定重現？ Anthropic 於 2026/10/27 表示，其研究做出的攻擊程式可在有 MPTCP 聆聽的主機上遠端取得 root，AWS 公告採同樣描述；CloudLinux 則表示無法重現，且對方未寫出測試用的核心版本與設定。 👉 這只影響「MPTCP 主機要不要排更前面」，不影響「沒開 MPTCP 能不能不修」——缺陷在一般 IPv4 TCP 裡，兩類主機都要修。

2. Ubuntu 正式安全更新什麼時候出？ 2026/11/02 Ubuntu 說明：26.10 已在 7.3.0-10.10 修好；22.04、24.04、26.04 的修補還在 proposed 測試區（不是預設會收到的更新管道）；16.04、18.04、20.04 尚未釋出。AWS 更新到美西時間 11/04 時，Cloud9、GameLift Streams、PCS 的 Ubuntu 映像仍寫「Canonical 尚未釋出修復核心」。部署前請以 Ubuntu CVE 頁 最新狀態為準。還沒有正式套件的系統，先縮小對外開放範圍。

3. NetApp 各產品的修補版本？ 公告 NTAP-20261102-0001 版本 4.0（2026/11/03 更新）仍是 Interim（暫行）。iThome 11/04 報導時尚未列出修補版本。現在能做的是限制管理介面，升級要等 NetApp 下一版公告。

4. 有沒有人已經在實際攻擊？

   • AWS（最後更新：美西時間 2026/11/04 15:25 ＝ 台灣時間 2026/11/05 07:25）：沒有被利用的證據。
   • CloudLinux（2026/11/03 11:44 UTC ＝ 台灣時間 11/03 19:44）：尚無在野利用報告。
   • Akamai（2026/11/02）：就其所知沒有公開可用的攻擊程式。
   • NetApp：只說已注意到公開討論。公開討論本身不等於有入侵事件。

重要提醒： 以上資訊還在變動，但有三件事不需要等：盤點對外的 IPv4 TCP 服務、安裝已釋出的核心並安排重開機、把設備管理介面收回到可信任的管理網路。

---

各家廠商修補進度

上游 Linux 核心

已修補版本：Linux 7.3，以及穩定版 5.10.272、5.15.223、6.1.190、6.6.159、6.12.113、6.18.56、7.2.10（Akamai，2026/11/02）。

• NetApp 另寫 7.3-rc6（測試版）仍受影響，這與「正式版 7.3 已修」不衝突。
• 已停止維護的版本線，只要是 4.4 以後、又沒有人把修補移植過去，同樣受影響。

⚠️ 很重要：上面這些號碼只適用自己編譯核心的人。 Ubuntu、Red Hat、Amazon Linux 等發行版會把修補「移植」到自己的核心版本號裡，號碼長得完全不一樣（例如 Amazon Linux 修補的是 kernel-4.14、kernel-5.4 這些上表沒有的版本線）。判斷有沒有修，請看「該發行版公告列的套件版本」，再確認重開機後 uname -r 顯示的就是那個版本。

各發行版與設備

為什麼各家速度差這麼多？ 每家都要把修補移植到自己的核心，再跑完自己的測試。Ubuntu 先把 proposed 開放給有能力自己驗收核心的單位，正式更新要等測試結束；CloudLinux 的 7h、8、LTS 採分批推出，一般的更新指令要等推送到那台機器才裝得到。

AWS 雲端服務

AWS 安全公告 2026-160 最後更新：美西時間 2026/11/04 15:25（台灣時間 2026/11/05 07:25）。

判斷原則只有一個：外部的 TCP 連線會不會直接打到那台機器的核心。 AWS 能幫你換的是它託管的那一層；你自己的主機、節點、機群，還是要自己更新。

---

自己檢查：我的機器有沒有問題？

以下指令能回答兩件事：① 現在跑的核心版本是多少；② 有沒有 MPTCP 在聆聽。 注意：這些指令不能判斷是否已經被入侵，目前也沒有公開的入侵跡象可以比對。

Linux

uname -r                       # 目前「正在運作」的核心版本
sysctl net.mptcp.enabled       # MPTCP 有沒有開
sysctl net.ipv4.tcp_migrate_req  # TCP 請求遷移有沒有開
ss -M -l -n -p                 # 列出所有 MPTCP 聆聽中的服務

看結果怎麼判斷：

⚠️ 不要拿上游版號（如 5.15.223、6.1.190）去比 Ubuntu 或 Red Hat 的套件版號，兩者不是同一套編號。

Ubuntu 可以列出已安裝的核心套件，對照 2026/11/02 公告的版本（proposed 版號之後可能再往上，請重看 Ubuntu CVE 頁）：

dpkg -l 'linux-image*' | grep ^ii

CloudLinux（使用 KernelCare 熱修補） 確認這次 CVE 有沒有包含在 live patch 裡，有的話會印出 CVE-2026-98432：

kcarectl --patch-info | grep CVE-2026-98432

不要用 kcarectl --info 判斷，它只顯示補丁等級、不列 CVE 編號，會讓已修好的機器看起來像沒修。

macOS、Windows

不適用。macOS 和 Windows 的核心都不是 Linux 核心，不在這次影響範圍。請到 Linux 主機、雲端執行個體或設備上檢查。

MikroTik RouterOS

查看目前 RouterOS 版本，對照所在的更新通道：

低於上表版本就是還沒修。同時確認：管理用的 TCP 服務沒有開給不可信網路、預設防火牆還在。

---

處置建議

第一階段（P0）：先處理暴露在外網的系統

1. 列清單。 把所有能從網際網路、合作夥伴網路或訪客網路連到的 IPv4 TCP 服務列出來，包括 SSH、網站、郵件、VPN、資料庫、儲存設備與網路設備的管理埠。每一項註明：發行版、核心版本、有沒有 MPTCP 聆聽。有 MPTCP 的排第一，其他對外主機緊接在後。

2. 有正式修補的，安裝並重開機。

Amazon Linux 2：

sudo yum update kernel && sudo reboot

Amazon Linux 2023——只執行跟你目前核心版本相符的那一行，不要三行一起貼。 有鎖定發行版本的，先確認版本為 2023.12.20261102 或更新：

# 核心 6.1
sudo dnf update kernel --releasever=latest && sudo reboot

# 核心 6.12
sudo dnf update kernel6.12 --releasever=latest && sudo reboot

# 核心 6.18
sudo dnf update kernel6.18 --releasever=latest && sudo reboot

CloudLinux 9 與 10：

dnf update 'kernel*'
reboot

重開後 uname -r 應為：9 → 5.14.0-687.64.1 或更新；10 → 6.12.0-211.73.1 或更新。

CloudLinux 7h 與 8，若要立刻安裝還在分批推出的核心：

yum update cloudlinux-release
yum update kernel --enablerepo=cloudlinux-rollout-3-bypass
reboot

重開後版號應以 4.18.0-553.180.1.lve.1 開頭。

有訂閱 KernelCare 的 CloudLinux 7h、8、9、10，可以先套熱修補，不用重開機：

kcarectl --update

套完一樣要用上面的 --patch-info 確認看得到 CVE 編號。8 LTS、9 LTS 和 CloudLinux for Ubuntu 22.04 沒有這次的熱修補。

3. Ubuntu。

• 26.10：更新到 7.3.0-10.10（或 Ubuntu 頁面上更新的版本）並重開機。
• 22.04、24.04、26.04：修補在 11/02 仍在 proposed 測試區，只建議給有能力自己做核心驗收測試的環境。一般正式環境請等正式安全更新，同時把這批主機標記為「尚未修補」。
• 16.04、18.04、20.04：修補尚未釋出，先做第三階段的縮小曝露。

4. MikroTik RouterOS 7 升級到上面列的修補版本。升級前先確認：管理服務只允許可信任的位址連入、保留預設防火牆、遠端管理改走 WireGuard 這類 VPN。

5. NetApp 設備 在修補版出來前，BMC 與 Service Processor 只允許可信任的管理網路連線。資料庫埠比照 AWS 對 RDS、Aurora、Neptune 的要求，不要對網際網路開放。

6. 如果你是因為主機反覆當機、出現看不懂的核心錯誤才查到這個 CVE： 先保存 dmesg、核心錯誤紀錄與開機紀錄，再把主機隔離。不要直接清日誌或重灌，否則事後無法判斷是漏洞被觸發還是其他故障。光是更新核心，也無法證明之前沒人進來過。

第二階段（P1）：換掉會把舊核心「再帶回來」的範本

修好現在這台還不夠——自動擴展、重建機器時用的映像檔（範本）沒換，新開的機器又是舊核心。

1. EKS 節點更新到 AMI v20261031 或更新，用 kubectl get node -o wide 的 OS-IMAGE 欄位核對。ECS on EC2 改用 20261031 最佳化 AMI，或在現有主機更新核心後重開。Elastic Beanstalk 換到 2026/11/04 的 AL2023 平台。GameLift 舊機群要新建並移走流量，不能就地改。
2. Bottlerocket 使用 v1.68.1 或更新。Storage Gateway 建議立即手動更新。Amazon MQ 想提早就把維護時段往前移，只重啟 broker 沒用。
3. DMS 若 describe-pending-maintenance-actions 已列出 os-patch，可選擇立即套用；立即套用會馬上重開，執行中的任務會中斷後恢復。
4. WorkSpaces、Cloud9 核心裝完後要重新啟動環境。有開 AutoStop、停用維護或擋掉更新來源的 WorkSpaces，要另外確認更新真的有裝上。
5. Go 1.24 以後撰寫、在 Linux 上聆聽的服務，在核心修好前都視為有 MPTCP 風險。Go 團隊的暫時做法：在環境變數設 GODEBUG=multipathtcp=0，或在主模組的 go.mod 加入 godebug multipathtcp=0。但如果程式碼自己呼叫了 SetMultipathTCP，會蓋掉這兩個設定。Go 團隊也提醒：逐個程式關閉很容易漏，漏一個就還有風險，而且這招假設所有攻擊都要靠 MPTCP。

第三階段（P2）：還沒有更新可裝時——暫時措施 ≠ 已修好

Red Hat、Ubuntu 都認為正解是安裝核心更新。大家建議關 MPTCP，只是因為那份未公開的攻擊程式據稱用到 MPTCP。AWS 與 Akamai 雖提供暫時做法，也都寫明不能取代核心更新。

以下三項可以先做，但請在清單上仍登記為「未修補」：

1. 縮小誰連得到你的 TCP 埠。 用安全群組、主機防火牆、管理網路限制來源。這招跟漏洞細節無關，最穩。

2. 關閉 MPTCP 與 TCP 請求遷移（Akamai 的做法）。只降低目前被描述的攻擊條件，一般 TCP 的缺陷仍在：

sudo sysctl -w net.mptcp.enabled=0
sudo sysctl -w net.ipv4.tcp_migrate_req=0

讓設定在重開機後仍有效：

sudo tee /etc/sysctl.d/99-cve-2026-98432.conf <<'EOF'
net.mptcp.enabled = 0
net.ipv4.tcp_migrate_req = 0
EOF
sudo sysctl --system
sudo sysctl net.mptcp.enabled net.ipv4.tcp_migrate_req

3. 用防火牆丟掉「帶備註」的封包（AWS 提供）。

iptables -I INPUT 1 -m u32 --u32 '0>>24&0x0f=6:15' -j DROP

這條規則的意思是：讀取 IPv4 封包標頭的「長度欄位」，正常無選項的標頭是 20 位元組（欄位值 5）；值落在 6–15，代表封包有附帶 IPv4 選項，就直接丟掉。

注意事項：

• 會影響真的需要 IP options 的應用（極少見，但要確認）。
• 預設的 Amazon Linux 2023 沒有安裝 iptables。
• 規則沒另外存檔的話，重開機就消失。
• 使用 AWS Network Firewall 的客戶，可在「嚴格規則順序」政策中，加一條優先於允許規則的有狀態規則，丟掉 IPv4 標頭長度大於 20 位元組的封包。若無狀態規則已經把流量直接放行，這條規則看不到那些流量。把政策從預設順序改成嚴格順序會改變所有規則的比對方式、可能中斷既有連線，務必先在測試環境驗證。

自行編譯核心的人：確定版本落在上游受影響範圍時，升級到對應的修補版本並重開機。用發行版的機器不要拿上游版號自己判斷已修好。

---

耘鼎觀點

這次真正拉開企業差距的，不是 9.8 分，而是同一顆 Linux 核心藏在多少個「要等別人更新」的地方。

虛擬機今晚就能更新，但自動擴展的映像檔、路由器韌體、儲存設備的管理晶片，各有各的發布時程：Amazon Linux 已能更新、Ubuntu 22.04 以後的正式更新 11/02 仍在測試、RouterOS 7 已有修補、NetApp 到 11/03 還沒有修補版本。上游 10/05 就修好了，不代表你機器上跑的核心已經換過。

• 每個對外服務都要對到「核心版本」和「負責人」：至少記下發行版、正在運作的核心版本、誰能核准重開機、新機器來自哪個映像檔。這張表比 CVSS 分數更能決定你這週能做多少。
• 映像檔和自動擴展要一起換：Elastic Beanstalk 換平台前新開的主機、GameLift 的舊機群，都會把舊核心帶回來。只修活著的那台，一擴展就回到原點。
• 暫時措施不能記成「已修復」：關 MPTCP、收管理埠、擋 IP options，都只是在等更新或等維護時段。記成已修復，下一次盤點就會漏掉還沒重開機的主機。
• 沒有更新可裝的設備，先改網路邊界：Ubuntu 16.04–20.04、CloudLinux for Ubuntu 22.04、NetApp 受影響機型，短期內可能都沒有版本可裝。把 BMC、Service Processor、路由器管理埠只留在可信任的管理網路，風險就從「網路上任何人」縮小成「已經進得了管理網路的人」。

如果盤點對不到負責人，或雲端帳號與機房設備要一起排程，耘鼎科技 GERTECH 可以協助弱點與曝險評估、外部攻擊面清查。上面的清單即使沒有導入服務，也可以自己動手做。

---

接下來要持續關注

1. Ubuntu 正式安全更新，以及 16.04、18.04、20.04 的修補。proposed 的版號可能還會變；正式版釋出後，沒有自行驗收能力的環境才適合大量部署。
2. NetApp 公告下一版：目前仍是 Interim，修補版本出來後再排儲存設備升級時段。
3. RDS 與 Aurora 的作業系統修補：AWS 預計 2026/11/06 提供，提供後仍要套用到資料庫主機，並持續確認資料庫埠沒對外開放。
4. 依賴 Canonical 的產品：CloudLinux for Ubuntu 22.04、GameLift Streams、PCS 的 Ubuntu 深度學習 AMI、Cloud9 Ubuntu 環境，都要等 Ubuntu 正式更新。
5. 攻擊程式與實際利用的說法有沒有變：目前是「攻擊程式未公開、原廠無被利用證據」。若核心 CVE 機構、AWS 或發行版改口，就要從「單純修補」升級為「修補 + 入侵追查」。
6. Go 是否調整 MPTCP 預設：Go 安全團隊 2026/10/29 表示現在改語言預設還太早，討論在 golang/go#82717。在那之前，Go 服務的風險以核心有沒有修為準。

---

參考資料

• Linux 核心 CVE 公告｜CVE-2026-98432（核心公告，連結引自 NetApp 公告的參考文獻）
• Akamai Security Intelligence Group｜CVE-2026-98432: A Remote Use-After-Free in the Linux Kernel's TCP Stack（研究分析，2026/11/02）
• AWS Security Bulletin｜2026-160-AWS：CVE-2026-98432（雲端廠商公告，最後更新美西時間 2026/11/04 15:25）
• MikroTik｜CVE-2026-98432（設備原廠公告，2026/11/03）
• CloudLinux｜CVE-2026-98432 Linux kernel IPv4 TCP flaw: status for CloudLinux（發行版狀態，重點摘要更新至 2026/11/03 11:44 UTC）
• Ubuntu｜Fixes available in -proposed pocket for CVE-2026-98432（發行版說明，2026/11/02）
• Red Hat｜CVE-2026-98432（發行版評分與弱點說明）
• NetApp Product Security｜NTAP-20261102-0001（設備原廠公告，版本 4.0，2026/11/03）
• iThome｜NetApp 揭露旗下多款儲存產品受 Linux 核心 TCP 漏洞影響（媒體報導，2026/11/04）
• Go 安全團隊｜Protecting against CVE-2026-98432（語言團隊說明，2026/10/29）
• Anthropic｜Discovering vulnerabilities with Claude（漏洞回報者自述，遠端 root 的說法出自這份公開說明）

延伸閱讀

• 駭客利用 CVE-2026-58115 接管 Node-RED 事件解析（2026-11-04）
• 2026 10月 PHP CVE 重大漏洞 RCE 漏洞復現研究報告 CVE-2026-109618、CVE-2026-109619（2026-10-22）

---

本文依據 Linux 核心 CVE 公告、Akamai 2026/11/02 研究文章、AWS 安全公告 2026-160、MikroTik 2026/11/03 說明、CloudLinux 2026/11/03 狀態、Ubuntu 2026/11/02 說明、Red Hat CVE 頁、NetApp 公告 NTAP-20261102-0001，以及 iThome 2026/11/04 報導整理。技術細節與修補資訊以原廠最新公告為準。

© Gertech 耘鼎科技 資安情資分享

想進一步討論這個主題？

歡迎來電 02-2748-8522，或填寫諮詢表單，由耘鼎顧問與您聯繫。

預約諮詢 →