トップ/記事一覧/Linuxカーネルの脆弱性『Fragnesia』とは。対象バージョンと対策まとめ
linux-fragnesia-cve-2026-46300-cover-ja

Linuxカーネルの脆弱性『Fragnesia』とは。対象バージョンと対策まとめ

Linuxカーネルの新たな権限昇格脆弱性『Fragnesia』(CVE-2026-46300)が5月13日に公開。Copy Fail・Dirty Fragに続き3週間で3度目のroot奪取バグ。XFRM ESP系の古い設計が一斉に剥がれ始めた構造を、運用者向け5層遮断フレームで解説。

ニュース2026年5月14日公開 3日前更新
目次
この記事のポイント

Linuxカーネルの新たな権限昇格脆弱性『Fragnesia』(CVE-2026-46300)が5月13日に公開。Copy Fail・Dirty Fragに続き3週間で3度目のroot奪取バグ。XFRM ESP系の古い設計が一斉に剥がれ始めた構造を、運用者向け5層遮断フレームで解説。

Linuxカーネルには、CVE-2026-46300、通称「Fragnesia(フラグネシア)」と呼ばれる脆弱性(情報セキュリティ上の欠陥)があります。ネットワーク通信を暗号化するIPsec処理(XFRM ESP-in-TCP)の内側に穴があり、サーバーにログインできる一般ユーザーが、管理者権限(root、システムを何でも操作できる最上位の権限)を奪えるタイプの弱点です。対象は2026年5月13日に投入された修正より前のカーネルで、現在配布されているUbuntu・RHEL・AlmaLinux・Debian・SUSE・Amazon Linuxなど主要なLinuxはすべて修正済みです。カーネルを普通に更新して再起動していれば、追加の対応は要りません。

修正は上流(Linuxカーネル本体)に「net: skbuff: preserve shared-frag marker during coalescing」というパッチとして2026年5月13日に入り、同日以降に各社が配布を進めました。逆に言えば、5月13日より前にビルドされたまま更新していないカーネル——自前ビルドのLinux、しばらく再起動していないEC2・GCE・Azure VM、社内Jenkinsや踏み台サーバー、Dockerホストなど——はいまも穴が開いたままです。攻撃に必要なのはログインできる一般ユーザー権限だけで、パスワードの追加入力や特別な設定は要りません。公開と同時に動く攻撃コード(PoC、攻撃を再現する実証プログラム)が出回っており、Ubuntu上での動作も確認されています。

公開から約2ヶ月が経った2026年7月23日時点でも、この穴が「実際に攻撃で悪用された」という確かな報告は確認されていません。ただし手口は公開済みで、母数が全Linuxサーバーと極めて大きいため、古いまま放置していい理由にはなりません。

安全なバージョンはどれか——ディストリ別の対処状況

Fragnesiaは2026年5月13日の修正より前のカーネルが対象で、それ以降のビルドには修正が入っています。2026年7月23日時点で配布されている各系列のカーネル(kernel.orgのstable 7.1.4、長期サポート版の6.18.39 / 6.12.96 / 6.6.144 / 6.1.177 / 5.15.211 / 5.10.260など)は、いずれもFragnesia修正済みです。

ディストリビューション修正が入ったカーネル状態
Ubuntu 26.047.0.0-22.22 以降修正済み
Ubuntu 25.106.17.0-35.35 以降修正済み
Ubuntu 24.046.8.0-124.124 以降修正済み
Ubuntu 22.045.15.0-181.191 以降修正済み
Ubuntu 20.04 / 18.04影響なし
(対象外)
RHEL / AlmaLinux
Debian / SUSE
Amazon Linux
各社の最新カーネル修正済み
(配布完了)

確認方法はシンプルです。uname -rで動いているカーネルの版を確認し、パッケージ管理(Ubuntu/Debianならapt、RHEL系ならdnf)で更新してから再起動します。カーネルの更新は再起動して初めて反映されるため、更新だけして再起動していないサーバーは、まだ古いカーネルで動いている点に注意してください。Ubuntuのセキュリティ情報(2026年7月20日更新)や、AlmaLinuxの案内に、各系列の修正版番号がまとまっています。なお、AWSのBottlerocket、Google KubernetesのCOS(Container-Optimized OS)、AzureのCBL-Marinerのようにクラウド事業者がパッチ配布まで面倒を見るマネージドOSは、公開後の自動アップデートで既に修正が行き渡っています。

