セキュリティ動向 on KnightLiブログ

AI脆弱性発見の時代が来た：Copy Fail、Dirty Frag、Fragnesia、ssh-keysign-pwnはなぜ集中発生したのか

Thu, 21 May 2026 09:30:01 +0800

最近、Linuxカーネル関連の脆弱性が相次いでいます。Copy Fail、Dirty Frag、Fragnesia、ssh-keysign-pwnが次々にセキュリティ界隈で議論されました。ローカル権限昇格につながるものもあれば、高感度ファイルを漏えいさせるもの、コンテナホストやマルチテナント環境に影響するものもあります。多くの人の第一印象は、「Linuxはなぜ急にここまで危なくなったのか」というものです。

より正確に言えば、Linuxが突然悪くなったわけではありません。長く隠れていた問題が、より速く、より体系的に掘り出されるようになったのです。

今回の波で本当に注目すべきなのは、いくつかのCVE修正だけではありません。脆弱性の発見方法が変わったことです。以前は、少数のトップ研究者が長い時間をかけて、サブシステムをまたぐロジックバグをつなぎ合わせる必要がありました。今では、AI支援監査、自動静的解析、fuzzing、セキュリティ研究プラットフォームがその作業を大きく増幅しています。脆弱性が一夜にして増えたのではなく、発見、再現、拡散の速度が上がったのです。

これらの脆弱性に共通すること

まず、最近の事例を並べて見ます。

脆弱性	主な影響	重要な特徴	リスクの焦点
Copy Fail / CVE-2026-31431	ローカル権限昇格	Linux crypto / AF_ALG関連経路、page cache書き込み問題を含む	一般ユーザーからrootへ。特にコンテナ環境で敏感
Dirty Frag / CVE-2026-43284、CVE-2026-43500	ローカル権限昇格	XFRM/ESP、RxRPCなどの経路におけるpage cache書き込みプリミティブ	チェーン利用可能。ホストとコンテナ境界に影響
Fragnesia / CVE-2026-46300	ローカル権限昇格	XFRM ESP-in-TCPサブシステムのロジック問題	Dirty Fragに近い攻撃面
ssh-keysign-pwn / CVE-2026-46333	ローカルの機密情報漏えいと権限昇格リスク	Linux kernel `__ptrace_may_access()` のロジック欠陥	SSHホスト鍵、`/etc/shadow`などの機密ファイルリスク

これらは完全に同じ脆弱性ではありませんが、いくつかの共通点があります。

従来型のリモートRCEではなく、ローカル権限昇格またはローカル機密情報漏えいである。
攻撃者はまず通常のshell、コンテナ内のコマンド実行、CIタスク権限、低権限アカウントなど、何らかのローカル実行能力を持つ必要がある。
多くのリスクはカーネル境界に集中している。page cache、暗号/ネットワークサブシステム、ptrace権限判定、コンテナ共有カーネルなど。
コンテナは強い安全境界ではなく、ホストカーネルが共通基盤であるため、現代のクラウドネイティブ環境では影響範囲が拡大する。

したがって問題は「パッチがあるか」だけではありません。より深い問題は、なぜこのような低レベルで隠れた、長く潜伏していた問題が短期間に集中して現れたのかです。

第一の理由：多くの脆弱性は新しく書かれたものではなく歴史的負債

脆弱性の公開日を見ると、そのバグが最近のバージョンで入ったものだと思いがちです。しかし実際には、そうでないことが多いです。

Copy Failのような問題の重要点は、脆弱性が何年も潜伏し得ることです。正しい呼び出し経路、権限境界、メモリセマンティクスを誰かがつなげて初めて見つかります。公開情報では、Copy Failは2017年前後のカーネル最適化の歴史と関係があるとされています。Dirty FragやFragnesiaも、ネットワーク、暗号、page cacheといった深い交差経路を指しています。

この種の脆弱性の怖さは、ある一行のコードが明らかに危険に見えることではありません。複数の前提がたまたま重なることにあります。

あるサブシステムが性能のためにインプレース処理を行う。
あるインターフェースが非特権ユーザーにカーネル機能へ到達させる。
ある経路が読み取り専用ファイルページ、page cache、ネットワーク断片、暗号バッファをつなぐ。
ある暗黙の制約が型システム、assert、ドキュメントに書かれていない。
最終的に、一般ユーザーが本来影響できないカーネル状態に影響する経路になる。

これは通常のコードレビューが最も得意とする問題ではありません。あるレビュー担当者はcryptoサブシステムを理解し、別の人はネットワークサブシステムを理解し、第三者はメモリ管理を理解しているかもしれません。しかし脆弱性はその交差点に隠れています。

第二の理由：Linuxカーネルの複雑性は人工レビューの限界を超えている

Linuxの強みは、オープンで汎用的で、幅広いハードウェアに対応し、エコシステムが強いことです。しかしそれらの強みは代償も伴います。

現代のLinuxカーネルは単なる「小さなカーネル」ではありません。スケジューリング、メモリ管理、ファイルシステム、ネットワークプロトコルスタック、暗号フレームワーク、ドライバ、仮想化、コンテナ関連機構、eBPF、LSM、セキュリティモジュール、ハードウェアプラットフォーム対応など大量のサブシステムを含みます。各サブシステムには歴史、メンテナ、性能目標、互換性の負債があります。

問題は、脆弱性が単一モジュール内ではなく、モジュール同士の交点に存在しがちなことです。

splice() はファイルページとpipeをつなぐ。
AF_ALGはユーザー空間とカーネルcrypto APIをつなぐ。
XFRM/ESPはネットワークパケット、暗号、メモリページをつなぐ。
RxRPCやESP-in-TCPのような経路はネットワークスタックをさらに複雑にする。
コンテナは低権限ローカル実行をより一般的な現実の前提にする。

エンジニアリングの観点では、Linuxカーネルはもはや「十分な目があれば全部見られる」規模ではありません。オープンソースは問題の修正と検証を容易にしますが、すべての隅が継続的かつ安全にレビューされることを意味しません。サブシステム横断の脆弱性を本当に理解できる人は少なく、そうした脆弱性ほど大きな影響を生みやすいのです。

第三の理由：性能最適化は安全境界を薄くしがち

今回の脆弱性群では、性能のためにコピーを減らし、バッファを再利用し、データをインプレース処理するというテーマが繰り返し出てきます。

この種の最適化は非常に合理的です。カーネルはインフラであり、少しの性能低下がクラウド事業者、データベース、ネットワーク、ストレージ、コンテナ基盤に影響します。コピーを一回減らす、暗号化/復号を速くする、メモリ割り当てを減らすことは、実運用で価値があります。

しかし安全上の代償も明確です。「読み取り専用データ」「共有ページ」「ユーザー制御入力」「カーネルバッファ」「暗号出力」の境界が薄くなると、あるサブシステムが入出力契約を誤解しただけで、不正な書き込みや読み取りにつながります。

つまり、性能最適化自体が悪いわけではありません。しかし、より壊れやすい組み合わせを作ります。

インプレース暗号化/復号はコピーを減らすが、入力/出力バッファの正しい隔離により強く依存する。
page cacheはファイルアクセス性能を高めるが、攻撃面にもなり得る。
ゼロコピーはスループットを高めるが、異なるサブシステムが同じメモリオブジェクトを共有する。
コンテナはデプロイ効率を高めるが、共有カーネルによりローカルLPEの爆発半径を大きくする。

安全境界は「みんながミスしないことを覚えている」だけでは維持できません。型、権限チェック、不変制約、テスト、fuzzing、継続監査によって強制される必要があります。そうでなければ、性能最適化と暗黙の仮定が増えるほど、脆弱性はいずれ掘り出されます。

第四の理由：コンテナがローカル脆弱性の価値を高めた

以前は「ローカル権限昇格」は、攻撃者がすでにローカルアクセスを必要とするため、リモート脆弱性より低リスクに見られがちでした。クラウドネイティブ時代はこの判断を変えました。

今日の「ローカル実行」の入口は多くあります。

Webアプリケーションが通常のshellを取られる。
CI/CDタスクが信頼できないコードを実行する。
コンテナ内でユーザーアップロードのタスクが走る。
マルチテナント平台がnotebook、プラグイン、スクリプト、ビルドタスクの実行を許す。
AIコード実行環境、サンドボックス、オンライン評価平台が増えている。

攻撃者がコンテナ内で実行能力を得ると、カーネルLPEはもはや「そのマシンだけの小問題」ではありません。コンテナはホストカーネルを共有するため、カーネル脆弱性はコンテナ境界を越え、ホストや他のテナントに影響し得ます。

これが、Copy FailやDirty Fragのような脆弱性がクラウド、セキュリティ、コンテナチームから強く注目される理由です。それらは「低権限ローカルコード実行」を「ホスト級リスク」に引き上げる可能性を高めます。

AIの影響：脆弱性発見コストが下がった

今回の波で最も時代性がある部分は、AI支援の脆弱性発見です。

Copy Failの公開資料では、TheoriのXint Codeが発見過程に関与したことが言及されています。具体的なツール能力がどうであれ、これは一つの傾向を示しています。AIは必ずしも脆弱性を「無から発明する」わけではありませんが、研究者が検索経路を短縮するのを非常に得意とします。

AIが脆弱性研究に与える影響は主に次の点にあります。

見慣れないコードをより速く読む
カーネルサブシステムのコード量は非常に大きく、研究者がすべての経路を手で読むことはできません。AIは関数、呼び出しチェーン、入出力関係、怪しいパターンを素早く要約できます。
モジュール横断の接続を見つけやすくする
多くの脆弱性は「ユーザー空間入口 -> ネットワークスタック -> 暗号フレームワーク -> メモリページ -> ファイルキャッシュ」のような連鎖に隠れています。AIはファイル、ディレクトリ、サブシステムをまたぐ経路整理を補助できます。
監査仮説を生成しやすくする
たとえば「どの経路がユーザー制御データをpage cacheに書くのか」「どのAPIが非特権ユーザーにcryptoサブシステムへ到達させるのか」「どの関数が入力と出力バッファは重ならないと仮定しているのか」。以前は経験で少しずつ考える問題でしたが、今はより体系的に列挙できます。
再現可能な例へ変えやすくする
AIはカーネル研究者の判断を代替できませんが、検証コード、PoCの整理、誤った経路の説明、テストケース生成を助けられます。

結果として、脆弱性発見の単位コストが下がります。

以前なら、高品質なカーネル脆弱性を発見するにはトップ研究者が長い時間を使う必要がありました。今は、システムを理解する人がAIツールを使えば、疑わしい経路をより速く絞り込めます。脆弱性供給の上限が上がり、集中公開が起きやすくなっています。

ただしAIだけが原因ではない

もう一つの極端、すべてをAIのせいにすることも避けるべきです。

AIは加速器であり、根本原因ではありません。根本原因は依然として次の通りです。

歴史的コードの長期蓄積。
性能最適化における暗黙契約が強制されていない。
サブシステム横断の複雑性が高すぎる。
デフォルトで露出するカーネル機能が多すぎる。
セキュリティテストがすべての組み合わせ経路を覆っていない。
コンテナ、マルチテナント、自動実行環境がローカル脆弱性の価値を高めた。

これらの基盤条件がなければ、どれほど強いAIでもこれほど多くの高影響脆弱性を掘り出すことはできません。逆に、これらの条件が存在する限り、AIが成熟するほど、脆弱性はより体系的に見つかりやすくなります。

