Linuxの『古い配管』、3週間で3度目の同時破裂。サーバー乗っ取り連鎖

気づかない間に、すでにあなたのサーバーが乗っ取られているかもしれません。3週間で3度目です。Linuxカーネルの「古い配管」がまた1本破裂しました。

CVE-2026-46300、通称「Fragnesia（フラグネシア）」。2026年5月13日に公開されたLinuxカーネルの脆弱性で、4月29日のCopy Fail、5月7日のDirty Fragに続く、3週間で3本目の「一般ユーザーが管理者権限（root）を奪える」脆弱性です。今回も公開と同時に動く攻撃コード（PoC）が出回りました。誰でも手元のLinuxサーバーで試せる状態です。

これは偶然3本続いただけのこと——では、ありません。Linuxカーネルの古い部分が、いま一斉に剥がれ始めています。本記事では、Fragnesiaが何者なのか、なぜ3週間で3度目が起きたのか、そしてパッチを当てれば本当に終わるのかを、運用者の判断材料として整理します。

Fragnesiaは何が起きたのか

Fragnesiaは、LinuxカーネルのIPsec通信処理（XFRM ESP-in-TCPサブシステム）にあるバグです。IPsecとは、ネットワーク通信を暗号化するための仕組みで、VPN・社内ネットワーク・クラウド間通信などで広く使われています。

バグの本体はskb_try_coalesce()というカーネル内部の関数にあります。ネットワークから届いたデータを、カーネル内のバッファ（socket buffer、略してskb）同士で寄せ集めて整理する処理です。このとき、本来引き継ぐべきSKBFL_SHARED_FRAGという目印が伝わっていませんでした。

この目印は「このメモリの断片は、カーネルが独占しているのではなく、外（ファイルのページキャッシュなど）から持ち込まれた共有領域だぞ」という注意書きです。注意書きが消えるとどうなるか。カーネルが「自分のメモリ」だと思って書き込んだ場所が、実は読み取り専用ファイルのメモリ上のコピーだった、という事故が起きます。

攻撃者はWizの解説によれば、この事故を仕組みに変えます。ESP-in-TCPの復号処理を経由して、/usr/bin/su（root権限でログインを切り替えるコマンド）の中身を、メモリ上で書き換えます。ディスク上のファイルは無傷のままです。書き換わるのはメモリ上のコピーだけ。そして次に誰かがsuを呼ぶと、書き換わった命令が実行されてroot権限が奪われます。

発見・公開したのは、セキュリティ企業V12 SecurityのWilliam Bowling氏。攻撃に必要なのは、サーバーにログインできる一般ユーザー権限だけです。クラウドサービスの共用環境、開発者アカウント、Webアプリケーションから乗っ取った非rootシェル——どこからでも、ここから一段上の管理者権限へ駆け上がれます。

なぜ3週間で3度目が起きたのか

「偶然続いているだけ」と考えたくなりますが、構造を見るとそうではありません。3本のバグには共通点があります。

1本目のCopy Failは、カーネルの暗号機能の窓口（AF_ALG）とsplice()を組み合わせ、ページキャッシュに4バイトを書き込みました。2本目のDirty Fragは、IPsec暗号処理（ESP）とRPC通信処理（RxRPC）の「その場復号」の経路にある同種の欠陥を悪用しました。そして3本目のFragnesiaも、同じくESP系の経路で、socket bufferの断片管理に潜む欠陥を突きました。

いずれも、カーネルが他の領域から借りてきたメモリ断片を「自分のもの」と勘違いして書き込み、結果としてファイルのメモリ上のコピーを書き換えてしまう、という同型の構造です。攻撃面（バグの所在）は別々ですが、根っこの設計思想——「ページキャッシュとカーネル内部バッファの所有権を、暗黙の前提に頼って管理する」というやり方——は20年ほど前から続く古い設計です。

そこへ2025年以降、自動でバグを掘り出す道具が一気に進化しました。syzkaller（Googleが開発したカーネルファジングツール）、KASAN（カーネル内のメモリ破壊を検知する仕組み）、そしてAI支援によるコード解析。これまで「読める人がいなかった層」が、機械の手で次々と可視化されています。Dirty FragとFragnesiaが同じESP系の隣接コードから1週間以内に出てきたのは、攻撃面が広いからではなく、その層に光が当たり始めたからです。