この穴を、どんな人が、何のために狙うのか

Fragnesiaを欲しがるのは、漠然としたハッカー集団ではなく、先行するCopy Fail・Dirty Fragで既に同じ手筋を回している商売人たちです。クラウドVPSの共用環境で非rootシェルを買って隣のテナントの本番DBへ足を伸ばすランサムウェア運営、ライバル企業からソースコード・顧客名簿・営業資料を抜きたい産業スパイ、Webアプリの脆弱性で取った非rootシェルからroot昇格の踏み台を探す標的型攻撃者、root化したLinuxを束で他のグループに転売する初期アクセスブローカー(IAB)が、そのまま流用先になります。彼らがroot権限で取りに来るのは、/etc/shadowのパスワードハッシュ、SSH秘密鍵、本番DBのアクセス情報、Kubernetesのサービスアカウントトークン、AWS IAMロールの一時クレデンシャル、そして本番DBの顧客レコードです。サーバにログインできる一般ユーザのシェルが1個あれば、Fragnesia1発でroot権限まで地続きに繋がります。しかも書き換わるのはメモリ上の/usr/bin/suだけで、ディスク上のファイルは無傷のまま。AIDEやTripwireのファイル改ざん検知は通常通り「変更なし」と返事をします。

セキュリティ用語ではこれをカーネルレベルの「ローカル権限昇格(LPE、手元の低い権限から管理者権限へ上がる攻撃)」と呼びます。最初からrootである必要は当然なく、Webアプリ経由の非rootシェル、レンタルVPSの自分のテナント、開発者の踏み台SSHアカウント――どれか1段下の足場さえあれば、そこから一段上のrootまで階段を1段で上がれます。root取得後の挙動は定型化済みです。systemdユニットとしてのバックドア常駐、/etc/sudoers.d/への細工ファイル設置、~/.ssh/authorized_keysへの自分用鍵追加、auth.logとwtmpの書き換えによる痕跡消去。Kubernetesノードならクラスタ全体、コンテナホストなら同居テナント全社、Active Directory連携サーバなら社内全Windows端末まで、影響は侵入された1台を大きく超えます。ディスク上に証跡が残らない設計のため、攻撃成立後も「何も起きていない」見た目が続きます。

CVSS(脆弱性の深刻度を10点満点で表すスコア)7.8 はあくまでローカル攻撃前提の目盛りであって、Linuxサーバを運用する事業者が現実に向き合っているのは1台のroot喪失ではありません。Fragnesiaと同じ型のバグがその後も次々と見つかり、同じ場所を踏み抜き続けているという状況そのものです。だからこそ、未更新のサーバーを1台残さないことが、顧客データと社内ネットワークの信頼を守れるかどうかの分かれ目になります。

Fragnesiaは何が起きるのか

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

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

この目印は「このメモリの断片は、カーネルが独占しているのではなく、外(ファイルのページキャッシュなど)から持ち込まれた共有領域だぞ」という注意書きです。注意書きが消えるとどうなるか。カーネルが「自分のメモリ」だと思って書き込んだ場所が、実は読み取り専用ファイルのメモリ上のコピーだった、という事故が起きます。5月13日の修正パッチは、この目印を寄せ集めのあとも引き継ぐようにして穴を塞いでいます。

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

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

なぜ同じ型のバグが立て続けに出たのか

Fragnesiaは、2026年春に3週間で立て続けに公開された同型バグの3本目でした。「偶然続いただけ」と考えたくなりますが、構造を見るとそうではありません。3本のバグには共通点があります。

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

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

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

記事公開時、私たちは「第4・第5の同種の脆弱性が近いうちに来る」と書きました。その予想は当たりました。公開から2ヶ月のあいだに、クローンされたネットワークパケットでファイル由来のメモリを壊すDirtyClone(CVE-2026-43503、6月)pedit COW(CVE-2026-46331、6月)、2011年から潜んでいて公開エクスプロイトで約5秒でrootが取れるGhostLock(CVE-2026-43499、7月)、XFSファイルシステムの競合を突くRefluXFS(CVE-2026-64600、7月22日)などが相次いで公開されています。古い設計が一斉に検査台に乗せられている、という見立てはそのまま現実になりました。

