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

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 への依存を評価し、露出度の高いマシンを優先して更新し、「ディスクファイルが変わっていない」ことが「システムが影響を受けていない」ことを意味しないと理解することです。

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