防御側にとっての意味

運用、セキュリティ、プラットフォームチームにとって、今回の波には直接的な示唆があります。

第一に、「ローカル権限昇格」を低優先度として扱わないこと。
環境にコンテナ、CI、オンライン実行、プラグイン、notebook、マルチテナントタスクがあるなら、ローカル権限昇格はホストリスクになり得ます。

第二に、カーネルパッチのペースを上げること。
重要なホスト、Kubernetesノード、CI Runner、AIサンドボックス、仮想化ホストを古いカーネルに長期間置くべきではありません。カーネル更新、再起動ウィンドウ、live patch、段階的ロールバックの明確なプロセスが必要です。

第三に、不要なカーネル攻撃面を減らすこと。
不要なプロトコル、モジュール、ユーザー名前空間、特殊socket、デバッグインターフェースは、業務要件に応じて絞るべきです。デフォルトで有効であることは、デフォルトで露出すべきことを意味しません。

第四に、コンテナセキュリティではカーネルが破られる可能性を前提にすること。
コンテナ内でnon-rootを使い、capabilitiesを最小化し、seccomp、AppArmor/SELinux、読み取り専用ファイルシステム、機密マウントの隔離を使うことは今も重要です。すべてのカーネル脆弱性を止められるとは限りませんが、前提条件と後続被害を減らせます。

第五に、監視では権限昇格チェーンに注目すること。
リモート入口だけでなく、異常プロセス、機密ファイル読み取り、カーネルモジュール読み込み、コンテナ脱出兆候、CI Runner異常、/etc/shadow、SSH host keyなど高価値ファイルへのアクセスを見る必要があります。

オープンソースコミュニティにとっての意味

Linuxコミュニティや大規模オープンソースプロジェクトにとって、AIによる脆弱性発見は二重の圧力をもたらします。

一方で、AIは防御側が古い問題をより速く見つける助けになります。より多くの潜伏脆弱性が公開修正されることは、長期的には良いことです。

他方で、AIはノイズも生みます。低品質な自動報告、誤検知、重複報告、文脈のない「AIがbugを見つけた」という主張は、メンテナの時間を消耗します。本当の課題は「AIを使うか」ではなく、AIの出力を責任あるセキュリティプロセスへどう組み込むかです。

報告には最小再現が必要。
影響範囲と脅威モデルを明確にする必要がある。
理論上の問題、発火可能なbug、悪用可能な脆弱性を区別する必要がある。
embargo、ディストリビューション調整、修正ウィンドウを尊重する必要がある。
メンテナにはより良い自動テスト、fuzzing、静的解析、回帰検証が必要。

AIは脆弱性発見を速くします。同時に、修復と調整の仕組みもより成熟する必要があります。そうでなければ、セキュリティ研究の生産性向上は、メンテナの負担とユーザーの不安に変わります。

結論：神話崩壊ではなく、セキュリティ現実が変わった

Linuxは今も、主流OSインフラの中で最も透明で、制御可能で、修復と強化が可能な基盤の一つです。問題はLinuxが突然「安全でなくなった」ことではありません。現代カーネルの複雑性、クラウドネイティブな使われ方、AI支援の脆弱性発見が、脆弱性露出の速度を変えていることです。

今後も似た事件は起きる可能性が高いでしょう。毎回新しい災害が起きているからではなく、過去に蓄積された複雑な経路が、より高効率に探索されるようになったからです。

本当に変えるべきなのは、私たちの安全仮定です。

「脆弱性が公開されていない」を「脆弱性がない」と見なさない。
「ローカル権限昇格」を低リスクと見なさない。
「コンテナ隔離」を強い安全境界と見なさない。
数千万行級のシステムソフトウェアを人工レビューだけで守れると思わない。
パッチを待つだけでなく、攻撃面を縮小し、パッチ速度を上げ、多層防御を作る。

AIは脆弱性発見を高い生産能力の時代へ押し出しました。攻撃者にとっても、防御者にとっても同じです。違いは、防御側がこの能力をより速い監査、より早い修正、より安定したインフラ治理へ変えられるかどうかです。

参考資料

最近の Linux ローカル脆弱性 4 件の影響整理：Copy Fail、Dirty Frag、Fragnesia、ssh-keysign-pwn

Wed, 20 May 2026 23:00:37 +0800

最近、Linux エコシステムでは注目度の高いローカルセキュリティ問題が相次いでいる。個別に見ると、暗号インターフェース、ネットワーク/IPsec 経路、ページキャッシュ処理、ptrace アクセスチェックなど、発生箇所は異なる。だがまとめて見ると、運用上の教訓は同じだ。攻撃者が低権限のローカル実行点を得た時点で、Linux ホスト、コンテナノード、CI マシン、マルチユーザーサーバーのリスクは大きく増える。

この記事では各脆弱性の技術詳細を繰り返さず、実環境への影響を整理し、詳しい解説としてサイト内の 4 本の記事へリンクする。

4 つの問題は何に影響するのか

最近特に追うべきリスクは次の 4 つだ。

Copy Fail（CVE-2026-31431）：低権限のローカルユーザーがカーネル暗号関連経路を通じてページキャッシュに影響し、権限を拡大する可能性がある。
Dirty Frag（CVE-2026-43284 / CVE-2026-43500 関連）：xfrm/ESP、RxRPC などのネットワークおよびカーネルデータ経路にリスクが集中し、侵害後の段階で危険性が高い。
Fragnesia（CVE-2026-46300）：Dirty Frag に近く、XFRM ESP-in-TCP、共有 fragment、ページキャッシュ書き込みリスクをめぐる問題。
ssh-keysign-pwn（CVE-2026-46333）：直接 root shell を得るタイプではなく、SSH ホスト秘密鍵や /etc/shadow などを読まれる可能性があるローカル情報漏えいリスク。

この 4 種類は入口が異なり、緩和策も完全には同じではない。Copy Fail を処理したから Dirty Frag と Fragnesia も安全とは言えない。ネットワークモジュールの一部を無効化したから ssh-keysign-pwn の情報漏えいリスクが消えるわけでもない。

Copy Fail：コンテナと CI ノードの優先度が高い

Copy Fail の重要な影響は「アプリが落ちる」ことではなく、低権限の実行能力が root 権限に変わる可能性があることだ。特に影響が大きいのは次の環境である。

ユーザーがコードをアップロードまたは実行できる CI/CD ノード。
信頼できないワークロードを動かすコンテナホスト。
開発・テスト機、踏み台、共有サーバー。
古いカーネルを使い、パッチ適用の遅いクラウドホスト。

Copy Fail が危険なのは、攻撃のハードルが比較的低く、コンテナ環境と重なりやすいためだ。多くのチームはコンテナを強い隔離境界のように扱うが、通常のコンテナはデフォルトでホストカーネルを共有している。攻撃者がコンテナ内で shell を得られるなら、カーネル LPE によってコンテナ内の問題がホスト全体の問題に拡大する可能性がある。

詳細解説：Copy Fail CVE-2026-31431：Linux カーネルのファイルコピー経路におけるコンテナエスケープリスク。

Dirty Frag：侵害後の権限拡大装置

Dirty Frag は、攻撃者がシステムに入った後の権限拡大ツールに近い。典型的なリモート未認証脆弱性ではなく、通常は弱いパスワード、WebShell、低権限サービスアカウント、コンテナタスクなどを通じて、すでにローカル実行能力を得ていることが前提になる。

実際の影響は主に次の通りだ。

侵害済みの低権限アカウントが root になる可能性がある。
コンテナ内の低権限実行点がホストを脅かす可能性がある。
IPsec、ESP、RxRPC、関連するカーネルネットワーク機能を使うシステムは、パッチと一時緩和を慎重に評価する必要がある。
セキュリティチームは境界防御だけでなく、侵害後の権限昇格チェーンも見る必要がある。

Dirty Frag は、ローカル権限昇格が最初の入口でなくても、侵入がどこまで広がるかを決め得ることを示している。低権限の足場があれば、攻撃者はカーネルバグを探して最高権限へ進もうとする。

詳細解説：Dirty Frag CVE-2026-43284：Linux ローカル権限昇格のリスクと緩和ガイド。

Fragnesia：同系統の攻撃面は一度では片付かない

Fragnesia が重要なのは、Dirty Frag 周辺の攻撃面が単発の孤立した問題ではないことを示している点だ。あるバグが修正されても、隣接経路、似たデータ構造、関連モジュールの組み合わせに新しい利用可能な点が残る可能性がある。

運用への影響は主に次の通りだ。

脆弱性名だけで一度きりの対応をするのではなく、攻撃面として継続的に確認する。
esp4、esp6、rxrpc、XFRM、ESP-in-TCP などの関連経路を、実際の業務依存と照らして評価する。
関連するネットワーク機能を使っていないなら一時的な無効化を検討できるが、VPN、IPsec、トンネル、内部ネットワークに影響しないか先にテストする必要がある。
ページキャッシュ汚染型のリスクは、ファイル自体は変わっていないように見えても実行経路が影響を受ける、という検知の盲点を作り得る。

企業にとって最大の教訓は、パッチ管理を単一 CVE だけで見ないことだ。より安全なのは、サブシステムと攻撃面を軸に棚卸しし、どのマシンが関連機能を露出しているのか、どの業務が本当にそのモジュールを必要としているのかを確認することだ。

詳細解説：Fragnesia (CVE-2026-46300)：Linux カーネルローカル権限昇格の影響と緩和。

ssh-keysign-pwn：直接 root でなくても危険

ssh-keysign-pwn は前の 3 件とは性質が異なる。直接 root shell を取る脆弱性ではなく、ローカルの機密情報漏えいに近い。しかし実際の攻撃では、機密情報の漏えいがより深刻な結果につながることが多い。

主な影響は次の通り。

SSH host private keys が漏えいすると、ホスト ID の信頼性に影響する可能性がある。
/etc/shadow などのファイルを読まれると、オフラインクラッキングやアカウント乗っ取りにつながる可能性がある。
マルチユーザーサーバー、踏み台、ビルドマシン、共有開発機のリスクが高い。
攻撃者がすぐに権限昇格しなくても、後続の横展開に使える認証情報を得る可能性がある。

この種の問題は、直接 root shell ほど派手ではないため過小評価されやすい。だが企業環境では、鍵やパスワードハッシュの漏えいは長い後処理を意味する。SSH ホスト鍵のローテーション、信頼関係の確認、アカウントパスワードの確認、ログインログ監査が必要になる可能性がある。

詳細解説：ssh-keysign-pwn（CVE-2026-46333）解説：Linux ローカル情報漏えい、SSH ホスト鍵、/etc/shadow のリスク。

共通の影響：コンテナ隔離を強い境界と見なせない

この 4 件を合わせると、最も直接的な影響は、通常のコンテナ隔離は仮想マシン隔離ではないという再確認だ。

Docker、containerd、Kubernetes は namespace、cgroup、capabilities、seccomp、AppArmor、SELinux などで攻撃面を減らすが、通常はホストカーネルを共有している。脆弱性が共有カーネルにあるなら、コンテナ内の低権限実行点が攻撃の入口になる。

高リスク環境では次を確認すべきだ。

