脆弱性分析 on KnightLiブログ

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 ルールを整理します。

参考リンク

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

Fri, 01 May 2026 18:42:34 +0800

Copy Fail は Linux カーネルのファイルコピー経路に影響する脆弱性で、CVE-2026-31431 として管理されている。 Bugcrowd の分析では、これは注意すべきカーネルレベルの問題とされている。特定の条件下で、非特権ユーザーがファイルコピー関連のロジックを悪用し、不正な書き込みを引き起こせる可能性があり、その結果として権限昇格やコンテナエスケープにつながる。

リスクの観点では、これは通常のアプリケーション層の脆弱性ではない。問題はカーネルがファイルコピーとページキャッシュを処理する経路で発生するため、影響はコンテナ、共有ホスト、CI/CD Runner、PaaS プラットフォーム、マルチテナント Linux 環境にまで及ぶ。攻撃者がすでにシステム内で低権限コードを実行できる場合、この脆弱性は隔離境界を突破するための足がかりになり得る。

脆弱性はおおよそどこで発生するのか

Copy Fail は Linux カーネルのファイルコピー機能に関係している。現代の Linux には、copy_file_range、splice 系の経路、異なるファイルシステム間のデータコピー最適化など、複数の効率的なコピー経路がある。これらの仕組みは、ユーザー空間とカーネル空間の間のデータ移動を減らし、大きなファイルコピーの性能を高めるために用意されている。

問題は、高性能なコピー経路がページキャッシュ、ファイルオフセット、権限チェック、ファイルシステムコールバックを再利用することが多い点にある。どこかの境界条件の処理が厳密でない場合、カーネルが誤った権限コンテキストで書き込みを行ったり、本来攻撃者が変更できないデータページを制御できる形で露出したりする可能性がある。

Copy Fail の主なリスクは次のように整理できる。

攻撃者は root 権限を必要としない。
攻撃入口は一般的なファイルコピー機能にある。
影響点はカーネル空間にある。
コンテナ環境では、namespace やマウント隔離を迂回する可能性がある。
悪用に成功すると、コンテナが変更できないはずのホスト上の内容へ書き込める可能性がある。

これが Copy Fail が大きく取り上げられる理由である。コンテナセキュリティは Linux カーネルが提供する隔離機能に依存している。カーネル経路そのものに不正書き込みがあると、コンテナ境界は脆くなる。

なぜコンテナ環境でより敏感なのか

コンテナは仮想マシンではない。コンテナ内のプロセスとホストは同じ Linux カーネルを共有しており、namespace、cgroup、capability、seccomp、AppArmor/SELinux などの仕組みによって隔離されている。

脆弱性がユーザー空間サービスにある場合、通常は一つのコンテナや一つのプロセスに影響が限定される。しかし脆弱性がカーネルにあり、しかも非特権ユーザーからトリガーできる場合、攻撃者はコンテナ内部からホストへ影響を及ぼす可能性がある。

Copy Fail の危険性はここにある。多くのプラットフォームでは、ユーザーがビルドジョブを投入したり、スクリプトを実行したり、コンテナを起動したり、プラグインを動かしたりできる。攻撃者がコンテナ内でコードを実行できるだけで、カーネルのファイルコピー経路を利用して隔離を突破しようとする可能性がある。

高リスクな環境には次のようなものがある。

Kubernetes クラスター内の信頼できないワークロード。
CI/CD プラットフォームの共有 Runner。
ユーザーがコードをアップロードして実行できるサンドボックス。
マルチテナント Linux ホスト。
コンテナ化された PaaS。
サードパーティ製プラグインや拡張を実行するシステム。

これらの環境で影響を受けるカーネルが使われており、追加の制限が不足している場合、リスクは明らかに高まる。

影響範囲はカーネルのパッチ状態を見る必要がある

この種の脆弱性は、ディストリビューション名だけでは判断できない。同じ Ubuntu、Debian、RHEL、Fedora、Arch であっても、影響を受けるかどうかは実際に実行中のカーネルパッケージと、ディストリビューションが修正をバックポート済みかどうかに依存する。