連発したLinuxカーネル脆弱性の系譜

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

名称CVE公開日バグの場所
PwnKitCVE-2021-40342022年1月polkit(権限管理)
Dirty PipeCVE-2022-08472022年3月カーネル内のパイプ機構
Looney TunablesCVE-2023-49112023年10月glibc(動的リンカ)
Copy FailCVE-2026-314312026年4月29日カーネル暗号窓口(AF_ALG)
Dirty FragCVE-2026-43284 ほか2026年5月7日IPsec ESP / RxRPC
FragnesiaCVE-2026-463002026年5月13日IPsec ESP / socket buffer
DirtyCloneCVE-2026-435032026年6月ネットワークパケット複製
GhostLockCVE-2026-434992026年7月2011年からの潜伏バグ
RefluXFSCVE-2026-646002026年7月22日XFS(ファイルシステム)

PwnKitからLooney Tunablesまでは1〜2年に1度の頻度でした。それがCopy Fail以降、2週間に1本のペースに加速し、その後もDirtyClone・pedit COW・GhostLock・Januscape(CVE-2026-53359)・RefluXFSと途切れずに続いています。バグの所在は権限管理ツール、パイプ、ライブラリ、暗号窓口、IPsec、ファイルシステムと一見バラバラですが、運用者から見ると影響は同型です。「Linuxを使っている限り、ほぼ全部のサーバーで管理者権限を奪われ得る」という現実が、2026年春から繰り返され続けています。

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

未更新のサーバーで起きうること

修正が配布されたいま、危険が残るのは更新していないサーバーだけです。ここで線引きになるのは「マネージドOSか、自前で管理しているLinuxか」です。AWSのBottlerocket、Google KubernetesのCOS、AzureのCBL-Marinerのようにクラウド事業者がパッチ配布まで面倒を見るマネージドOSは、公開後の自動アップデートで既に修正が行き渡っています。一方、自前ビルドのLinux、ユーザーが直接管理しているEC2 / GCE / Azure VM、社内Jenkinsホスト、self-hostedのGitHub Actionsランナー、Dockerホスト群——これらは更新と再起動を自分でやらない限り、生身のままです。攻撃者が狙うのは、まさにこの後者の層です。

該当する場合想定される業務影響物理感覚で言うと
EC2やVMでECサイトを動かしている管理画面が乗っ取られ、
顧客DBが静かに吸い出される
真夜中に商店街の店主の知らぬ間に
レジの中身が抜かれ、朝の棚卸しで初めて気づく
self-hosted のGitHub Actionsランナーを
運用している
CIシークレットが流出し、
デプロイ済みコードが書き換えられる
印刷所に渡したはずの原稿が、
刷られる前にこっそり差し替えられて世に出る
社内Jenkinsや踏み台サーバーがある侵入の足場として横展開され、
社内ネットワーク全体が射程に入る
ビル裏口の合鍵が複製され、
全フロアの執務室を夜な夜な回遊される
自前ビルドのKubernetesクラスタを
運用している
ノードのリソースが暗号資産マイニングに
勝手に転用され、応答が鈍る
店の照明が突然暗くなり、
レジが反応せず、客が黙って帰っていく
個人情報を扱うサービスを
Linux上で運用している
侵害報告義務・損害賠償・
個人情報保護委員会対応の範囲
会社の金庫の暗証番号が、
もう闇市場の値札に貼られている

いずれも「サーバーにログインできる一般ユーザー権限」を出発点とします。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シェル取得イベントが該当します。読者の方が担うべきは「自社の責任範囲を自覚すること」までで、系譜全体の継続観測は本サイトの編集部が引き受けます。

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 FAQWizの技術解説が要点をまとめています。

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

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

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

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

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

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

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

第1層:パッチを当てる(最優先)

主要ディストリビューションのパッチ配布は既に完了しています。UbuntuAlmaLinux・RHEL・Debian・SUSE・Amazon Linux・CloudLinuxのいずれも、2026年7月23日時点で修正版を提供済みです。具体的なバージョンは前掲の「安全なバージョンはどれか」の表を参照してください。aptdnfで更新し、再起動すれば適用完了です。Copy FailとDirty Fragのパッチを当て終えていても、Fragnesiaは別バグなので新たな再起動が必要な点に注意してください。

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

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

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

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

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

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

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

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