信頼できないコードを共有ホスト上で実行していないか。
コンテナがデフォルトで root ユーザーとして動いていないか。
不要な capabilities を付与していないか。
seccomp ポリシーが広すぎないか。
マルチテナントワークロードを gVisor、Kata Containers、Firecracker microVM、専用 VM、専用ノードへ移すべきか。

CI/CD プラットフォームは特に注意が必要だ。ビルドジョブは外部コード、依存関係のインストールスクリプト、テストスクリプト、一時バイナリを自然に実行する。これらが長期稼働サービスとホストを共有している場合、1 つのローカル権限昇格が大きなインフラに波及する可能性がある。

共通の影響：パッチは「実行中のカーネル」まで届く必要がある

Linux カーネルのパッチ適用でよくある誤解は、パッケージがインストールされたことと、マシンが修正済みカーネルで動いていることを混同することだ。

運用では少なくとも 3 点を確認する。

`1`	`uname -a`

現在実行中のカーネルを確認する。

`1`	`dpkg -l \| grep linux-image`

RHEL 系ディストリビューションでは次のように確認する。

`1`	`rpm -qa \| grep kernel`

インストール済みカーネルパッケージを確認する。

最後に、マシンが修正済みカーネルで再起動済みかを確認する。すぐ再起動できない重要サービスでは livepatch、ホットパッチ、短期隔離を検討する。ただし一時緩和を最終修正と考えてはいけない。

共通の影響：攻撃面最小化はモジュールと syscall まで具体化する

今回の経路は、Linux の堅牢化が「更新する」「ファイアウォールを入れる」だけでは不十分であることを示している。

より具体的な確認項目は次の通り。

AF_ALG / algif_aead を業務で使っているか。
XFRM、ESP、ESP-in-TCP、IPsec が VPN、トンネル、セキュリティゲートウェイに必要か。
RxRPC が必要か。
非特権 user namespace を有効にする必要があるか。
コンテナが広すぎる socket タイプを作成できるか。
ptrace アクセスポリシーが緩すぎないか。

業務上不要な機能であれば、モジュール無効化、sysctl 調整、seccomp の強化、capabilities の削減を評価できる。本番環境にコマンドをそのまま貼り付けるのではなく、依存関係を棚卸しし、段階的に展開するべきだ。

推奨される対応順序

第一に、ローカルコード実行が露出している高リスクマシンを優先して修正する。

コンテナホスト。
CI/CD runner。
踏み台。
マルチユーザーサーバー。
外部公開サービスのホスト。
信頼できないプラグイン、スクリプト、拡張を動かすシステム。

第二に、ディストリビューションのアドバイザリと実際の実行中カーネルを確認する。上流のバージョン番号だけを見てはいけない。Debian、Ubuntu、RHEL、AlmaLinux、Rocky Linux、SUSE、openEuler などはセキュリティ修正を backport することがある。

第三に、コンテナ実行ポリシーを締める。非 root ユーザー、最小 capabilities、no-new-privileges、読み取り専用ファイルシステム、明示的な seccomp と AppArmor/SELinux ポリシーを優先する。

第四に、鍵と認証情報のリスクを確認する。特に ssh-keysign-pwn が関係する環境では、SSH host key、/etc/shadow、踏み台の認証情報、CI secrets のローテーションが必要か評価する。

第五に、監視を補う。異常な root shell、不審なローカル LPE PoC、重要ファイルの変更、異常な ptrace 動作、コンテナプロセスによるホストパスへのアクセス、CI ノードからの異常なネットワーク接続を重点的に見る。

結論

この 4 件の要点は「Linux が安全でなくなった」ではなく、「デフォルトの信頼だけでは足りなくなった」だ。

Linux は今も透明で、修正でき、切り詰められ、堅牢化できる主流システムである。しかしコンテナ、CI、マルチテナント、AI による自動コード実行が広がる環境では、低権限の実行点を小さな問題と見なせなくなっている。カーネルに利用可能なローカル権限昇格や機密情報漏えいのバグがあれば、局所的な侵入はホスト制御、認証情報漏えい、横展開につながり得る。

より現実的な対応は、この 4 件を警告として受け止めることだ。パッチを早く適用し、再起動済みカーネルを確認し、モジュールは必要なものだけ有効化し、コンテナを締め、鍵をローテーションできるようにし、マルチテナントの隔離レベルを再評価する。

サイト内の関連解説:

APT45 が AI で脆弱性を大量検証：ゼロデイ攻撃のハードルは下がっている

Sun, 17 May 2026 19:52:39 +0800

Google Threat Intelligence Group は 2026 年 5 月 11 日、新しい AI Threat Tracker を公開した。重要なのは「攻撃者が AI を使い始めた」ことだけではない。使い方が、文章作成、翻訳、偵察支援から、脆弱性研究、PoC 検証、マルウェア難読化、自動化された攻撃編成へ移っている点だ。

まず、混同しやすい二つの点を分けておきたい。

第一に、Google は AI の支援で開発されたとみられるゼロデイ exploit を初めて確認したと述べている。この事例は、名前が明かされていないサイバー犯罪グループによるものだ。対象は人気のあるオープンソースの Web ベース管理ツールで、有効な認証情報を持っている場合に 2FA を回避できる。Google は影響を受けるベンダーと協力して責任ある開示を進め、大規模悪用を防いだ可能性があるとしている。

第二に、APT45 はこのゼロデイ事例の帰属先ではない。GTIG は別件として、北朝鮮関連の APT45 が AI モデルに大量の反復プロンプトを送り、複数の CVE を再帰的に分析し、PoC exploit を検証していたと述べている。つまり APT45 は、AI を単なるフィッシングメール作成ツールではなく、脆弱性研究と exploit 武器庫の整理ツールとして使っている。

AI ゼロデイ事例が示すもの

このゼロデイは、典型的なメモリ破壊、入力検証ミス、単純な設定ミスではない。GTIG はこれを高レベルの意味論的ロジック欠陥として説明している。開発者が認証フロー内に信頼の前提をハードコードし、その結果、2FA enforcement ロジックと例外条件の間に矛盾が生じた。

この種の脆弱性は従来型スキャナーが苦手とする。静的解析や fuzzing は、クラッシュ、危険な sink、入出力経路、既知パターンの発見に強い。しかし「開発者が何を保証したかったのか」「どの例外がその保証を破っているのか」を理解するのは簡単ではない。

大規模言語モデルのリスクはそこにある。専門のセキュリティ研究者より強いとは限らないが、文脈を読み、意図を説明し、似たコード経路を比較し、業務ロジックの不整合を指摘することは得意だ。この能力が攻撃者の自動化フローに組み込まれると、熟練研究者が長時間かけて読む必要があったロジック脆弱性を、より大規模にふるい分けられる可能性がある。

GTIG は exploit コード内に AI 生成の痕跡も確認している。教育的な docstring、幻覚された CVSS スコア、教材のような Python 構造などだ。Google は Gemini が使われたとは考えていない一方で、攻撃者が何らかの AI モデルを使って脆弱性の発見と武器化を支援した可能性には高い信頼を置いている。

APT45 の変化は長期的に注目すべき

APT45 は、北朝鮮関連の脅威グループとして長く追跡されてきた。活動目的はスパイ活動、金銭獲得、戦略的情報収集にまたがる。今回 GTIG が強調したのは、APT45 の AI 利用方法だ。大量かつ反復的に CVE を分析し、PoC exploit を検証し、より信頼できる攻撃能力として蓄積している。

これは「AI に短いスクリプトを書かせる」話とは違う。

組織が AI を脆弱性の選別、PoC 検証、payload 調整、テスト環境に接続できるなら、人手のボトルネックは変わる。以前は、チームが同時に調査できる脆弱性の数は、研究者の人数、経験、時間に依存していた。今は、AI が反復的な読解、要約、変種テスト、初期判断の一部を担い、人間は標的選定、悪用可能性の確認、実運用への投入に集中できる。

防御側にとって、これは既知脆弱性の猶予期間が短くなることを意味する。

CVE が公開された後、攻撃者はアドバイザリを一から読み、パッチ diff を調べ、環境を作り、PoC を修正する必要がなくなる。AI は影響範囲の理解、テスト案の生成、失敗原因の調査、対象バージョン差分の整理を助ける。人間による修正が必要でも、全体の処理量は上がる。

これは「AI が何でも自動で侵入する」という話ではない

この件を、AI がすでに完全な侵入を単独で実行できる証拠と読む必要はない。

GTIG の報告が示すのは、攻撃チェーンの複数段階が AI によって加速しているということだ。脆弱性研究、マルウェア難読化、偵察、ソーシャルエンジニアリング、情報操作、モバイル UI 自動化、サプライチェーン汚染に AI の関与が見え始めている。

ただし AI はまだ失敗する。脆弱性を幻覚したり、悪用可能性を誤判定したり、動かないコードを生成したり、複雑な企業認可ロジックで迷ったりする。危険なのは AI が完璧なことではない。攻撃者が低コストで試行錯誤できることだ。大量試行が十分に安くなれば、誤った出力は捨てられ、使える出力だけが攻撃フローに入る。

APT45 のような事例が重要なのはこのためだ。国家級または国家に近い組織には標的も忍耐もある。AI が反復作業を減らせば、より高価値な標的に多くの資源を投じられる。

防御の焦点は「ゼロデイの有無」から「猶予期間の短さ」へ

多くの企業はこれまで、既知脆弱性はパッチ管理で、ゼロデイは多層防御で対応する、とリスクを分けてきた。AI が脆弱性研究に入ると、この境界は曖昧になる。

より現実的な問いは次の通りだ。

新しい CVE が公開された後、外部攻撃者が実用的な exploit を作るまでにどれくらいかかるか。
資産台帳は同じ日に影響を受けるシステムを答えられるか。
WAF、EDR、ログ、ID システムは異常な試行を検知できるか。
高リスクシステムで MFA、最小権限、ネットワーク分離が標準になっているか。
オープンソース部品、AI agent プラグイン、第三者 connector がサプライチェーン審査に含まれているか。

AI ゼロデイは基礎的なセキュリティを無効化するわけではない。むしろ、基礎を長く放置した環境を罰する。

パッチサイクルが遅い、資産台帳が不明確、インターネット公開面の責任者がいない、ログを検索できない、アカウント権限が過大なままなら、攻撃者が AI を使うかどうかは効率の違いにすぎない。問題はいずれ表面化する。

AI サプライチェーンも攻撃面になっている

GTIG は、攻撃者が AI ソフトウェアエコシステム自体にも注目していると述べている。agent skill、第三者データ connector、オープンソース wrapper ライブラリ、自動化フレームワークなどだ。リスクはモデルそのものが破られることだけではない。モデル周辺のツールチェーンが汚染されることからも生じる。

これは AI coding、AI Agent、自動化プラグインを使う人にとって重要だ。

悪意ある skill、バックドア入り依存関係、過剰権限の connector は、AI システムを「作業を助けるもの」から「攻撃者のために動くもの」へ変えてしまう。agent がファイルシステム、ブラウザ、端末、クラウドアカウント、企業データへアクセスできるなら、サプライチェーン審査は従来アプリの範囲にとどめられない。

最低限、次の対応が必要だ。

出所不明の agent skill やプラグインを安易に入れない。
コマンド実行、ファイル読み取り、秘密情報アクセスができるツールは権限分離する。
本番環境で未レビューの AI 生成スクリプトを直接実行しない。
AI プロジェクトの依存関係、GitHub Actions、PyPI / npm パッケージをスキャンする。
モデル API Key、クラウド秘密情報、GitHub Token に最小権限と漏えい監視を適用する。