調査では、まず次の三点を確認する。

現在実行中のカーネルバージョン。
ディストリビューションのセキュリティアドバイザリに CVE-2026-31431 が含まれているか。
クラウドベンダーやマネージドプラットフォームがホストカーネルを修正済みか。

まずシステム上でカーネルバージョンを確認する。

`1`	`uname -a`

そのうえで、ディストリビューションのセキュリティアドバイザリ、カーネル changelog、クラウドプラットフォームの告知を確認する。多くのエンタープライズディストリビューションは古いカーネルブランチへセキュリティ修正をバックポートするため、メジャーバージョンだけで安全かどうかを判断してはいけない。

一時的な緩和策

最も確実な修正はカーネル更新である。ただし、すぐにパッチを展開できない環境では、まず露出面を下げることができる。

一般的な緩和の方向性は次の通り。

信頼できないユーザーに特権コンテナを実行させない。
コンテナへ機密性の高いホストパスをマウントしない。
コンテナの capability を絞り、特に不要な CAP_SYS_ADMIN を付与しない。
seccomp、AppArmor、SELinux で危険なシステムコールとファイルアクセスを制限する。
信頼できないワークロードを、より隔離の強い仮想マシンへ移す。
CI/CD Runner はジョブごとに破棄し、同じホストを長期間使い回さない。
異常なファイル書き込み、権限変更、コンテナエスケープの兆候を監視する。

これらの対策はパッチの代替にはならない。目的は、パッチが本番環境に届くまでの間、悪用成功率と影響範囲を下げることである。

修正の優先順位

環境のリスクに応じて優先順位を付けるのがよい。

優先して修正すべきもの：

外部にコンテナ実行機能を提供するプラットフォーム。
信頼できないコードを実行する CI/CD ノード。
マルチテナント Kubernetes ノード。
ユーザー定義プラグインやスクリプト実行機能を持つシステム。
共有開発機、教育用マシン、実験環境。

相対的に優先度が低いもの：

単一ユーザーのデスクトップ。
信頼済みサービスだけを実行する内部ホスト。
信頼できないコードをすでに仮想マシンで隔離している環境。

リスクが低い場合でも、ディストリビューション経由でカーネルを更新することを推奨する。カーネル脆弱性はより複雑な攻撃チェーンに組み込まれることが多く、パッチを遅らせる利点はあまりない。

運用チーム向けチェックリスト

次の順序で対応できる。

すべての Linux ホストとコンテナノードを棚卸しする。
信頼できないコードを実行するマシンを特定する。
現在のカーネルバージョンとディストリビューションのセキュリティアドバイザリを確認する。
高リスクノードを優先して更新する。
すぐに更新できないノードには一時的な隔離ポリシーを適用する。
コンテナランタイム設定を確認し、不要な特権とホストマウントを削除する。
更新後にノードを再起動し、新しいカーネルが実際に有効になっていることを確認する。
後続の監査に備えて変更記録を残す。

カーネルパッケージをインストールしただけでは、システムが新しいカーネルで動いているとは限らない。更新後は必ず再起動し、再度確認する。

`1`	`uname -a`

まとめ

Copy Fail / CVE-2026-31431 の要点は、どこかのアプリケーションがクラッシュすることではなく、Linux カーネルのファイルコピー経路に権限境界の問題があることだ。非特権コードが、より高い権限のデータ書き込み経路へ触れる機会を持つため、コンテナ環境やマルチテナント環境では特に注意が必要である。

この種の脆弱性に対応するうえで重要なのは次の二点だ。

ディストリビューションまたはクラウドベンダーが提供するカーネルパッチをできるだけ早く適用する。
パッチ展開前は、信頼できないコード、特権コンテナ、機密性の高いホストマウントを制限する。

個人デスクトップでは、すぐに慌てる必要がある問題ではないかもしれない。しかし、コンテナプラットフォーム、CI/CD、サンドボックス、共有ホストを運用しているチームにとっては、高優先度のカーネルセキュリティ更新として扱うべきである。

参考ソース：