古い設計が、いま一斉に検査台の上に乗せられている。これがLinuxカーネルで現在進行中のことの本質です。読者の方には先に伝えておきますが、第4・第5の同種の脆弱性は、近いうちに来ます。

3週間で連発したLinuxカーネル脆弱性の系譜

過去にもLinuxには「全主要ディストリビューションを同時に巻き込む」脆弱性が定期的に出てきました。ここ数年の系譜を並べると、今回の3連発の異常さがよく見えます。

PwnKitからLooney Tunablesまでは1〜2年に1度の頻度でした。それがCopy Fail以降、2週間に1本のペースに加速しています。バグの所在は権限管理ツール、パイプ、ライブラリ、暗号窓口、IPsecと一見バラバラですが、運用者から見ると影響は同型です。「Linuxを使っている限り、ほぼ全部のサーバーで管理者権限を奪われ得る」という現実が、3週間で3度繰り返されました。

なお、本サイトではCopy Failの記事を系譜の起点として位置付け、本記事を続編として扱います。次に同型のバグが来たときは、本記事と前記事の判断フレームが再利用できる構造で書き残しています。

あなたのサーバーで、今夜何が起きうるのか

あなたのサーバーは、いま静かに「代わりの主」を迎えようとしているかもしれません。3週間で3度目の脆弱性公開という事実が、ここで生活実感に着地します。

最初に押さえたいのは、「マネージドOSか、自前で管理しているLinuxか」の線引きです。AWSのBottlerocket、Google KubernetesのCOS（Container-Optimized OS）、AzureのCBL-Marinerのようなクラウド事業者がパッチ配布まで面倒を見るマネージドOSは、Fragnesia公開後の数時間〜数日でホスト側の自動アップデートが進みます。一方、自前ビルドのLinux、ユーザーが直接管理しているEC2 / GCE / Azure VM、社内Jenkinsホスト、self-hostedのGitHub Actionsランナー、Dockerホスト群——これらは生身のままです。攻撃者がいま狙うのは、まさにこの後者の層です。

具体的に何が起きうるのか、業務シーンに翻訳して並べます。

いずれも「サーバーにログインできる一般ユーザー権限」を出発点とします。WebアプリのRCE（任意コード実行）で奪った非rootシェル、開発者の踏み台アカウント、共用クラウド環境の隣のテナント——どれもが起点になりえます。

では、やられたらどう気づくのか。ディスク上のファイルは改ざんされないという性質上、通常のファイル整合性監視（Tripwire、AIDE等）は無力です。代わりに、運用者が現場で気づきうるシグナルを並べます。

玄関ドアノブを回すと、一瞬だけ何かに引っかかる感覚——SSHログインが瞬間的に詰まる、ログイン直後のプロセス一覧に見慣れないものが混ざる。自分の手帳に、書いた覚えのない予定が勝手に増えている——crontabや/etc/cron.d/に身に覚えのないジョブが追加されている。日記帳が一晩で異様に分厚くなっている——journaldのログサイズが急に膨らみ、xfrm_state_allocなどESP系の関数呼び出しが異常頻度で記録される。電気代の請求書が、先月の3倍届く——AWS / GCP / Azureの請求額が突発的に跳ね上がり、CloudTrailに不自然なAssumeRoleバーストが残る。

技術的にはdmesgのxfrm関連の異常メッセージ、auditdで記録されたsetuid(0)呼び出しの親プロセス系統、SIEMでの不自然なrootシェル取得イベントが該当します。読者の方が担うべきは「自社の責任範囲を自覚すること」までで、系譜全体の継続観測は本サイトの編集部が引き受けます。

1週間前のDirty Fragとは何が違うのか

FragnesiaはDirty Fragの「修正漏れ」ではありません。別のバグです。ただし、攻撃面と緩和策は非常に近いため、ここで簡単に整理しておきます。

Dirty Frag（5月7日公開）は、独立研究者のHyunwoo Kim氏が発見した2つのバグの組み合わせです。CVE-2026-43284（IPsecのesp4/esp6サブシステム）とCVE-2026-43500（RxRPCサブシステム）を組み合わせ、暗号復号処理が外部から借りてきたメモリ領域（splice()やsendfile()でパイプから流し込まれたページ）を、カーネルが自分の領域だと誤認することで、ページキャッシュへの書き込み権限を作り出します。CVSSスコアはどちらも7.8。Microsoftは攻撃が実際に観測されている可能性を示唆しています。