セキュリティチームへの実務的な提案

第一に、脆弱性対応を前倒しする。高リスク CVE は月次パッチを待たせるべきではない。特に VPN、ゲートウェイ、管理パネル、ID システム、CI/CD、リモート管理ツールのような境界資産はそうだ。

第二に、検索可能な資産台帳を作る。AI が攻撃者の標的探索を速くするなら、防御側も「このシステムはあるか、どのバージョンか、どこに公開されているか」に素早く答えられなければならない。

第三に、署名検知を行動検知で補う。AI 生成の exploit やマルウェアは表面的特徴を変えるかもしれないが、認証回避、異常ログイン、大量探索、失敗リクエストのパターン、権限昇格の経路には行動痕跡が残る。

第四に、AI ツールをセキュリティガバナンスに入れる。社内の coding agent、browser agent、document agent、自動化スクリプト、プラグインマーケットには、承認、レビュー、ログ、ロールバックが必要だ。

第五に、AI 防御を「セキュリティ大模型を買うこと」だけにしない。実際に役立つのは、脆弱性優先順位付け、ログ分析、パッチ影響評価、コードレビュー、設定ベースライン確認に AI を組み込み、防御側の速度も上げることだ。

まとめ

GTIG の今回の報告は、AI が攻防の速度を上げていることをはっきり示している。

AI 支援のゼロデイは、ロジック欠陥や認証回避がモデルによって見つけやすくなる可能性を示した。APT45 の事例は、成熟した脅威組織がすでに AI を使って CVE を大量分析し、PoC を検証していることを示している。PROMPTSPY、AI 生成の難読化コード、agent サプライチェーン攻撃は、AI が攻撃者のチャットツールではなく攻撃ツールチェーンに入りつつあることを示す。

これは終末ではないが、普通のニュースでもない。

企業にとって実務的な対応は、恐れることではない。パッチ、資産、ログ、ID、サプライチェーン、AI ツール権限を、より速く、明確に、検証可能にすることだ。AI は攻撃者の試行速度を上げる。防御側も発見、判断、修復の速度を上げなければならない。

参考資料

Next.js の高危険度 SSRF 脆弱性 CVE-2026-44578：影響範囲とアップグレード方針

Sun, 17 May 2026 17:27:13 +0800

Next.js は 2026 年 5 月、高危険度の SSRF 脆弱性 CVE-2026-44578 を公開しました。

GitHub / Vercel のセキュリティアドバイザリ GHSA-c4j6-fc7j-m34r と NVD の記録によると、この脆弱性は、内蔵 Node.js server を使い、悪意ある WebSocket upgrade リクエストを受け取れる状態にある自己ホスト型 Next.js アプリケーションに影響します。攻撃者はサーバーに任意の内部または外部宛先へリクエストを代理送信させ、内部サービスやクラウド metadata エンドポイントを露出させる可能性があります。

Vercel 上でホストされているデプロイは影響を受けません。修正バージョンは 15.5.16 と 16.2.5 です。

先に結論

自前サーバー、コンテナ、Kubernetes、ECS、VPS、ベアメタル、または自己管理 PaaS で Next.js を自己ホストしている場合は、優先的に確認してください。

影響を受ける範囲：

next >= 13.4.13 < 15.5.16
next >= 16.0.0 < 16.2.5

影響を受けない、またはリスクが低いケース：

Vercel にデプロイしているアプリケーション。
15.5.16、16.2.5、またはそれ以降へアップグレード済み。
内蔵 Node.js server を外部に公開していない構成。
リバースプロキシやロードバランサーで不要な WebSocket upgrade をすでに遮断し、アウトバウンドアクセスも制限している環境。

推奨対応順：

本番環境で実際に動いている next バージョンを確認する。
自己ホスト型アプリをできるだけ早く修正版へアップグレードする。
すぐにアップグレードできない場合は、リバースプロキシまたはロードバランサーで不要な WebSocket upgrade を遮断する。
アプリケーションサーバーからクラウド metadata、内部管理画面、機密性の高い内部サービスへのアクセスを制限する。
直近の異常な WebSocket upgrade リクエストと内部アクセスログを確認する。

脆弱性の内容

CVE-2026-44578 は Server-Side Request Forgery、つまり SSRF の脆弱性です。

SSRF の本質的なリスクは、攻撃者が内部システムへ直接アクセスするのではなく、あなたのサーバーに代理でリクエストを送らせる点にあります。サーバーは通常、内部ネットワーク、クラウド基盤、内部サービスに近い場所にあるため、代理として使われると、攻撃者が本来アクセスできないリソースに届く可能性があります。

今回の Next.js の問題は WebSocket upgrade の処理経路にあります。アドバイザリによると、内蔵 Node.js server を使う自己ホスト型アプリケーションでは、細工された WebSocket upgrade リクエストにより、サーバーが任意の内部または外部宛先へ代理アクセスする可能性があります。

リスクのある対象は次のようなものです。

内部 HTTP サービス。
管理画面。
クラウド metadata アドレス。
コンテナまたはクラスタ内部のサービス。
サーバーからのみアクセスできる内部 API。

この脆弱性の CVSS v3.1 スコアは 8.6 High で、ベクトルは次の通りです。

`1`	`CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:N/A:N`

これは、ネットワーク経由で攻撃可能、攻撃複雑度は低く、権限もユーザー操作も不要で、主に機密性に影響することを意味します。

自己ホストが危険になりやすい理由

今回のアドバイザリは、Vercel-hosted deployments are not affected と明記しています。

重点的に見るべきなのは自己ホスト型デプロイです。理由は単純で、自己ホスト環境のネットワーク構成はさまざまだからです。origin server を直接公開しているものもあれば、Nginx、Traefik、Ingress、Cloudflare、ALB、自前ゲートウェイの背後にあるものもあります。クラウド VM、コンテナネットワーク、Kubernetes クラスタで動く場合もあります。

これらの環境でアウトバウンドアクセスが制限されていない場合、Next.js プロセスは次のものに到達できる可能性があります。

169.254.169.254 のようなクラウド metadata アドレス。
プライベート IP 範囲。
VPC 内だけで公開されているサービス。
Redis、Elasticsearch、Prometheus、Grafana などの内部コンポーネント。
Kubernetes Service、Pod、管理エンドポイント。

つまり SSRF の危険性は Next.js だけで決まるものではありません。その Next.js サーバーがいるネットワークから何にアクセスできるかで決まります。

影響を受けるか確認する方法

最初に next のバージョンを確認します。

プロジェクトディレクトリで実行します。

`1`	`npm ls next`

または：

`1`	`pnpm why next`

直接確認することもできます。

cat package.json
cat package-lock.json
cat pnpm-lock.yaml
cat yarn.lock

バージョンが次の範囲に入る場合は対応が必要です。

1
2

>= 13.4.13 < 15.5.16
>= 16.0.0 < 16.2.5

次に、デプロイ方式を確認します。

特に注意すべき構成：

next start で本番サービスを起動している。
カスタム Node.js server で Next.js をホストしている。
Docker イメージ内で Next.js server を直接起動している。
Kubernetes / ECS / VPS / ベアメタルで自己ホストしている。
リバースプロキシの背後にある Next.js origin がなお到達可能。
アプリケーションのネットワークから内部サービスやクラウド metadata にアクセスできる。

アプリケーションが Vercel にデプロイされている場合、この脆弱性の影響は受けないと公式アドバイザリは述べています。ただし、同じリリース群に他の修正が含まれる可能性があるため、Next.js は常に更新しておくべきです。

どのバージョンへ上げるべきか

公式の修正バージョンは次の通りです。

15.5.16
16.2.5

アップグレード例：

`1`	`npm install next@15.5.16`

16.x を使っている場合：

`1`	`npm install next@16.2.5`

pnpm：

`1`	`pnpm add next@15.5.16`

または：

`1`	`pnpm add next@16.2.5`

アップグレード後、再ビルドしてリリースします。

1
2

npm run build
npm run start

または、CI/CD に沿って Docker イメージを再ビルドし、再デプロイしてください。

プロジェクトが 14.x または 15.x に固定されている場合、この修正のためだけに慌てて 16.x へメジャーアップグレードする必要はありません。まず 15.5.16 の修正ラインへ上げ、テストとリリースを完了し、その後でメジャーバージョン移行を計画するほうが安全です。

一時的な緩和策

すぐにアップグレードできない場合、アドバイザリの中心的な方針は次の通りです。origin server を信頼できないネットワークに直接公開しないこと。WebSocket upgrade が不要ならリバースプロキシまたはロードバランサーで遮断すること。そして可能な限り origin のアウトバウンドアクセスを制限することです。

検討できる緩和策：

Next.js origin server を直接公開しない。
Nginx、Ingress、ALB、Cloudflare などの入口層で不要な WebSocket upgrade をフィルタする。
業務で WebSocket を使っていない場合、upgrade セマンティクスを持つリクエストを拒否する。
アプリケーションサーバーに egress 制限をかけ、クラウド metadata アドレスと機密性の高い内部ネットワークへのアクセスを禁止する。
クラウド基盤が提供するより安全な metadata アクセス方式、たとえば token 必須の metadata サービスを有効化する。
管理画面、データベース、キャッシュ、監視システムに認証とネットワーク分離を追加する。

リバースプロキシ規則は一時的な緩和策であり、アップグレードの代替ではありません。フレームワークの脆弱性は最終的に修正版で解決すべきです。

運用上の確認ポイント

この脆弱性は主に機密性に影響するため、確認の中心は「内部リソースへのアクセスに使われたか」です。

確認すべきもの：

Web アクセスログ中の異常な Upgrade、Connection、Host、パス、送信元 IP。
リバースプロキシまたはロードバランサーの異常な WebSocket upgrade ログ。
Next.js サービス周辺の異常なアウトバウンド接続。
クラウド metadata サービスへのアクセスログや認証情報の使用記録。
内部管理サービス、監視システム、キャッシュ、検索サービスへの異常アクセス。
IAM 一時認証情報、アクセスキー、token の異常使用。
コンテナまたはホスト上の不審なプロセス、ダウンロード、横展開の痕跡。

悪用が疑われる場合：

ログと証跡を保全する。
露出した可能性のあるクラウド認証情報、API key、データベースパスワード、session secret をローテーションする。
クラウドアカウントの直近 API 呼び出しを確認する。
内部サービスのアクセス記録を確認する。
影響を受けたコンテナまたはホストを再構築する。
egress 制御と metadata 保護を再確認する。

React/Next.js RCE とは別の問題

混同しやすい点として、CVE-2026-44578 は Next.js WebSocket upgrade SSRF であり、以前の React Server Components 関連 RCE ではありません。

この問題の中心は、攻撃者が指定した内部または外部アドレスへサーバーにリクエストを送らせることです。主なリスクは情報漏えいと内部リソースの探索です。

一方、React Server Components 関連の RCE はコード実行リスクであり、影響や修正範囲が異なります。

そのため「Next.js に脆弱性がある」という大見出しだけで判断せず、具体的な CVE、影響バージョン、デプロイ方式、修正バージョンを対応させる必要があります。

優先対応すべきチーム

最優先で対応すべき環境：

