CVE-2026-46300 LinuxカーネルFragnesiaがKEVに追加——今すぐ確認すべき対処手順

公開日：2026年10月30日文：クリスタルメソッド編集部監修：河合継（代表取締役）

Linuxカーネルの権限昇格CVE-2026-46300（Fragnesia）がKEVに追加——配布カーネルは各社の修正パッケージで確かめる

Fragnesia（CVE-2026-46300）が悪用確認リストに追加された——何が起きているか

2026年10月28日、米サイバーセキュリティ・インフラストラクチャセキュリティ庁（CISA）は「悪用が確認された脆弱性カタログ（KEV）」にLinuxカーネルの脆弱性CVE-2026-46300を追加した（CISA KEV）。修正は2026年5月13日に、CVEの記録は5月23日に公開済みだったが、KEV追加によって「現在も実際に悪用されている」という事実が公式に確定した。「修正はもう出ているから大丈夫」という判断が通用しなくなった時点が、2026年10月28日だ。

CWE分類は「変数の初期化漏れ（CWE-456）」。CVSS 3.1 スコアは 7.8（High）で、攻撃元はローカル・特権不要・利用者操作不要（AV:L/AC:L/PR:L/UI:N）、機密性・完全性・可用性のいずれも High と評価されている（cve.org）。

Red Hat はこの脆弱性に「Fragnesia」という通称を付け、過去の「Dirty Frag」（CVE-2026-43284）の亜種と位置づけている（access.redhat.com）。CISAは連邦政府機関に対して対処期限を 2026年10月31日と定めているが、これは連邦政府機関向けの期限であり、民間企業への法的拘束力はない。ランサムウェアでの悪用についてCISAは「Unknown（不明）」としており、断定できる情報はない。なお、この不具合の修正（カーネルパッチ）は2026年5月13日に公開されており、そのときから概念実証（PoC）も公開されていた（Tenable、2026年5月14日付）。

攻撃者が社内の別の機器へ広がっていく手口は、ラテラルムーブメントの手口・ツール・対策で解説しています。

関連記事Linux CVE-2026-98432、今何をする？

なぜ低権限のアカウントから root を取られるのか——仕組み

脆弱性の核心は、Linuxカーネルのネットワークスタックにある skb_try_coalesce() という関数の実装漏れだ。ソケットバッファ（skb）のページ断片を別のバッファへ移す処理で、元のバッファが持っていた「共有フラグメントの印（SKBFL_SHARED_FRAG）」が引き継がれなかった（cve.org）。

その結果、ESP（Encapsulating Security Payload）の入力処理が skb_has_shared_frag() を false と判断し、ページキャッシュ由来のページ断片に対して「その場で」復号を行ってしまう。復号はページキャッシュ上のデータを直接書き換えるため、読み取り専用のファイル——特権バイナリや重要な系統ファイルを含む——のキャッシュを低権限のユーザーが改ざんできる状態になる。改ざんした特権バイナリを実行させることで、root 権限を取得できる経路が生まれる。

攻撃者に必要なのは、対象サーバーで何らかのコードを実行できる低権限のローカルアカウントだ。この脆弱性単体は遠隔からの侵入手段を持たない。CISAの告知には、PHP の脆弱性（CVE-2026-109618・CVE-2026-109619、いずれも2026年10月26日にKEV追加）と組み合わせることで、Webシェルを仕込んで root でコマンドを実行できると記載されている。これは組み合わせが「可能」という記載であり、実際の攻撃のすべてがこの経路を使っているとはCISAは断定していない（CISA KEV）。

また、Fragnesia の完全な修正には関連CVEである CVE-2026-43503（Fragnesia の2つ目のコミット）と CVE-2026-43284（Dirty Frag・IPsec ESP）の修正が両方そろう必要があると Ubuntu は注記している（ubuntu.com/security）。

図: CVE-2026-46300 の攻撃経路。低権限のローカルアカウントがカーネルの SKBFL_SHARED_FRAG 引き継ぎ漏れを突き、ページキャッシュ上の読み取り専用ファイルを書き換えて root 権限を取得するまでの流れ。

次に読む：Magento脆弱性、ECサイトは今何を？

Magento脆弱性CVE-2026-48356——CISAが悪用確認、ECサイト今すぐやること

ディストリビューション別の修正状況——配布カーネルは各社のパッケージ版で確かめる

上流カーネルの修正版番号（5.10.257・6.1.174 など）と、配布カーネルの uname -r で表示される版番号は直接比較できない。配布カーネルは上流の修正を取り込んだうえで独自の版番号を持つため、各ディストリビューションの修正パッケージ版で判断する必要がある（ubuntu.com/security、RHSB-2026-003）。