これに対し、Fragnesia（5月13日公開）は、Dirty Fragの修正コミットを当てたカーネルでも、別経路から同じ「書き込み権限」が作れることを示しました。問題のある関数はskb_try_coalesce()で、ESP-in-TCPの経路に存在します。CloudLinuxの解説によれば、上流のDirty Frag修正パッチは、この経路を塞ぎきれていませんでした。

2つを並べてみると、共通点が浮かびます。どちらもLinuxのIPsec実装の周辺コードに潜んでいて、どちらも外部から借りたメモリ断片の所有権管理ミスでroot奪取に至ります。緩和策（後述）も同じ手順で済みます。攻撃手法としては独立していますが、運用上は1セットで扱うのが現実的です。

本記事ではDirty Fragの詳細な解説までは踏み込みませんが、TenableのDirty Frag FAQとWizの技術解説が要点をまとめています。

築30年オフィスビルの空調ダクトと同じ話

技術的な説明が続いたので、ここで一度、別の物に置き換えてみます。

Linuxカーネルの内部は、築30年のオフィスビルの空調ダクトに似ています。ビルの外側（アプリケーション層）はリフォームが進み、内装は最新に見えます。しかし天井裏には、20年前に張り巡らされた古い配管が、いまも現役で動いています。図面を読める設備技師は減り、長く誰も検査していなかった——そんな状態です。

2026年に入って、ようやくサーモグラフィー（syzkallerのような新世代のファジングツール）と新人技師（AI支援の解析）が天井裏に入りました。すると4月29日、まず1本の配管に亀裂が見つかります（Copy Fail）。1週間後、別フロアで類似の配管が裂けます（Dirty Frag）。さらにその1週間後、別の階の隣接配管が破裂します（Fragnesia）。亀裂の場所は別々ですが、いずれも「20年前の同じ設計思想で施工された配管」です。

破裂した個別の配管を直しても、同じ設計の配管はビル全体に張り巡らされています。第4・第5の破裂は、近いうちに別の階で起きます。やるべきことは2つです。破裂した配管をいち早く塞ぐこと（パッチ適用）。そして、必要のないフロアでは元栓を閉めて配管系統そのものから切り離すこと（モジュール無効化）。これを並行して進めるのが、運用者の仕事になります。

運用者がやるべきこと——古層対策を加えた多層遮断フレーム

Copy Failの記事では、パッチ・モジュール無効化・ユーザー権限削減・監視強化の4層を提案しました。今回はそこに「古層遮断」という考え方を1層追加します。

第1層：パッチを当てる（最優先）

主要ディストリビューションは既に対応を始めています。AlmaLinuxはテストリポジトリで5月13日中にパッチ提供を始め、Ubuntu・CloudLinuxも同様です。2026年5月14日以降のビルドであれば、Fragnesiaの修正が含まれています。Copy FailとDirty Fragのパッチを当て終えていても、Fragnesiaは別バグなので新たな再起動が必要です。

第2層：使っていないIPsec関連モジュールを無効化（即効性あり）

パッチが間に合わない場合、もしくはパッチ後の保険として、攻撃に使われるカーネルモジュールを/etc/modprobe.d/でブラックリスト化します。対象はesp4、esp6、rxrpcの3つ。Dirty Fragの対策で既に無効化済みであれば、Fragnesiaの公開PoCも防げます。一般的なWebサーバー・データベースサーバーではこれらを使っていないケースがほとんどで、無効化しても支障は出ません。逆にVPNゲートウェイなどIPsecを業務で使うサーバーは、第1層のパッチ適用を最優先にしてください。

第3層：ユーザー名前空間とseccompの制限

攻撃の出発点は「サーバーにログインできる一般ユーザー権限」です。unprivileged user namespaces（一般ユーザーが新しい権限空間を作る機能）を無効化することで、攻撃が利用できる経路を狭められます。kernel.unprivileged_userns_clone=0をsysctlで設定します。コンテナ環境ではseccompフィルタで該当のシステムコールを制限する方法もあります。

第4層：監視強化——「ファイルは無傷」を疑う

3本のバグに共通する厄介な特徴は、ディスク上のファイルは一切変更されない点です。通常のファイル改ざん検知では引っかかりません。代わりに、メモリ上の異常な書き込みパターンをeBPF（カーネル内で動く監視機構）で検知する、suid binaryの実行ログをsyslogに集約する、不自然なrootシェル取得を監視する——という運用が必要です。