自己ホスト型 Next.js 本番サイト。
クラウド VM、コンテナ、Kubernetes、内部ネットワークで動作する環境。
アプリケーションサーバーがクラウド metadata サービスへアクセスできる環境。
アプリケーションサーバーが内部管理画面、データベース、キャッシュ、監視システムへアクセスできる環境。
next start origin server を直接公開している環境。
古い next を使っており、アップグレード担当が明確でない環境。

相対的に優先度が低い環境：

完全に Vercel へデプロイされているアプリケーション。
すでに修正版へアップグレード済みのアプリケーション。
origin server が直接公開されておらず、入口層で不要な WebSocket upgrade を遮断している環境。
アウトバウンドネットワークが厳格に制御され、機密性の高い内部リソースへ到達できない環境。

ただし「優先度が低い」は「アップグレード不要」という意味ではありません。Next.js は露出度の高いフレームワークであり、古いバージョンを長く使うほどリスクは積み上がります。

開発チーム向けチェックリスト

次のチェックリストで対応できます。

すべてのリポジトリの next バージョンを確認する。
Vercel プロジェクトだけでなく、すべての自己ホスト型デプロイを洗い出す。
next start または内蔵 Node.js server を使うサービスを特定する。
15.5.16、16.2.5、またはそれ以降へアップグレードする。
本番イメージを再ビルドして公開する。
入口層で不要な WebSocket upgrade を遮断する。
アプリケーションサーバーからクラウド metadata と機密性の高い内部ネットワークへのアクセスを制限する。
直近の異常な upgrade リクエストとアウトバウンドアクセスを確認する。
露出した疑いのある認証情報をローテーションする。
Next.js のセキュリティ更新を依存関係更新プロセスに組み込む。

まとめ

CVE-2026-44578 は、真剣に対応すべき Next.js の高危険度 SSRF 脆弱性です。

Vercel ホストのデプロイには影響しませんが、自己ホスト型 Next.js アプリには広く影響します。対象は 13.4.13 から 15.5.16 未満、そして 16.0.0 から 16.2.5 未満です。トリガーは WebSocket upgrade の処理経路であり、攻撃者はサーバーに内部または外部アドレスへ代理アクセスさせ、内部サービスやクラウド metadata エンドポイントを露出させる可能性があります。

直接的な修正は 15.5.16 または 16.2.5 へのアップグレードです。一時緩和としては、origin server を直接公開しないこと、不要な WebSocket upgrade を遮断すること、アプリケーションサーバーのアウトバウンドアクセスを制限することが挙げられます。

運用チームにとって重要なのは CVE スコアだけではありません。あなたの Next.js サーバーが、そのネットワーク位置から何にアクセスできるかです。SSRF の実際の影響は、サーバーの背後にある内部リソースとクラウド権限に左右されます。

参考リンク：

ssh-keysign-pwn（CVE-2026-46333）解説：Linux のローカル情報漏えい、SSH ホスト鍵、/etc/shadow のリスク

Sun, 17 May 2026 09:29:03 +0800

ssh-keysign-pwn は、Linux kernel の __ptrace_may_access() のロジック問題をめぐって公開された一連の利用経路で、CVE 番号は CVE-2026-46333 です。リモートから未認証で悪用できる脆弱性ではなく、直接 root shell を得るものでもありません。それでもリスクは高く、ローカルの低権限ユーザーが、本来アクセスできない root 所有の機密ファイル、たとえば SSH ホスト秘密鍵や /etc/shadow を読み取れる可能性があります。

運用上の重点は PoC の再現ではありません。影響を受けるマシンを特定し、カーネルを更新し、再起動して修正済みカーネルで起動し、必要に応じて SSH host keys のローテーションやパスワードリセットを行うことです。

まず結論

この脆弱性は高い優先度で対応すべきです。理由は次の 4 つです。

root 権限は不要で、ローカルの低権限ユーザーから発火できます。
公開 PoC が存在し、悪用のハードルが下がっています。
対象は通常ファイルではなく、SSH ホスト秘密鍵や /etc/shadow になり得ます。
修正にはカーネルパッチと再起動が必要で、パッケージ更新だけでは不十分です。

複数ユーザー、ローカル shell、共有ホスト、CI runner、コンテナホスト、学生用端末、踏み台サーバー、または完全には信頼できないローカルユーザーがいるサーバーでは、優先的に対応してください。

脆弱性の概要

Qualys は 2026 年 5 月 15 日、oss-security でこの問題を公開しました。Qualys はそれ以前に Linux kernel の __ptrace_may_access() ロジック問題を security@kernel.org に報告しており、上流修正は Linus によってマージ済みでした。その後、公開 exploit コードが現れたため、Qualys は情報を oss-security に投稿しました。

その後 Linux kernel CVE チームがこの問題に CVE-2026-46333 を割り当てました。NVD ページではソースが kernel.org とされ、問題説明はカーネルコミット ptrace: slightly saner 'get_dumpable()' logic に対応しています。

簡単に言えば、この脆弱性はプロセス終了経路にあります。一部の特権プロセスが終了中の場合、対象タスクがすでに mm を持たないため、カーネル内の ptrace アクセスチェック関連ロジックが、本来依存すべき dumpable チェックを迂回してしまう可能性があります。攻撃者は非常に狭い競合ウィンドウで、終了中の特権プロセスがまだ開いているファイルディスクリプタを取得できます。

これが ssh-keysign-pwn と呼ばれる理由です。公開された利用経路の一つは ssh-keysign を使い、SSH host private keys を読み取るものです。

SSH ホスト秘密鍵と /etc/shadow が読まれる理由

この問題の本質はローカル情報漏えいです。特権プログラムの終了過程で「メモリ記述子は切り離されたが、ファイルディスクリプタはまだ閉じられていない」時間差を悪用します。

AlmaLinux のアドバイザリはリスクを明確に説明しています。特権プログラムが権限を落とす前に機密ファイルを開いており、攻撃者が終了ウィンドウ中に対応するファイルディスクリプタを取得できれば、その機密ファイルを読み取れる可能性があります。

公開議論でよく挙がる対象は次の 2 つです。

ssh-keysign：/etc/ssh/ssh_host_*_key のような SSH ホスト秘密鍵に関係する可能性があります。
chage：/etc/shadow に関係する可能性があります。

SSH ホスト秘密鍵が漏えいすると、攻撃者はそのホストになりすまし、SSH のホスト ID 信頼を損なう可能性があります。/etc/shadow が漏えいすると、攻撃者はパスワードハッシュをオフラインで解析し、後続の侵害を広げることができます。

そのため、これは「直接 root shell」ではなくても高優先度で扱うべき問題です。

影響範囲の判断

上流の観点では、これは Linux kernel の脆弱性です。NVD の記録では、この問題は 2026 年 5 月 15 日に NVD データセットへ追加されており、その時点では CVSS スコアは付与されていませんでした。

ディストリビューションごとの状態は、それぞれのアドバイザリで確認してください。

AlmaLinux 8、9、10 は対応情報を公開し、2026 年 5 月 16 日の更新で patched kernels が本番リポジトリに入ったと説明しています。
Debian Security Tracker は bullseye、bookworm、trixie、sid などの vulnerable/fixed 状態と fixed versions を掲載しています。
その他のディストリビューションでは、Ubuntu、Red Hat、SUSE、Arch、Alpine などの公式セキュリティページや更新リポジトリを確認してください。

カーネルの上流バージョン番号だけで安全かどうかを判断しないでください。ディストリビューションは修正を backport するため、同じ上流バージョンに見えても、配布元によってパッチ状態が異なる場合があります。

優先的に対応すべきマシン

リスク順に対応するなら次の順序を推奨します。

複数ユーザーサーバーと共有ホスト。
通常の shell アカウントがある踏み台、教育用端末、開発機。
CI runner、ビルドマシン、ホスティング基盤ノード。
コンテナホストと仮想化ホスト。特に完全には信頼できない workload が共存する環境。
公開サービス用マシン。脆弱性自体はローカルアクセスを必要としますが、Web/RCE/弱いパスワードで低権限の足場が得られるとリスクが重なります。

純粋な単一ユーザーデスクトップのリスクは相対的に低めですが、システム更新で修正することを推奨します。ブラウザ、開発ツール、スクリプト、サードパーティソフトウェアを通じたローカル低権限コード実行は珍しくないためです。

修正方針

最優先の修正は、ディストリビューションが提供する修正済みカーネルをインストールし、再起動することです。

コマンドはディストリビューションごとに異なりますが、原則は同じです。

パッケージメタデータを更新する。
CVE-2026-46333 修正を含む kernel パッケージをインストールする。
再起動して新しいカーネルで起動する。
uname -r とディストリビューションのセキュリティアドバイザリで、実行中カーネルが修正済みか確認する。

AlmaLinux のアドバイザリでは、本番リポジトリに修正済みカーネルが提供されており、通常の dnf upgrade と再起動で対応できるとされています。Debian tracker も複数ブランチの fixed versions を掲載しています。

注意点として、新しい kernel パッケージをインストールしただけで再起動しない場合、古い脆弱なカーネルがまだ動作しています。

一時的な緩和策：ptrace_scope を厳しくする

すぐに再起動できない場合は、まず Yama の ptrace_scope を厳しくしてください。

Qualys は oss-security の後続返信で、/proc/sys/kernel/yama/ptrace_scope を 2（admin-only attach）または 3（no attach）に設定すると、既知の公開利用経路を阻止できると確認しています。ただし理論上は別の利用方法が存在し得るとも述べており、これは修正ではなく緩和策です。

一時設定は次の通りです。

`1`	`sudo sysctl -w kernel.yama.ptrace_scope=3`

永続化する場合は sysctl 設定に書き込みます。

`1`	`echo 'kernel.yama.ptrace_scope = 3' \| sudo tee /etc/sysctl.d/99-ssh-keysign-pwn.conf`

ptrace_scope=3 は ptrace attach を無効化するため、gdb や strace -p などのデバッグに影響する可能性があります。本番環境でデバッグが必要なら 2 を検討してください。どちらを選んでも、カーネル更新と再起動は早めに計画すべきです。

SSH ホスト鍵をローテーションすべきか

脆弱性公開前後に次の条件があったマシンでは、保守的に対応することを推奨します。

信頼できないローカルユーザーがいる。
共有ホスト、またはコンテナ/CI のマルチテナント環境である。
Web 脆弱性、弱いパスワード、サプライチェーンスクリプトなど、攻撃者にローカル足場を与え得る要素がある。
ログに不審なローカルプロセス、異常なデバッグ挙動、公開 PoC ファイルがある。
修正前に長時間露出していた。

保守的な対応には次が含まれます。

修正と再起動後に SSH host keys をローテーションする。
既知ホスト指紋管理システムを更新する。
そのホスト指紋に依存する自動化システムへ通知する。
SSH 接続アラートを確認し、正当な指紋変更を中間者攻撃と誤認しないようにしつつ、本当のリスクを見逃さない。

/etc/shadow が漏えいした疑いがある場合は、パスワードリセット、弱いパスワードの禁止、古いハッシュがオフライン解析可能かどうかの確認も検討してください。

監視すべきもの

この種の脆弱性は利用ウィンドウが短く、従来のログに完全には残らない可能性があります。それでも次の点は確認できます。

通常ユーザーディレクトリに ssh-keysign-pwn、chage_pwn、または類似 PoC ファイルがないか。
短時間で見慣れない C プログラムをコンパイルするなどの不審なコンパイル行為。
/etc/ssh/ssh_host_*_key や /etc/shadow への異常アクセスの兆候。
異常な pidfd_getfd、ptrace、デバッガ関連の挙動。
外部システムから SSH ホスト指紋異常が報告されていないか。

