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

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、アップグレード候補を確認します。

1
2
3
4


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