表: CVE-2026-46300 各ディストリビューションの修正済みカーネルパッケージ版（2026年10月30日時点）
ディストリビューション	修正済みパッケージ版（例）	深刻度	出典
Ubuntu 26.04 LTS	7.0.0-22.22	High	Ubuntu Security
Ubuntu 25.10	6.17.0-35.35	High	Ubuntu Security
Ubuntu 24.04 LTS	6.8.0-124.124	High	Ubuntu Security
Ubuntu 22.04 LTS	5.15.0-181.191	High	Ubuntu Security
Ubuntu 20.04 以前	影響なし（Ubuntu評価）	—	Ubuntu Security
RHEL 10	6.12.0-211.16.1.el10_2	Important	Red Hat CVE
RHEL 9	5.14.0-687.10.1.el9_8	Important	Red Hat CVE
RHEL 8	4.18.0-553.125.1.el8_10	Important	Red Hat CVE
Debian bookworm	6.1.190-1	—	Debian Security Tracker
Debian trixie	6.12.113-1	—	Debian Security Tracker
Debian bullseye	5.10.257-1（DLA-4606-1）	—	Debian Security Tracker
SUSE（全対象製品）	Resolved（SUSE-SU 多数公開済み）	Important（CVSS 8.8）	SUSE Security

※ RHEL の EUS・SAP 向けなど派生版のパッケージ版は上表の版と異なる。Red Hat の告知（RHSB-2026-003）で対象製品ごとに確認する。Ubuntu 20.04 以前が「影響なし」なのは Ubuntu の評価であり、他のディストリビューションの旧バージョンに当てはまるとは言えない。

Ubuntu の評価によれば、Ubuntu 20.04 以前（カーネル 4.15・5.4 系）で「影響なし」とされる理由は、攻撃コードの実行に必要な espintcp モジュールが Linux カーネル v5.6 以降でしか提供されていないからだ（ubuntu.com/security）。

自社が対象か判断がつかない場合は、お使いの製品と版の情報をお送りいただければ、公式情報をもとに対象かどうかの目安をお伝えします（無料相談）。

今日から動くための具体的な対処手順

CISA は KEV 追加と同時に「Forensics Triage（侵害の有無の初期調査）」の実施を求めている（CISA KEV）。修正パッケージを入れる前に、すでに侵害されていないかを確認する手順を先に踏む、という趣旨だ。

ステップ 1: 動いているカーネルを確認する

uname -r

Ubuntu/Debian 系は次のコマンドで入っているカーネルパッケージの一覧と版も確認できる。

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

RHEL/CentOS 系は次を使う。

rpm -q kernel

ステップ 2: 修正パッケージを適用して再起動する

カーネルは再起動しないと入れ替わらない。Ubuntu の場合は次の2コマンドを順に実行する（ubuntu.com/security）。

sudo apt update && sudo apt upgrade
sudo reboot

RHEL・SUSE・Debian は各社の告知（RHSB-2026-003、SUSE Security、DLA-4606-1）に従い、対象のカーネルパッケージを更新してから再起動する。

ステップ 3: すぐに修正を入れられないサーバーには公式の緩和策を適用する

Red Hat が公式に示している緩和策は2通りある（1つ目は Ubuntu も同じ手順を案内している。2つ目は Red Hat のみ）（RHSB-2026-003、ubuntu.com/security）。

IPsec を使っていない環境: esp4 と esp6 のモジュールを読み込まないようにする。

echo "install esp4 /bin/false" >> /etc/modprobe.d/disable-esp.conf
echo "install esp6 /bin/false" >> /etc/modprobe.d/disable-esp.conf
rmmod esp4 2>/dev/null; rmmod esp6 2>/dev/null

IPsec（VPN）を使っている環境: 非特権ユーザー名前空間を無効化する。

sysctl -w user.max_user_namespaces=0

どちらの緩和策にも副作用がある。前者は IPsec（strongSwan など）が動かなくなる。後者はルートレスコンテナ・ブラウザのサンドボックス・Flatpak に影響する可能性がある、と Red Hat が明記している。緩和策はカーネル修正を入れるまでの一時措置であり、修正の代替ではない（RHSB-2026-003）。

優先すべきサーバーの判断基準

複数のサーバーを運用している場合、次の順で優先度を考えるのが合理的だ。

複数のユーザーがログインできるサーバー（共有開発環境・踏み台サーバーなど）
コンテナを複数テナントで共有するホスト（Ubuntu はコンテナ外への脱出の可能性にも言及している）
PHP が動いているWebサーバー（CISAが言及した PHP の2件・CVE-2026-109618・CVE-2026-109619 との組み合わせが考えられるため）

PHP を使うサーバーでは、PHP 側の2件の脆弱性も修正済みかどうかを同時に確認しておくことを勧める（CISA KEV）。

ESP のモジュールが現在読み込まれているかどうかは次のコマンドで確認できる。

lsmod | grep -E 'esp4|esp6'

非特権ユーザー名前空間の現在の設定は次で確認できる。

sysctl user.max_user_namespaces

CVE-2026-46300 はローカル権限昇格の脆弱性であり、遠隔から直接攻撃できるタイプではない。なお、同じ Linux カーネルの別の脆弱性 CVE-2026-98432 は、TCP の use-after-free で遠隔から攻撃できるタイプであり、攻撃経路も修正パッケージも異なる。本稿の対処手順はそちらには当てはまらない。CVE-2026-98432 を調べている場合は、別の記事AIが見つけたLinuxカーネルの重大脆弱性CVE-2026-98432のほうが対象になる。

〈参考文献〉