これらのシグナルは悪用を証明するものではなく、存在しないからといって悪用されていない証明にもなりません。最優先事項は、パッチ、再起動、認証情報のローテーション、リスク隔離です。

よくある誤解

1 つ目の誤解：これは OpenSSH のリモート脆弱性ではありません。名前に ssh-keysign が入っていますが、根本原因は Linux kernel の ptrace アクセスチェックロジックであり、sshd のリモート認証フローではありません。

2 つ目の誤解：ローカルユーザーがいなければ完全に安全、というわけではありません。確かにローカル実行条件は必要ですが、実際の攻撃チェーンでは Web サービス、CI、スクリプト、弱いパスワード、コンテナエスケープなどを足がかりに低権限のローカル実行を得ることがよくあります。

3 つ目の誤解：ptrace_scope を設定すれば十分、というものです。これは一時的な緩和策であり、根本修正ではありません。カーネル更新と再起動は必要です。

4 つ目の誤解：root を取られていなければ問題ない、というものです。SSH ホスト秘密鍵や /etc/shadow の漏えいだけでも、横展開、ホストなりすまし、オフライン解析につながる十分なリスクがあります。

対応チェックリスト

次の順序で実行することを推奨します。

影響を受ける Linux ホストを棚卸しする。特に複数ユーザー環境と共有環境を優先する。
ディストリビューション公式のセキュリティアドバイザリを確認し、fixed kernel version を特定する。
修正済みカーネルをインストールして再起動する。
すぐに再起動できないマシンでは、先に kernel.yama.ptrace_scope=2 または 3 を設定する。
修正後、実行中のカーネルバージョンを確認する。
高リスクマシンでは SSH host keys をローテーションする。
/etc/shadow 漏えいが疑われる場合、パスワードリセットとアカウント監査を検討する。
公開 PoC、異常なコンパイル、不審なローカルデバッグ挙動を確認する。

まとめ

ssh-keysign-pwn（CVE-2026-46333）は、Linux kernel の __ptrace_may_access() 関連ロジックに起因するローカル情報漏えい脆弱性です。リモートから直接侵入できるものでも、直接 root shell を与えるものでもありませんが、低権限ローカルユーザーが高価値の機密ファイルを読み取れる可能性があるため、複数ユーザー、共有ホスト、CI、コンテナホスト環境では特に警戒が必要です。

最も確実な修正は、ディストリビューション提供の修正済みカーネルへ更新し、再起動することです。ptrace_scope=2/3 は一時的な緩和策として使えますが、パッチの代替にはなりません。リスクウィンドウにさらされていた重要ホストでは、SSH ホスト鍵のローテーションとパスワードリスク評価も検討してください。

参考リンク：

CVE-2026-42945 の確認方法：Nginx Rift の発動条件、バージョン確認、アップグレード方針

Fri, 15 May 2026 17:55:42 +0800

CVE-2026-42945 は NGINX Open Source と NGINX Plus に存在するセキュリティ脆弱性で、外部では Nginx Rift とも呼ばれています。問題は ngx_http_rewrite_module にあり、脆弱性の種類は heap-based buffer overflow です。

この種のニュースは、「18 年間潜伏」「パスワード不要でリモート制御」「サーバーの 30% が影響」といった見出しになりがちです。たしかに広まりやすい表現ですが、パッチ情報や NVD の説明を見るときは、リスクを分解して見るべきです。深刻な脆弱性であり、ログインも不要です。ただし、すべての Nginx インスタンスが自動的に乗っ取られるわけではなく、発動には特定の rewrite 設定とリクエスト条件が必要です。

まず公式説明を見る

NVD による CVE-2026-42945 の説明は、次のように整理できます。

NGINX Plus と NGINX Open Source に影響する。
脆弱性は ngx_http_rewrite_module にある。
rewrite ディレクティブの後に rewrite、if、または set ディレクティブが続き、$1 や $2 のような名前なし PCRE キャプチャグループを使い、さらに置換文字列に疑問符 ? が含まれる場合に問題が発動する可能性がある。
未認証の攻撃者が細工したリクエストを送ることで脆弱性を発動できる。
結果として NGINX worker プロセスで heap buffer overflow が発生し、再起動する可能性がある。
システムで ASLR が無効化されている場合、コード実行の可能性がある。

CNA である F5 の評価は次のとおりです。

CVSS v4.0：9.2、Critical。
CVSS v3.1：8.1、High。
CWE：CWE-122 Heap-based Buffer Overflow。

つまり、これは単なる「設定ミスで 404 になる」問題ではなく、Nginx 公式のセキュリティ修正対象となるメモリ安全性の脆弱性です。

落ち着いて読むべき表現

第一に、「パスワード不要」は基本的に未認証攻撃と理解できます。攻撃者は Nginx の管理画面にログインする必要も、SSH を取得する必要も、アプリケーションアカウントを持つ必要もありません。ただし、任意の公開 Nginx を簡単に乗っ取れる、という意味ではありません。

第二に、「直接リモート制御」は条件次第です。公式説明に沿ったより慎重な言い方は、worker プロセスの再起動を引き起こす可能性がある、そして ASLR が無効なシステムではコード実行が可能な結果になり得る、というものです。ASLR が有効で、ディストリビューションのビルド強化が適用され、実行権限が制限された環境では、リスク経路はより複雑になります。

第三に、「30% のサーバーが影響」という表現を「Nginx の市場シェア全体が攻撃面である」と同一視してはいけません。実際の露出は、バージョン、影響を受けるモジュールの有無、特定の rewrite 設定の有無、ディストリビューションがすでにバックポートしているか、そして Nginx 実行環境の強化状態によって決まります。

より正確な判断はこうです。本番環境で Nginx を動かしているなら、すぐ確認するべきです。ただし、見出しの割合だけで自分の環境が影響を受けるかどうかを判断しないでください。

影響範囲をどう判断するか

nginx.org のリリース情報によると、2026 年 5 月 13 日に公開された nginx-1.30.1 stable と nginx-1.31.0 mainline には複数のセキュリティ修正が含まれており、その中に CVE-2026-42945、つまり ngx_http_rewrite_module の buffer overflow 修正も含まれています。

公式 Nginx のソースコードや公式パッケージを使っている場合は、まず次を確認します。

NGINX Open Source stable：1.30.1 以降へアップグレード。
NGINX Open Source mainline：1.31.0 以降へアップグレード。
NGINX Plus：F5 が案内する対象ブランチの修正版を確認。

Debian、Ubuntu、RHEL、AlmaLinux、Rocky Linux、Alpine、コンテナイメージ、Plesk、管理パネル、Ingress Controller、クラウド事業者の管理コンポーネントを使っている場合、nginx -v の上流バージョンだけを見て判断しないでください。多くのディストリビューションはセキュリティ修正を古いパッケージに backport します。バージョン番号が古く見えても、パッチが取り込まれている場合があります。

1 分で緊急度を判断する

まず次の質問で簡易的に優先度を分けます。

この Nginx はインターネットに直接公開されているか、API Gateway、リバースプロキシ、ロードバランサー、Ingress の入口層にあるか。
公式 Nginx パッケージ、ソースビルド、サードパーティ管理パネル、コンテナイメージを使っており、まだ CVE-2026-42945 の修正状態を確認していないか。
設定に複雑な rewrite ルールがあるか。特に連続した rewrite、if、set、および $1、$2 のような名前なしキャプチャを使っているか。
リクエストパス、クエリパラメータ、ユーザー制御入力を rewrite の出力先に含める場面があるか。
ASLR が無効、worker の権限が強すぎる、コンテナ権限が広すぎるなど、システム強化が弱いか。

最初の 2 項目に該当し、rewrite 設定の確認がまだなら、高優先度として扱うべきです。公開入口、共有環境、Kubernetes Ingress、エッジプロキシ、ログインや API トラフィックを扱う Nginx は、修正済みと確認できるパッケージへ優先的に更新または置き換えます。

Debian / Ubuntu / RHEL / Alpine で修正を確認する方法

ディストリビューション利用者は nginx -v だけを見ないでください。Debian、Ubuntu、RHEL、AlmaLinux、Rocky Linux、Alpine などは、セキュリティパッチを安定ブランチへ backport することが多く、見かけのバージョンが nginx.org の 1.30.1 や 1.31.0 より低い場合があります。

Debian / Ubuntu では、セキュリティアドバイザリ、パッケージ changelog、アップグレード候補を確認します。

nginx -v
nginx -V
apt list --upgradable | grep nginx
apt changelog nginx | grep -i "CVE-2026-42945"

RHEL / AlmaLinux / Rocky Linux では、セキュリティ更新とパッケージ変更履歴を確認します。

1
2

yum updateinfo list security | grep -i nginx
rpm -q --changelog nginx | grep -i "CVE-2026-42945"

Alpine では、現在のパッケージバージョンとセキュリティブランチの更新状況を確認します。

1
2

apk info -v nginx
apk version -v nginx

パッケージマネージャー、ディストリビューションのセキュリティアドバイザリ、またはベンダー advisory が CVE-2026-42945 の修正済みを明記しているなら、上流バージョン番号が新しく見えなくても「バックポート済み」と扱えます。逆に、バージョン番号が高くても出所が不明なら、ビルド日とパッチの出所を確認してください。

コンテナイメージと Ingress Controller の確認方法

コンテナ環境では、ホストではなくイメージ内の Nginx を確認します。まず実際に組み込まれているバージョンを確認します。

1
2

docker run --rm your-nginx-image nginx -v
docker run --rm your-nginx-image nginx -V

ベースイメージが更新されているかも確認してください。イメージが Debian、Ubuntu、Alpine、またはディストリビューションパッケージを元に構築されている場合は、該当ディストリビューションのセキュリティアドバイザリとパッケージ changelog に戻って判断します。古いイメージを再起動するだけでは意味がありません。イメージ自体の再ビルドまたは置き換えが必要です。

Kubernetes Ingress では、次の 3 点を同時に確認します。

Ingress Controller プロジェクトが CVE-2026-42945 に関する advisory または修正版を公開しているか。
現在クラスタで実行されている controller イメージの digest が実際に更新されているか。tag だけの変更では不十分です。
controller 内蔵の Nginx バージョン、ビルドパラメータ、テンプレート設定に高リスクの rewrite ルールが残っていないか。

まず実行中のイメージを確認します。

1
2

kubectl -n ingress-nginx get pods -o wide
kubectl -n ingress-nginx describe pod <pod-name> | grep -i image

クラウド事業者のマネージド Ingress やゲートウェイを使っている場合は、該当クラウドサービスのアドバイザリも確認してください。マネージドコンポーネントは通常、ユーザーが自分で apt upgrade して修正できるものではありません。事業者の修正を待つか、修正済みバージョンへ切り替える必要があります。

重点的に確認すべき rewrite 設定

この脆弱性は rewrite 設定に関係します。まず Nginx 設定を検索します。

1
2

grep -R "rewrite" /etc/nginx -n
grep -R "\\$[0-9]" /etc/nginx -n

次のようなパターンに注意します。

`1`	`rewrite ^/old/(.*)$ /new/$1? permanent;`

