先に要点
- Linux カーネルの 権限昇格の脆弱性 Fragnesia（CVE-2026-46300）が、2026年10月28日に CISA の「悪用が確認された脆弱性」の一覧（KEV）に追加されました。対応の期限は10月31日で、侵害の調査も求められています。深刻度は CVSS 7.8（High）で、ローカルのユーザーが root になれる問題です。
- 「ローカル」の問題でも、軽く見てはいけません。PHP の脆弱性（PHP2Shell）で Web サーバーに入られたあと、この脆弱性で root まで上がる使われ方が報告されています。KEV の説明も、PHP の2つの脆弱性との連鎖を名指ししています。
- 修正はカーネルの更新と再起動です。Ubuntu では 22.04 が 5.15.0-181.191、24.04 が 6.8.0-124.124 以降で修正済みです。Debian と RHEL も修正版が出ています。更新しても、再起動するまでは直りません。
- 更新できないときの暫定対処は、IPsec 用のカーネルモジュール（esp4・esp6・rxrpc）を読み込めなくすることです（Ubuntu の案内）。ただし IPsec の VPN などが止まるので、使っていないか確かめてから行います。
- 悪用が疑われるときは、再起動の前にメモリ上の状態とログを残します。この手口はメモリ上のキャッシュを書き換えるため、再起動すると手がかりが消えるおそれがあります。
自社や自分の Linux サーバーを運用している方向けの記事です。2026年10月28日に KEV へ追加されたと聞いて、自分のサーバーは対象か、何をいつまでにすればよいかを確かめたい人が、そのまま作業できるようにまとめました。
この記事は、Ubuntu のセキュリティ情報、Debian のセキュリティトラッカー、Red Hat のセキュリティ情報、NVD、CISA の KEV、Dream（セキュリティ企業）の調査レポート（いずれも2026年10月30日に確認）をもとにしています。ディストリビューションごとの修正版は日々更新されるので、作業の直前に各社の公式ページで最新を確かめてください。
何が起きたのか：キャッシュの書き換えで root を取る
Fragnesia は、Linux カーネルの IPsec の仕組み（XFRM の ESP を TCP で運ぶ処理）に見つかった問題です。Red Hat の説明では、権限の低いローカルのユーザーが、読み取り専用のファイルのページキャッシュ（ファイルを読んだときにメモリに置かれる写し）へ、好きなバイト列を書き込める、とされています。重要なシステムのファイルを書き換えて、root の権限を得る使い方ができます。
Fragnesia が root につながる流れ（NVD・Ubuntu・Dream の記述より）
- 1
- 2ESP の処理が、共有されたままの領域を直接書き換える
印が無いので、ESP の入力処理は「書き換えてよい領域」と誤って判断し、復号の結果をページキャッシュの上に直接書いてしまう。
- 3読み取り専用のファイルの中身が、メモリ上で書き換わる
Dream の調査では、/etc/pam.d/su の認証の設定を「すべて許可」に置き換える使い方が確認された。
- 4su root がパスワードなしで通る
認証の設定が書き換わった結果、権限の低いユーザーが root になれる。
脆弱性の名前や関連の番号が多いので、整理しておきます。
| 名前・番号 | 内容 |
|---|---|
| Dirty Frag（CVE-2026-43284、CVE-2026-43500） | 2026年5月7日に公開された、ESP と RxRPC のカーネルモジュールの権限昇格。Fragnesia はこの変種（Red Hat の表現） |
| Fragnesia（CVE-2026-46300） | 今回の話題。NVD への掲載は2026年5月23日。10月28日に KEV へ追加 |
| PHP2Shell（CVE-2026-109618、CVE-2026-109619） | PHP の脆弱性。認証なしでコード実行を受けうる。2026年10月21日に NVD へ掲載 |
KEV の説明には、「この脆弱性は CVE-2026-109618・CVE-2026-109619 と連鎖させると、PHP の webshell を設置し、root でコマンドを実行できる」と書かれています。Dream の調査レポートでは、実際にこの2つを組み合わせた攻撃が観測されたと報告されています。PHP2Shell そのものは PHP2Shell の記事で解説しています。
CVSS の評価では、攻撃にはサーバー上の低い権限での実行が必要です。しかし、Web アプリの脆弱性で nobody や www-data のような権限のコード実行を取られると、その条件は満たされます。Web アプリの脆弱性と権限昇格が連鎖すると、実質的には外から root まで届きます。PHP や Web アプリを動かしているサーバー、共用のサーバー、コンテナの基盤、CI の実行環境は、特に優先して更新します。
自分のサーバーは対象か：修正済みの版を確かめる
カーネルの版は、ディストリビューションが独自の番号を付けています。次の表は、各社の公式情報にある修正済みの版です。
| ディストリビューション | 修正済みの版（これ以降なら修正済み） | 出典 |
|---|---|---|
| Ubuntu 26.04 LTS | 7.0.0-22.22 | Ubuntu の CVE ページ |
| Ubuntu 25.10 | 6.17.0-35.35 | 同上 |
| Ubuntu 24.04 LTS | 6.8.0-124.124 | 同上 |
| Ubuntu 22.04 LTS | 5.15.0-181.191 | 同上 |
| Ubuntu 20.04 LTS | 標準のカーネルは対象外。HWE 5.15 は 5.15.0-181.191~20.04.1（Ubuntu Pro） | 同上 |
| Debian 13（trixie） | 6.12.90-1（現行のセキュリティ版は 6.12.113-1） | Debian のセキュリティトラッカー |
| Debian 12（bookworm） | 6.1.174-1（現行のセキュリティ版は 6.1.190-1） | 同上 |
| Debian 11（bullseye） | 5.10.257-1 | 同上 |
| RHEL 8・9・10 | 系列ごとに別々の RHSA で修正（Red Hat は重要度を Important と分類） | Red Hat の CVE ページ |
| 上流のカーネル | 5.15.208・6.1.174・6.6.141・6.12.91・6.18.33・7.0.10 以降 | NVD |
RHEL は系列ごとに RHSA が多数あるため、表にはまとめず、Red Hat の CVE ページで、使っているマイナー版の項目を確かめてください。
# 動いているカーネルの版（Ubuntu・Debian・RHEL 共通）
uname -r
# Ubuntu・Debian：入っているカーネルのパッケージ
dpkg -l "linux-image*" | grep ^ii
# RHEL 系：パッケージの変更履歴に、この CVE への言及があるか
rpm -q --changelog kernel | grep CVE-2026-46300
次に、関係するカーネルモジュールが実際に読み込まれているかを見ます。Ubuntu の案内にある確認を、そのまま使えます。
# esp4・esp6・rxrpc が読み込まれていれば表示される
grep -E "^(esp4|esp6|rxrpc) " /proc/modules
# 今回の再現に必要とされる espintcp も確かめる
lsmod | grep -E "esp4|esp6|espintcp|rxrpc"
Ubuntu のセキュリティチームは、公開されている再現コードが espintcp というモジュールを必要とするため、それ以前の古いカーネル（4.15・5.4）では実際には動かないと説明しています。一方で、読み込まれていなくても、権限のあるユーザーが読み込ませられる可能性があります。モジュールが見つからないことを理由に更新を見送らず、修正版へ上げてください。
更新の手順：カーネルを上げて、再起動する
修正は、ディストリビューションのカーネルのパッケージを更新し、再起動することです。更新しただけで再起動しないと、古いカーネルが動き続けます。
更新から確認までの流れ
- 1
- 2疑わしい兆候があれば、再起動の前に証拠を残す
悪用の疑いがあるサーバーは、再起動するとメモリ上の手がかりが消える。ログと、メモリ上の状態の取得を先に行う（次の節）。
- 3カーネルのパッケージを更新する
Ubuntu・Debian は apt、RHEL 系は dnf（または yum）で、カーネルを含む更新を適用する。
- 4再起動する
再起動しないと反映されない。ライブパッチを使っている環境は、提供元がこの CVE に対応しているかを確かめる。
- 5動いているカーネルの版を確かめる
uname -r で、修正済みの版になったことを確認する。
Ubuntu の公式ブログ（Dirty Frag の案内）に載っている更新の方法は次のとおりです。
# すべてのパッケージを更新する
sudo apt update && sudo apt upgrade
# 再起動する（カーネルの更新後に必要）
sudo reboot
Ubuntu は 16.04 LTS 以降、unattended-upgrades が標準で有効になっていて、24時間以内にセキュリティ更新が自動で適用されると説明しています。ただし、再起動は自動では行われません。更新の適用と再起動の両方が済んだかを、uname -r で確かめます。
Ubuntu のセキュリティチームは、Fragnesia の修正は Dirty Frag の修正（CVE-2026-43284）と合わせて入れることが重要だと書いています。43284 の修正が、共有の印を復号の時に実際に確かめる部分で、Fragnesia の修正は、その印が途中で失われないようにする部分だからです。ディストリビューションが配る最新のカーネルに更新していれば、通常は両方が入っています。個別のパッチを自分で取り込むことは勧められていません。
すぐに更新できないとき：モジュールを止める暫定対処
Ubuntu は、Fragnesia について「Dirty Frag と同じ手順で暫定対処できる」と案内しています。ESP と RxRPC のカーネルモジュールを読み込めなくする方法です。
手順（Ubuntu の案内）
モジュールを読み込めなくする設定ファイルを作り、起動時の読み込みも止め、いま読み込まれているものを外し、外れたかを確かめます。外せなければ再起動が必要です。
止まるもの
IPsec を使う VPN（StrongSwan など）と、RxRPC を使う AFS（Andrew File System）が影響を受けます。使っているサーバーでこの対処をすると、通信が止まります。
更新したら元に戻す
カーネルを更新したあとは、この対処は不要です。設定ファイルを消し、起動時の読み込みの設定を作り直します。
# 1. esp4・esp6・rxrpc を読み込めなくする
echo "install esp4 /bin/false" | sudo tee /etc/modprobe.d/dirty-frag.conf
echo "install esp6 /bin/false" | sudo tee -a /etc/modprobe.d/dirty-frag.conf
echo "install rxrpc /bin/false" | sudo tee -a /etc/modprobe.d/dirty-frag.conf
sudo update-initramfs -u -k all
# 2. 読み込まれているものを外す
sudo rmmod esp4 esp6 rxrpc 2>/dev/null
# 3. 外れたかを確かめる（"NOT loaded" が出れば完了）
grep -qE "^(esp4|esp6|rxrpc) " /proc/modules && echo "Affected modules are loaded" || echo "Affected modules are NOT loaded"
# 更新後に、暫定対処を元に戻す
sudo rm /etc/modprobe.d/dirty-frag.conf
sudo update-initramfs -u -k all
上の手順は Ubuntu 向けです。Debian や RHEL では、ファイルの置き場所や initramfs の更新コマンドが異なります。ディストリビューションの案内を確かめてから行ってください。また、モジュールを止める対処は、更新までのつなぎです。更新の計画は止めないでください。
悪用されていないかを確かめる：再起動の前に
KEV の CVE-2026-46300 の項目には、侵害調査（フォレンジックのトリアージ）が必要という印が付いています。CISA の実施ガイダンスは、可能なら、システムを書き換える前に、メモリ上の消えやすい情報から先に集めるように求めています。再起動やパッチ適用で、手がかりが失われるためです。
メモリ上の手がかり
この手口は、ファイルの本体ではなく、メモリ上のキャッシュを書き換えます。ディスクにあるファイルは変わらないまま、読み出したときの見え方だけが変わる可能性があります（これは、ページキャッシュの性質からの筆者の推測で、公式の記述ではありません）。再起動すれば書き換えは消えるので、疑わしいサーバーは再起動する前に確かめます。
/etc/pam.d/su を見る
Dream の調査では、/etc/pam.d/su の認証の設定が、すべてを許可する pam_permit.so に置き換えられていました。cat /etc/pam.d/su の内容を、配布されたパッケージの元の内容と比べます。パッケージ検証（dpkg -V など）はディスク上のファイルを調べるため、この手口の検知には向かない可能性があります。
ログを見る
Web サーバーのアクセスログに、PHP2Shell に関係する不審な大量リクエストが無いか、認証のログ（/var/log/auth.log や /var/log/secure）に、見覚えのない su での root への切り替えが無いかを調べます。
疑わしければ
ネットワークから切り離し、再起動せずに専門家へ相談するほうが、手がかりが残ります。サーバー上の鍵・トークン・パスワードは、再発行の対象になります。
Dream の報告では、攻撃者は root を取ったあと、ドメインのディレクトリ情報の列挙や、認証情報の取り出しにも進んでいました。サーバーが侵害された場合は、そのサーバーに保存されていた認証情報だけでなく、そこから届く社内の仕組みへの影響も見ます。
今回の学び：「ローカルの脆弱性」と「連鎖」
脆弱性は単独でなく連鎖で見る
PHP の脆弱性で入られても、そこでは nobody のような低い権限にとどまります。権限昇格が組み合わさって初めて、サーバー全体を取られます。どちらか一方の更新が漏れていても、連鎖は成立します。
カーネルの更新は再起動の計画が要る
カーネルの更新は、再起動するまで効きません。毎月の更新の日を決めて、再起動の時間をあらかじめ確保しておくと、今回のような期限付きの対応にも動きやすくなります。
修正は公開済みだった
上流のカーネルの修正は5月に出ていて、NVD への掲載も5月23日です（ディストリビューションごとの修正版の公開日は各社で異なります）。修正版が出た時点でカーネルを更新して再起動していたサーバーは、10月の KEV 追加に慌てずに済みました。
管理画面を公開しない
Dream の報告で狙われたのは、インターネットに公開されていた管理用の Web 画面でした。管理画面は、VPN や IP アドレスの制限の内側に置くのが基本です。
KEV の使い方は KEVカタログとは？、情報の集め方は 脆弱性情報の集め方 で解説しています。同じ時期に KEV へ入った自社運用の GitLab の脆弱性は GitLab の記事 を参照してください。
よくある質問
VPS やクラウドの仮想マシンを使っているだけでも対象ですか？
仮想マシンの中の Linux のカーネルは、基本的に自分で更新するものです。VPS やクラウドの仮想マシンを借りている場合は、自分で更新と再起動を行います。マネージドサービス（カーネルの管理が事業者側のもの）は、事業者の案内を確かめます。
Docker のコンテナを使っていますが、影響はありますか？
コンテナは、ホストのカーネルを共有します。Ubuntu のセキュリティチームは、この問題が権限昇格や、コンテナからの脱出につながる可能性があると説明しています。コンテナの中のパッケージを更新しても直らず、ホスト側のカーネルを更新して再起動する必要があります。
IPsec や VPN を使っていないので、大丈夫ではないですか？
使っていなくても、更新するのが安全です。Ubuntu は、公開されている再現コードが espintcp というモジュールを必要とすると説明していますが、対象の判断は、使っているかどうかではなく、修正済みの版かどうかで行います。
悪用は確認されていますか？
はい。CISA は KEV に追加しており、PHP2Shell と組み合わせた攻撃も報告されています。ランサムウェアの攻撃での利用が確認されているかは、KEV では「不明」とされています（2026年10月30日時点）。
更新したのに、まだ不安です
動いているカーネルの版（uname -r）が修正済みの版以降かを確かめます。更新だけで再起動していない場合は、古いカーネルのままです。そのうえで、更新前に悪用された可能性があるサーバーは、前の節の確認を行います。
まとめ
- Linux カーネルの権限昇格 Fragnesia（CVE-2026-46300、CVSS 7.8）が2026年10月28日に KEV に追加。期限は10月31日で、侵害調査も求められる
- PHP2Shell（CVE-2026-109618・109619）と連鎖させて、外から root を取る攻撃が報告されている。「ローカルだから」と後回しにしない
- 修正はカーネルの更新と再起動。Ubuntu 22.04 は 5.15.0-181.191、24.04 は 6.8.0-124.124 以降。Debian・RHEL も修正版あり。コンテナを使う環境はホストを更新する
- 暫定対処は esp4・esp6・rxrpc を止めること（Ubuntu の案内）。ただし IPsec の VPN などが止まるので、更新までのつなぎにとどめる
- 悪用の疑いがあれば、再起動の前に証拠を残す。この手口はメモリ上のキャッシュを書き換える
- 同じ週には、IPv4 の TCP 処理の use-after-free（CVE-2026-98432、CVSS 9.8）も公開されている。KEV には未掲載だが、外部に向けて待ち受けるサーバーは更新の準備が要る（確認と更新の記事）
参考リンク
- CVE-2026-46300（Ubuntu のセキュリティ情報）・Dirty Frag の暫定対処と修正版（Ubuntu ブログ）
- CVE-2026-46300（Debian セキュリティトラッカー）
- CVE-2026-46300（Red Hat）
- CVE-2026-46300（NVD）
- Known Exploited Vulnerabilities Catalog（CISA）・BOD 26-04 実施ガイダンス（CISA）
- Chained PHP2Shell Exploit Roots 25 Servers（Dream Research、2026年10月26日、10月29日更新）
- PHP の脆弱性（CVE-2026-109618、CVE-2026-109619）に関する注意喚起（JPCERT/CC）