第5層：古層遮断——使わないサブシステムは元栓を閉める

今回の3連発が示したのは、「20年前の設計が残っているサブシステムは、これからも順番にバグが見つかる」という事実です。サーバーの用途に対して使っていないカーネルサブシステムは、起動時にロードしない設定（/etc/modprobe.d/blacklist.conf等）に入れておくと、将来の同型脆弱性に対しても先回りで防御できます。IPsecを使わない多くのサーバーで、esp4・esp6・rxrpc・xfrm関連モジュールをまとめて無効化しておく運用は、現実的な選択肢です。

第4・第5の備えと、編集部の追跡

実際にFragnesiaは攻撃されているのか。本記事執筆時点では、完全武器化された攻撃の確認はまだありません。ただしGreyNoiseのIPテレメトリでは、XFRM関連のnetlinkプローブの微増が観測され始めました。Hacker News・Reddit（r/netsec）・X上では研究者によるPoC断片が浮上しており、コードのコピー＆ペーストで動くものへの加工も時間の問題と見られます。

脅威の温度感を3段階で言うなら、黄信号（武器化前夜）です。赤（実被害が多発）には届いていませんが、青（理論段階）でもありません。「今夜から明日朝にかけて手を打たないと、踏まれる確率が日ごとに上がる」段階だと、編集部は判断しています。Copy FailのCISA KEV期限が翌5月15日に迫っている時間圧力も、これに重なります。

Fragnesia公開と同時に、Linuxカーネルメーリングリストでは関連サブシステムの精査が始まっています。syzkallerのレポート、kernel.orgのコミット履歴、torvalds/linuxのissueに、ESP系・XFRM系・暗号系のクラッシュ報告が並びます。「次」が出るかどうかではなく、「次」がいつ・どこで出るかという段階です。

運用者向けに、現時点でやれることをまとめます。Copy Fail・Dirty Frag・Fragnesiaの3本のパッチを当て、IPsec系モジュールを業務要件に応じて整理し、ユーザー名前空間の権限制限を入れる。そして、ベンダー（Red Hat、Ubuntu、SUSE等）のセキュリティ通知を受け取る経路を整えておく。今後の数週間は、これを基本姿勢にしておくのが安全です。

既にroot奪取のPoCが流通している以上、攻撃のハードルは限りなく低くなりました。サプライチェーン攻撃の系譜でも見てきた通り、攻撃者は「動くものはすぐ使う」傾向があります。クラウド共用環境、CI/CDランナー、共有開発サーバー、コンテナホスト——多くの一般ユーザー権限が混在する場所ほど、優先度は上がります。

本記事は「Linuxカーネル脆弱性連鎖シリーズ」の第3報です。系譜の続報は本サイトで継続追跡中です。

参照元

• ▸NVD - CVE-2026-46300 Detail（米国国立標準技術研究所）
• ▸CloudLinux Blog - Fragnesia (CVE-2026-46300) Mitigation and Kernel Update（2026年5月13日）
• ▸TuxCare - Fragnesia (CVE-2026-46300): A New Linux Kernel LPE（2026年5月13日）
• ▸Wiz Blog - Fragnesia: Linux Kernel LPE via ESP-in-TCP（2026年5月13日）
• ▸AlmaLinux - Fragnesia (CVE-2026-46300): Patched kernels available in testing（2026年5月13日）
• ▸Ubuntu Security - CVE-2026-46300
• ▸Phoronix - Fragnesia Made Public As Latest Linux LPE Vulnerability（2026年5月13日）
• ▸Cybersecurity News - Fragnesia Linux Vulnerability Let Attackers Gain Root Privileges - PoC Released（2026年5月13日）
• ▸Gotekky - Fragnesia (CVE-2026-46300): The Third Linux Kernel Root Exploit in Three Weeks（2026年5月13日）
• ▸Microsoft Security Blog - Active attack: Dirty Frag Linux vulnerability expands post-compromise risk（2026年5月8日）
• ▸Tenable - Dirty Frag Linux Kernel LPE FAQ
• ▸Wiz Blog - Dirty Frag (CVE-2026-43284) Linux Privilege Escalation
• ▸本サイト - Linux『Copy Fail』脆弱性、世界のサーバー乗っ取りの恐れ。期限まで3日（2026年5月12日）