【実測】CVE-2026-98432、CVSSよりもまず「先に対象かどうか」を確認すべし

こんにちは、もんすんです。

この記事は、Linux のサーバーやラズパイを動かしている個人開発者と、脆弱性のニュースを見て何をすればよいか迷う初学者に向けた記事です。

この記事で分かることは、次の3つです。

• Linux カーネルの脆弱性 CVE-2026-98432 の中身、影響を受ける版、直し方
• 話題の中で出てくる MPTCP が、そもそも何に使う仕組みか
• 自分のマシンが対象かを、読み取りだけで確かめる手順と、私のラズパイでの結果

先に、私の言いたいことを書きます。

最近、CVSS の数字だけを見て騒ぐ投稿が多すぎると感じています。
大事なのは、自分のサービスが対象かをすぐに確かめ、対象なら直すことだけです。
だから記事や X で書くべきなのは、点数の大きさよりも、検知から確認までを速く回す手順だと考えています。

また、このCVEの対象になるのは以下のサーバです。
まず取り急ぎ確認することをお勧めします。
CVE-2026-98432の対象

CVE-2026-98432 の概要

CVE は、公開された脆弱性につける通し番号です。
CVSS は、脆弱性の深刻さを 0 から 10 の数字で表す共通の物差しです。

この脆弱性は、Linux カーネルの IPv4 の TCP の接続開始の処理にあります¹。

接続を始めるときに送られる IP オプションのデータを、別の CPU がまだ読んでいる間に解放してしまう競合があります。
解放済みのメモリを使ってしまう、use-after-free と呼ばれる種類の欠陥です。
IPv6 は、オプションを複製しているため、この部分の影響を受けないと書かれています¹。

2026/10/27 には Anthropic が、この脆弱性を使い、認証なしで root としてコマンドを実行できることを実証したと公表しました²。
root は、システムのすべての権限を持つ管理者です。

出典	内容
CVE の記録、Linux カーネルの採番1	2026/10/15 公開。CVSS 3.1 で 9.8、Critical
Red Hat3	CVSS 3.1 で 8.1、Important。攻撃の難しさを High と評価
Ubuntu4	CVSS 4.0 で 8.3、High。22.04 と 24.04 は影響あり、対応中

同じ CVSS 3.1 でも、評価する組織によって 9.8 と 8.1 に分かれました。

ただし、ここで、CVSSの点数は、自分のマシンが対象かどうかは教えてくれません。

対象と直し方

対象

影響はカーネル 4.4 以降です。

正確には、次の3つが揃ったサーバーが対象です。

1. カーネルの版が影響範囲にある。4.4 以降で、まだ修正版に更新していないもの
2. IPv4 の TCP で接続を待っている。Web・SSH・データベースなど、ほとんどのサーバーが当てはまる
3. 攻撃者のパケットがそこまで届く。インターネットに公開していなくても、同じネットワークの中から届くなら当てはまる

つまり、修正前のカーネルで TCP の待ち受けがある Linux サーバーは、基本的にすべて対象です。

上流は、Linux カーネル本体の開発元のことです。
上流の修正版は 5.10.272、5.15.223、6.1.190、6.6.159、6.12.113、6.18.56、7.2.10 と、7.3 以降です¹。

Debian 13 では、6.12.113-1 が DSA-6568-1 で修正済みと表示されています⁵。
DSA は、Debian のセキュリティ勧告の番号です。

直し方

直し方は、修正を含むカーネルに更新して再起動することです。
Red Hat は、条件を満たす回避策はないとしています³。

自分のカーネルが修正済みか確かめる

1. 動いているカーネルの版

uname -r

これが、今動いているカーネルの版です。
パッケージを更新していても、再起動するまでは古いカーネルが動いたままです。
判断は、必ずこのコマンドの結果で行います。

2. 修正が入っているか

uname -r の番号を、上流の修正版と比べます¹。

系列	修正版
5.10	5.10.272
5.15	5.15.223
6.1	6.1.190
6.6	6.6.159
6.12	6.12.113
6.18	6.18.56
7.2	7.2.10
7.3	7.3 以降はすべて修正済み

Ubuntu や Red Hat などのディストリビューションは、修正を独自の版番号のカーネルに取り込みます。
そのため、番号を上流と比べるだけでは判定できません。
各社の脆弱性情報のページで確認してください³⁴⁵。

3. ディストリビューションのカーネルの場合

今動いているカーネルに修正が入っているかを確かめます。
どれも uname -r や uname -v を使い、入っているだけのカーネルではなく、動いているカーネルを見ます。

# Ubuntu: 変更履歴に CVE 番号か修正の件名があるか
apt changelog linux-image-$(uname -r) | grep -E 'CVE-2026-98432|free inet_opt and ireq_opt'

# RHEL / Rocky / Alma: 変更履歴に CVE 番号か修正の件名があるか
rpm -q --changelog kernel-$(uname -r) | grep -E 'CVE-2026-98432|free inet_opt and ireq_opt'

# Debian: 動いているカーネルのパッケージの版を出す。6.12.113-1 などの修正版と比べる
uname -v

Ubuntu と RHEL 系で何も表示されなければ、動いているカーネルにはまだ修正が入っていない可能性が高いです。
変更履歴の書き方はディストリビューションごとに違うため、最終的な判定は各社のページで行ってください。
Ubuntu と RHEL 系のコマンドは、私の環境では試していません。