ここでの $1、$2 のような名前なしキャプチャと、置換先に含まれる ? は、公式説明にある重要な条件の一部です。特に次のような書き方を確認します。

ある rewrite の後に別の rewrite、if、または set が続く。
正規表現で (.*) や (.+) のような広いキャプチャを使い、出力先で $1 や $2 を使っている。
rewrite の出力先に ? があり、クエリパラメータの追加または破棄に使っている。
rewrite の入力が公開パス、Host、URI、パラメータ、または上流が制御できる値に由来する。
管理パネル、ゲートウェイ、Ingress annotation、テンプレートが自動生成した rewrite ルール。

短時間でアップグレードできない場合は、一時的な緩和策を取ります。

複雑な rewrite ルールを減らす。
名前なしキャプチャを、より明確な名前付きキャプチャへ変更する。
置換文字列内で不要な ? を連結しない。
高リスク入口に WAF またはリバースプロキシルールを追加する。
ASLR が有効であることを確認する。
Nginx worker の実行権限を下げ、systemd sandbox、SELinux/AppArmor などの強化状態を確認する。

これらは緩和策であり、パッチの代替ではありません。

修正の優先順位

露出面に応じて優先順位を付けます。

公開入口の Nginx。
リバースプロキシ、API Gateway、エッジゲートウェイ。
マルチテナント環境の Nginx。
Kubernetes Ingress Controller。
Plesk、管理パネル、クラウドマーケットプレイスのイメージなど、Nginx を同梱するコンポーネント。
内部ネットワーク上でも重要業務を担う Nginx。

アップグレード後の確認：nginx -t、reload、worker 状態

更新後は、パッケージマネージャーの成功表示だけで終わらせないでください。設定、プロセス、実際のバイナリがすべて切り替わっていることを確認します。まず設定を検証します。

`1`	`nginx -t`

エラーがなければ、滑らかに reload します。

`1`	`systemctl reload nginx`

パッケージ更新でバイナリが置き換わった場合は、古い worker が終了していることを確認します。

`1`	`ps aux \| grep nginx`

master プロセスの起動時刻やバイナリパスも確認し、実行中のサービスが古いプロセスのまま残っていないことを見ます。必要ならメンテナンス時間を設けてサービスを再起動し、古い worker や古いコンテナがリクエストを処理し続けないようにします。

コンテナと Ingress 環境では、新しいイメージのロールアウトが実際に完了していることも確認します。

1
2

kubectl -n ingress-nginx rollout status deployment/<deployment-name>
kubectl -n ingress-nginx get pods -o wide

確認の要点は「コマンドを実行したか」ではなく、「修正を含む Nginx プロセスが本番トラフィックを処理しているか」です。

同じ Nginx 修正バッチを無視しない

nginx.org が同日に公開した 1.30.1 と 1.31.0 は、CVE-2026-42945 だけを修正したわけではありません。リリース情報には HTTP/2 request injection、SCGI/uWSGI buffer overread、charset module buffer overread、HTTP/3 address spoofing、OCSP resolver use-after-free なども挙げられています。

つまり、本番環境では単一 CVE に対する一時ルールだけで済ませるべきではありません。この Nginx のセキュリティ更新全体を、まとめてアップグレード対象として扱うべきです。

まとめ

CVE-2026-42945 の要点は、「すべての Nginx が即座に乗っ取られる」という話ではありません。rewrite モジュールに長期間存在していたメモリ安全性の脆弱性であり、特定の設定では未認証リクエストから発動できます。最も直接的な結果は worker のクラッシュと再起動です。ASLR が無効な環境など、弱い環境ではコード実行リスクが高くなります。

運用側の対応順序はシンプルです。

Nginx の入手元とバージョンを確認する。
ディストリビューション、F5、nginx.org、クラウド事業者のアドバイザリを見る。
修正を含むバージョンまたはディストリビューションのセキュリティパッケージへできるだけ早く更新する。
複雑な rewrite 設定、特に $1、$2、? の組み合わせを確認する。
ASLR、権限分離、サービス reload 状態を確認する。

見出しは怖くても、修正は冷静に進めるべきです。まず露出面を確認し、次にアップグレードし、その後で高リスクな rewrite ルールを整理します。

参考リンク

Dirty Frag、Copy Fail、Fragnesia：最近の Linux ローカル権限昇格脆弱性 3 件の比較

Fri, 15 May 2026 13:24:04 +0800

最近、Linux カーネルで注目度の高いローカル権限昇格脆弱性が続けて報告されています。Dirty Frag、Copy Fail、Fragnesia です。最終的な効果はいずれも似ています。低権限のローカルユーザーが root に昇格できる可能性があります。

ただし運用対応の観点では、これらを一つの脆弱性として扱うべきではありません。入口となるモジュール、発火経路、緩和策、パッチのタイミングが異なります。より正確には、Linux カーネルの「ページキャッシュ、splice、socket buffer、暗号処理経路」という複雑な境界に共通するリスクを露出させたものです。

この記事ではリスクと対応方針だけを扱い、再現可能な攻撃手順は扱いません。

3 つの脆弱性の概要

Dirty Frag：CVE-2026-43284

Dirty Frag は主に Linux カーネルのネットワーク経路におけるページキャッシュ書き込み問題を指します。公開資料では、xfrm-ESP 側の CVE-2026-43284 と、rxrpc 側の CVE-2026-43500 が一緒に語られることが多いです。

CVE-2026-43284 は、ESP が共有 skb fragment を処理する際のインプレース復号に関係します。重要なのは、攻撃者がディスク上のファイルを直接書き換えるのではなく、カーネルが書くべきでない共有ページへ書き込み、ページキャッシュ内のファイル内容に影響する点です。

運用上覚えておくべきなのは、Dirty Frag が esp4、esp6、rxrpc というカーネルモジュール群とネットワークサブシステム経路に到達することです。IPsec、ESP、RxRPC と関係するため、一時的な緩和策もこれらのモジュールを中心に考えることになります。

Copy Fail：CVE-2026-31431

Copy Fail は Theori / Xint Code が公開した Linux カーネルのローカル権限昇格脆弱性です。入口は IPsec のネットワーク経路ではなく、カーネルのユーザー空間暗号 API である algif_aead / AF_ALG 関連経路です。

公開説明では、2017 年に導入されたインプレース最適化に由来するとされています。特定の状況で、カーネルが期待どおりにデータをコピーせず、ページキャッシュページを writable な宛先経路に入れてしまいます。攻撃者は AF_ALG と splice() を組み合わせ、ページキャッシュに裏付けられたページへ小さな制御書き込みを行えます。

リスクが高い理由は、利用可能性が高く、複数の主要ディストリビューションにまたがって影響するためです。Dirty Frag と違い、Copy Fail の一時的な緩和は algif_aead の制限または無効化、そしてコンテナや CI 環境での AF_ALG socket 作成制限が中心になります。

Fragnesia：CVE-2026-46300

Fragnesia は V12 Security が公開した別の Linux カーネルローカル権限昇格脆弱性で、Dirty Frag と近い攻撃面に属します。Dirty Frag と同じ bug ではありませんが、IPsec ESP / rxrpc 関連モジュールとページキャッシュ書き込み効果を中心にしています。

AlmaLinux はこれを同じコード領域における 3 つ目の local-root 問題として位置付けています。ポイントは、skb_try_coalesce() が socket buffer fragment を結合する際に共有 fragment マーカーを正しく保持しなかったことです。その結果、後続の XFRM ESP-in-TCP 受信経路が外部ページキャッシュページ上でインプレース復号を行う可能性があります。

つまり、Fragnesia は Dirty Frag に近い問題です。どちらも esp4、esp6、rxrpc、skb fragment、ESP 復号経路の周辺にあります。一時的な緩和策も大きく重なります。

共通点：なぜ危険なのか

3 つの共通点は「コード位置が完全に同じ」ということではなく、攻撃結果とリスクモデルが非常に似ていることです。

第一に、いずれもローカル権限昇格です。攻撃者は通常、まず対象マシン上で一般ユーザーとしてコード実行能力を得てから、root への昇格を試みます。単一ユーザーのデスクトップではリモート一発侵害ではありませんが、複数ユーザーサーバー、CI runner、コンテナホスト、共有開発機、SSH を公開している VPS では、低権限入口は珍しくありません。

第二に、いずれもページキャッシュ書き込みに関係します。攻撃者は必ずしもディスク上のファイルを恒久的に書き換えるわけではなく、メモリ上のページキャッシュコピーに影響します。これにより従来のファイル整合性チェックは不十分になり得ます。ディスク hash は正常でも、実行経路が汚染されたページキャッシュ内容を読む可能性があります。

第三に、タイミングに強く依存する競合条件というより、決定的なロジックバグに近いものです。公開資料では、これらの脆弱性は race condition に勝つ必要がないと繰り返し述べられています。防御側は古い経験則で利用成功率を低く見積もるべきではありません。

第四に、コンテナや自動化実行環境のリスクを増幅します。コンテナ内の低権限コード、CI ジョブ、ビルドスクリプト、サードパーティプラグインがホストカーネルの関連インターフェースに到達できると、「ローカル問題」が「プラットフォーム問題」に変わります。

相違点：一つの対策では全部を覆えない

最大の違いは入口となるモジュールです。

Copy Fail の重要な入口は algif_aead / AF_ALG で、カーネルのユーザー空間暗号 API に属します。一時的な防御は algif_aead の無効化または制限、そして seccomp によるコンテナ内の AF_ALG socket 作成ブロックが中心です。

Dirty Frag の重要な入口は xfrm-ESP と rxrpc です。プロトコル処理と socket buffer 処理経路に近く、一時的な防御では esp4、esp6、rxrpc の無効化を検討します。ただし IPsec、VPN、トンネル、関連するネットワーク機能に影響する可能性があります。

Fragnesia の入口も Dirty Frag に近い領域ですが、具体的には skb_try_coalesce() が共有 fragment マーカーを保持しなかったことが問題です。Copy Fail の暗号 API 問題というより、Dirty Frag のリスク面にある別の分岐と見るべきです。

したがって、Copy Fail を処理済みだから Dirty Frag と Fragnesia も覆われる、とは言えません。逆に esp4 / esp6 を無効化したから Copy Fail が消えるわけでもありません。それぞれのパッチ状態と緩和策を別々に確認する必要があります。

影響範囲の判断方法

この種の脆弱性では、ディストリビューション名やカーネルのメジャーバージョンだけで判断しないことが重要です。ディストリビューションは修正をバックポートしますし、クラウドベンダーは独自のカーネルブランチを維持します。企業向けディストリビューションでは追加パッチが入っていることもあります。

より安全な確認順序は次の通りです。

ディストリビューションのセキュリティアドバイザリとカーネルパッケージ changelog を確認する。
現在のカーネルパッケージで対象 CVE が修正済みか確認する。
クラウドサーバー、コンテナホスト、CI ノードでは、クラウド事業者やプラットフォーム側の公告も確認する。
一時的な緩和策では、業務が対象モジュールに依存しているか確認する。
カーネル更新後は再起動を行い、実際に実行中のカーネルが切り替わったことを確認する。

この手順で最もありがちな落とし穴は「パッケージは更新したが、マシンを再起動していない」ことです。カーネル脆弱性は通常のユーザー空間サービス更新とは違います。新しいパッケージを入れても、再起動するまで古いカーネルが動き続ける可能性があります。

運用上の優先度