いまの危険度と、続く脆弱性への備え

実際にFragnesiaは攻撃されているのか。公開から約2ヶ月が経った2026年7月23日時点でも、実際の攻撃で悪用されたという確かな報告は確認されていません。PoCは公開済みでUbuntu上での動作も確認されていますが、in-the-wild(実環境)での悪用の証拠はないとする見方が大勢です(TenableのFAQ)。一部に「攻撃で悪用されている」と見出しで主張する記事もありますが、本文に裏付けとなる根拠は示されていません。

米国の政府機関CISAが「実際に攻撃に使われている脆弱性」をまとめたKEVカタログにも、Fragnesia(CVE-2026-46300)とDirty Frag(CVE-2026-43284 / 43500)は2026年7月23日時点で登録されていません。同じ系譜のなかでKEVに載っているのは先頭のCopy Fail(CVE-2026-31431)だけで、その修正期限(2026年5月15日)は既に過ぎています。日本国内でも、JPCERT/CC(日本のセキュリティ情報を取りまとめている公的機関)がWeekly Report(2026年5月20日号)でFragnesiaに触れ、PoC公開とベンダーパッチ適用を呼びかけています。

過度に恐れる必要はありませんが、放置していい理由にもなりません。攻撃には「サーバーにログインできる一般ユーザー権限」という前提が要るため、何もしていないのに勝手に乗っ取られるタイプではありません。一方で、root奪取のPoCが流通している以上、その前提さえ満たせば攻撃のハードルは限りなく低くなっています。サプライチェーン攻撃の系譜でも見てきた通り、攻撃者は「動くものはすぐ使う」傾向があります。クラウド共用環境、CI/CDランナー、共有開発サーバー、コンテナホスト——多くの一般ユーザー権限が混在する場所ほど、更新の優先度は上がります。

Copy Fail・Dirty Frag・Fragnesiaの3本を含む最新カーネルを当てて再起動する。IPsec系モジュールを業務要件に応じて整理する。ユーザー名前空間の権限制限を入れる。そして、ベンダー(Red HatUbuntuSUSE等)のセキュリティ通知を受け取る経路を整えておく。DirtyCloneやRefluXFSのように同型のバグはその後も出続けているため、これを恒常的な基本姿勢にしておくのが安全です。

本記事は「Linuxカーネル脆弱性連鎖シリーズ」の1本です。系譜の続きは本サイトで継続追跡しています。

よくある質問

Q. 自分のサーバーがFragnesiaの対象か、どう確認すればいいですか。

uname -rで動作中のカーネル版を確認し、前掲の表と照らし合わせてください。2026年5月13日の修正より前のカーネルが対象で、それ以降のビルドは修正済みです。Ubuntuなら24.04で6.8.0-124.124以降、22.04で5.15.0-181.191以降なら対処不要。更新後に再起動していない場合はまだ古いカーネルで動いているので、再起動まで済ませてください。

Q. すでに攻撃に使われていますか。

2026年7月23日時点で、実際の攻撃で悪用されたという確かな報告は確認されていません。米CISAのKEVカタログにも未登録です。ただしPoC(攻撃を再現する実証プログラム)は公開済みで、Ubuntu上での動作も確認されているため、古いカーネルを放置するのは安全ではありません。

Q. IPsecやVPNを使っていなければ関係ないですか。

IPsecを業務で使っていないサーバーは、esp4esp6rxrpcモジュールを無効化しておけば公開PoCを防げます。ただしこれは応急策で、根本的にはカーネルを最新に更新して再起動するのが確実です。VPNゲートウェイなどIPsecを実際に使うサーバーは、モジュール無効化ではなくパッチ適用を最優先にしてください。

Q. Copy FailやDirty Fragのパッチを当てていればFragnesiaも防げますか。

いいえ。3本は攻撃面が近い別々のバグで、Fragnesiaには専用の修正(2026年5月13日投入)が必要です。Copy Fail・Dirty Fragを当てた後でも、Fragnesia修正を含む新しいカーネルへ更新し、再起動してください。

参照元

avatar-m-1

堀川 慎

Backend Engineer / AWS / Django / Go