ここで分かるのは、対象の条件のうちカーネルの版だけです。
修正が入っていなければ、ss -tln で TCP の待ち受けがあるかも見て、対象かを判断します。

MPTCP は何に使うものか

Anthropic の説明では、攻撃の相手は MPTCP で待ち受けている Linux サーバーでした²。
ただし CVE の記録の本文に、MPTCP という言葉は出てきません¹。

MPTCP は Multipath TCP の略で、RFC 8684 で決められた TCP の拡張です⁶。
ふつうの TCP は、1つの接続で1つの経路しか使いません。MPTCP は、Wi-Fi とモバイル回線のような複数の経路を、1つの接続で同時に使えます。
帯域を束ねたり、片方の経路が切れても通信を続けたりできます⁷。

実は自分で使った覚えがなくても、使っている可能性があるようです。
Go 1.24 では、待ち受けの設定 ListenConfig が、Linux では既定で MPTCP を使うようになったようです⁸。

私のラズパイで確かめる

Debian 13 の Raspberry Pi で、読み取りだけの確認をしました。

uname -r
apt-cache policy linux-image-rpi-v8 | sed -n '1,3p'
zcat /proc/config.gz | grep '^CONFIG_MPTCP='
sysctl net.mptcp.enabled
sudo ss -Mlnp

ss -M は、MPTCP のソケットだけを表示するオプションです。
出力は次のとおりです。アドレスは伏せました。

6.12.47+rpt-rpi-v8
linux-image-rpi-v8:
  インストールされているバージョン: 1:6.12.47-1+rpt1
  候補:               1:6.18.50-1+rpt1
CONFIG_MPTCP=y
net.mptcp.enabled = 1
LISTEN 0  4096  x.x.x.x:443    x.x.x.x:*  users:(("tailscaled",pid=1117,fd=25))
LISTEN 0  4096  x.x.x.x:61540  x.x.x.x:*  users:(("tailscaled",pid=1117,fd=21))

確認すること	私の結果	判定
動いているカーネル	6.12.47	修正版 6.12.113 より前
MPTCP	組み込み済みで有効	使える状態
MPTCP で待ち受け	tailscaled の2つ	Tailscale の仮想ネットワーク側だけ

設定した覚えのない MPTCP の待ち受けが、Tailscale の常駐プロセスにありました。
Tailscale は Go で書かれています⁹。

上の Go の既定によるものとみられます。

Raspberry Pi のカーネルは、Debian のカーネルとは別のパッケージです。Debian の修正済みの表示は、そのまま当てはまりません。
私の環境の更新候補は 6.18.50 で、上流の修正版 6.18.56 より番号が前でした。
パッケージの変更履歴は取得できず、修正を含むかは確認できていません。

注意: MPTCP を止めても直らない

MPTCP を止める設定 net.mptcp.enabled は、新しく MPTCP のソケットを作れるかを決めるものです¹⁰。

	対策	理由
❌	MPTCP を止めて終わりにする	欠陥は IPv4 の TCP の処理にある。すでに動いている待ち受けにも効かない
✅	修正を含むカーネルに更新して再起動する	欠陥そのものが直る

Anthropic の実証は MPTCP の待ち受けが相手でしたが、ふつうの TCP で同じことができないとは書かれていません²。
私のラズパイでも、SSH が使う 22 番ポートは、ふつうの TCP で待ち受けていました。

まとめ

段階	やること	今回の結果
検知	CVE の記録で、影響する版と修正版を見る	修正版は 6.12.113 など
確認	uname -r で版を、ss -tln で TCP の待ち受けを見る。ss -M で MPTCP の待ち受けもあれば優先度を上げる	6.12.47 で対象。MPTCP の待ち受けあり
対処	修正を含むカーネルに更新する	Raspberry Pi の修正版を待って更新する

9.8 という数字を見てから、私の結果が出るまでにかかったのは、コマンド5つでした。
次に試すことは、Raspberry Pi のカーネルの変更履歴で、この修正の取り込みを確かめることです。

CVSS の数字に驚き、拡散する前に、まずは自分が対象かを確かめましょう！
対象なら直す、対象でなければ安心して次へ進む。
やることは、それだけです。

参考

1. CVE-2026-98432 の記録 https://www.cve.org/CVERecord?id=CVE-2026-98432 ↩ ↩² ↩³ ↩⁴ ↩⁵ ↩⁶

2. Anthropic「Discovering and exploiting vulnerabilities in critical, real-world software with Claude」 https://www.anthropic.com/research/discovering-vulnerabilities-with-claude ↩ ↩² ↩³

3. Red Hat CVE-2026-98432 https://access.redhat.com/security/cve/cve-2026-98432 ↩ ↩² ↩³

4. Ubuntu CVE-2026-98432 https://ubuntu.com/security/CVE-2026-98432 ↩ ↩²

5. Debian Security Tracker CVE-2026-98432 https://security-tracker.debian.org/tracker/CVE-2026-98432 ↩ ↩²

6. RFC 8684 TCP Extensions for Multipath Operation with Multiple Addresses https://www.rfc-editor.org/rfc/rfc8684 ↩

7. Multipath TCP for Linux https://www.mptcp.dev/ ↩

8. Go 1.24 Release Notes https://go.dev/doc/go1.24 ↩

9. tailscale/tailscale https://github.com/tailscale/tailscale ↩

10. MPTCP Sysfs variables, The Linux Kernel documentation https://docs.kernel.org/networking/mptcp-sysctl.html ↩