最優先で処理すべきマシンは、すべての Linux マシンを均等に並べたものではありません。低権限コード実行が最も起きやすい場所から始めるべきです。

優先度が高い環境は次の通りです。

複数ユーザーのログインサーバー
CI / CD runner
ビルドマシンと成果物パッケージングマシン
コンテナホストと Kubernetes ノード
共有開発機
SSH を公開しているクラウドサーバーと VPS
サードパーティスクリプト、プラグイン、ジョブキューを実行するプラットフォーム
Web 脆弱性、弱いパスワード、過去の侵害痕跡があるマシン

閉じた単一ユーザー環境で外部コード実行入口がないマシンも、脆弱であればリスクはあります。ただし対応順序は後ろに回せる場合があります。

一時的な緩和策の位置付け

一時的な緩和策はパッチの代替ではありません。すぐに再起動できない、またはディストリビューションのパッケージを待っている間に露出面を下げるためのものです。

Copy Fail では algif_aead と AF_ALG に注目します。業務でカーネル AF_ALG 暗号インターフェースを使っていない場合は、関連モジュールの無効化を評価できます。コンテナ環境では、信頼できないワークロードが該当 socket を自由に作れないよう、まず seccomp ポリシーを確認すべきです。

Dirty Frag と Fragnesia では、esp4、esp6、rxrpc に注目します。システムが IPsec ESP、関連 VPN、トンネル、RxRPC に依存していない場合は一時的な無効化を検討できます。ただし本番環境では不用意に実行しないでください。これらのモジュールは実際のネットワーク業務を支えている可能性があります。

最終的にはカーネル更新に戻る必要があります。一時的な緩和策は攻撃面を減らせますが、システムが完全に安全であることの証明にはなりません。

3 つの脆弱性が示すもの

本当に警戒すべきなのは CVE の数だけではありません。これらの脆弱性はすべて、ゼロコピー、splice、socket buffer、ページキャッシュ、暗号インターフェース、プロトコルスタック最適化といった高複雑度のカーネル経路に集中しています。

これらの経路は大きな性能上の利益をもたらしますが、所有権の境界を保つのが難しくなります。fragment が共有されているか、ページにインプレースで書けるのか、最適化が本当にコピー削減だけなのか、といった点が安全境界そのものになります。

セキュリティチームと運用チームにとって、結論は実務的です。

ローカル権限昇格は「既存の低権限入口を増幅するもの」として扱う。
コンテナはカーネル脆弱性に対する自然な隔離境界ではない。
ファイル整合性チェックはディスク内容だけを見てはいけない。
CI、ビルドマシン、プラグイン基盤は高優先度資産として扱う。
カーネルパッチは「インストール済み」と「実行中」の両方を確認する。

まとめ

Dirty Frag、Copy Fail、Fragnesia はいずれも最近の Linux ローカル権限昇格リスクとして優先度の高い事象ですが、一つの脆弱性の別名ではありません。

Copy Fail は algif_aead / AF_ALG 暗号 API 経路を通ります。Dirty Frag は xfrm-ESP と rxrpc 関連経路を通ります。Fragnesia は Dirty Frag に近い攻撃面で、skb fragment マーカー処理の問題により再びページキャッシュ書き込みリスクを引き起こします。

対応として最も堅実なのは、ディストリビューションの公告に従ってカーネルを更新し、再起動することです。すぐに更新できないシステムでは、漏洞の入口に応じて一時的なモジュール無効化や seccomp の強化を評価します。複数テナント、CI、コンテナホスト、共有開発環境を優先してください。

参考資料：

Theori Copy Fail 説明：https://github.com/theori-io/copy-fail-CVE-2026-31431
CERT-EU Copy Fail セキュリティアドバイザリ：https://cert.europa.eu/publications/security-advisories/2026-005/
AlmaLinux Dirty Frag 説明：https://almalinux.org/blog/2026-05-07-dirty-frag/
AlmaLinux Fragnesia 説明：https://almalinux.org/blog/2026-05-13-fragnesia-cve-2026-46300/
V12 Security Fragnesia PoC 説明：https://github.com/v12-security/pocs/tree/main/fragnesia

Fragnesia (CVE-2026-46300)：Linux カーネルのローカル権限昇格脆弱性の影響と緩和策

Fri, 15 May 2026 13:18:01 +0800

Linux カーネルで、Dirty Frag と同じ系統の攻撃面に関係するローカル権限昇格脆弱性が新たに報告されました。Fragnesia (CVE-2026-46300) です。

V12 Security の公開情報によると、Fragnesia は Linux のローカル権限昇格脆弱性です。攻撃者はホスト上で高権限を持っている必要はありません。ローカルでコードを実行できれば、カーネルの XFRM ESP-in-TCP サブシステムのロジック欠陥を利用し、読み取り専用ファイルのページキャッシュ内容をバイト単位で書き換え、最終的に root shell を得られる可能性があります。

原資料：

V12 Security PoC 説明：https://github.com/v12-security/pocs/blob/main/fragnesia/README.md

この記事では再現可能な攻撃手順は扱わず、運用側が把握すべきリスクと対応方針に絞ります。

Dirty Frag との関係

V12 Security は Fragnesia を Dirty Frag 脆弱性クラスに分類しています。Dirty Frag と同一の bug ではありませんが、Linux カーネルの XFRM ESP-in-TCP という同じ攻撃面にある別の問題です。

XFRM は Linux カーネルで IPsec を処理するためのフレームワークです。ESP-in-TCP は ESP 暗号化トラフィックを TCP 上で運ぶ仕組みに関係します。Fragnesia の問題は、共有ページフラグメントと socket buffer の結合処理にあります。特定の状況で、カーネルが fragment がまだ共有状態であることを見失い、制御可能な書き込み余地が生まれます。

この種の問題は Dirty Pipe / Dirty Frag のようなページキャッシュ書き込み脆弱性を想起させます。具体的なコードは同一ではありませんが、攻撃効果が読み取り専用ファイルのページキャッシュ上のコピーに到達する点が共通しています。

なぜ危険なのか

Fragnesia が危険な理由は主に 3 つあります。

第一に、これはローカル権限昇格です。攻撃者が通常ユーザーとしてコードを実行できるだけで、root に昇格できる可能性があります。複数ユーザーのサーバー、コンテナホスト、CI runner、共有開発機、VPS、Shell を公開している環境では、通常のデスクトップよりも深刻です。

第二に、従来型の競合条件に依存しません。V12 の説明では、ESP-in-TCP の処理フローを構成し、すでに socket buffer に splice されたファイルページ上で暗号化ストリームを処理させることで、ページキャッシュ内容にバイト単位の影響を与える経路が示されています。これは単なる理論上の可能性ではなく、安定した利用経路が検証されていることを意味します。

第三に、変更されるのはディスク上のファイルではなくページキャッシュです。公開説明の例では /usr/bin/su が対象になっています。成功後もディスク上のファイルは恒久的には書き換えられず、変更はメモリ上のページキャッシュに存在します。ディスクファイルの hash や整合性だけを確認する巡回チェックでは異常を見逃す可能性があります。

管理者にとって厄介なのはここです。ファイルは変わっていないように見えても、汚染されたページキャッシュ上の対象バイナリを実行すると権限昇格につながる可能性があります。

既知の影響範囲

V12 Security の説明では、Dirty Frag の影響を受け、2026 年 5 月 13 日の関連パッチが適用されていないカーネルは Fragnesia の影響も受けるとされています。公開検証環境には Ubuntu 22.04、Ubuntu 24.04、6.8.0-111-generic などのカーネルが含まれます。

注意点は 2 つあります。

第一に、ディストリビューションのメジャーバージョンだけで判断しないことです。Ubuntu 22.04 / 24.04 が影響を受けるかどうかは、ディストリビューション名ではなく実際のカーネルパッチ状態で決まります。

第二に、デフォルトの AppArmor 制限だけに頼らないことです。Ubuntu の非特権ユーザー名前空間に対する AppArmor 制限はハードルを上げますが、公開情報ではそれは追加の回避対象であり、脆弱性本体の根本対策ではありません。

信頼できる判断方法は、各ディストリビューションのセキュリティアドバイザリとカーネルパッケージ更新を確認することです。

一時的な緩和策

すぐにカーネルを更新できない場合は、まず関連プロトコルモジュールに依存しているかを確認します。

V12 が示す緩和方向は Dirty Frag と同じです。システムが IPsec ESP や RxRPC に依存していない場合、esp4、esp6、rxrpc などのモジュール無効化を検討できます。ただしネットワーク機能に影響するため、本番環境で不用意に実行すべきではありません。IPsec、VPN、トンネル、関連するカーネル機能を業務で使っているか確認が必要です。

より安全な対応順序は次の通りです。

ディストリビューションがカーネルのセキュリティ更新を公開しているか確認する。
まずカーネルパッチをインストールし、再起動を計画する。
すぐに更新できない場合のみ、一時的なモジュール無効化を評価する。
複数ユーザーシステムと CI / ビルド環境を優先する。
不要なローカルアカウント、Shell、コンテナ脱出面、低権限実行入口を確認する。

モジュール無効化を最終修復とみなすべきではありません。これは露出面を一時的に下げる手段です。

すでに悪用された疑いがある場合

Fragnesia の特徴の一つはページキャッシュ汚染です。V12 は、悪用後に対象ファイルのページキャッシュ上のコピーが注入内容を含み、ページが追い出されるかシステムが再起動されるまで、後続の実行で異常な挙動を起こし得ると説明しています。

悪用が疑われる場合は、少なくとも次を実施します。

できるだけ早くログと監査記録を保全する。
最近の異常なローカルログイン、低権限ユーザー活動、不審なプロセス、root shell の痕跡を確認する。
関連するページキャッシュをクリアするか、直接再起動する。
修正済みカーネルへ更新する。
重要バイナリの整合性を確認する。ただしディスク hash のみに依存しない。
露出した可能性のある認証情報と鍵をローテーションする。

本番サーバーであれば、単なる通常のパッチ適用ではなく、潜在的なローカル権限昇格インシデントとして扱う方が安全です。

優先して確認すべきマシン

この種の脆弱性では、すべての Linux マシンを同じ優先度で扱うのではなく、攻撃者が低権限コード実行を得やすい場所から見るべきです。

優先度が高い環境は次の通りです。

複数ユーザーのログインサーバー
CI / CD runner
ビルドマシン
共有開発機
コンテナホスト
VPS とクラウドサーバー
SSH を公開しているエッジノード
サードパーティ製スクリプトやプラグインを実行するプラットフォーム

閉じた単一ユーザー環境で外部コード実行入口がないマシンも、脆弱であれば影響はあります。ただし緊急度は相対的に下げられます。

まとめ

Fragnesia が注目に値するのは名前が新しいからではありません。Linux のローカル権限昇格問題を、ページキャッシュとカーネルネットワークサブシステムの複雑な境界へ再び引き戻したからです。

管理者にとって重要なのは、攻撃手順を研究することではなく、カーネルのパッチ状態を確認し、ESP / RxRPC への依存を評価し、露出度の高いマシンを優先して更新し、「ディスクファイルが変わっていない」ことが「システムが影響を受けていない」ことを意味しないと理解することです。

影響を受けるシステムでは、最終的な答えはディストリビューションが提供するカーネル更新をできるだけ早く適用することです。一時的なモジュール無効化は移行措置であり、パッチの代替ではありません。