CVE-2026-42945（NGINX Rift）とは。NGINX rewrite 脆弱性で確認すること

2026年5月13日、NGINX の ngx_http_rewrite_module に CVE-2026-42945 が公開されました。

日本時間だと 2026年5月14日に話題になっているやつです。

通称は NGINX Rift。

「18年前からある NGINX の RCE」みたいな見出しも出ています。

まあ、見出しとしては強い。

ただ、2026年5月14日時点の情報を見る限り、これは「NGINX を使っている全サーバーが即 RCE」という話ではありません。

一方で「ASLR が有効なら無視していい」という話でもないです。

特定の rewrite 設定パターンがあると、外部から細工した HTTP リクエストで NGINX worker をクラッシュさせられます。

ASLR が無効な環境では、任意コード実行まで行ける可能性があります。

ASLR が有効な環境でも、クラッシュによる DoS は残りますし、将来的に別条件と組み合わせた攻撃が出ないとも言い切れません。

なので、騒ぎすぎず、でも放置もしない。

この温度感で確認しておくのがよさそうです。

概要

なお、nginx.org の security advisories 上では severity は medium と表示されています。

この記事では、F5 / CNA の CVSS 評価を併記しています。

NVD の説明では、rewrite ディレクティブと unnamed PCRE capture、つまり $1 や $2 のような番号付きキャプチャ、さらに ? を含む置換文字列、後続の rewrite / if / set の組み合わせが条件として挙げられています。

たとえば、危ない形をかなり単純化すると、こういう雰囲気です。

location ~ ^/api/(.*)$ {
    rewrite ^/api/(.*)$ /internal?migrated=true;
    set $original_endpoint $1;
}

もちろん、これと完全一致する設定だけが危ない、という意味ではありません。

見るべきなのは、同じスコープの中で rewrite、?、$1 / $2、後続の rewrite / if / set が絡んでいないか、です。

何が起きるのか

原因は、rewrite の置換文字列を処理するときのサイズ計算と、実際に書き込むときのエスケープ処理がずれることです。

depthfirst の説明では、rewrite と set の処理の流れで is_args の扱いがずれ、必要なバッファサイズを小さく見積もってしまう、という整理になっています。

NGINX は最初に「このくらいのバッファが必要」と計算します。

ところが、実際にコピーする段階では URI の一部が再エスケープされ、+、%、& などが展開されます。

計算時よりも大きいデータを書き込むことになり、heap buffer overflow になります。

攻撃者がリクエスト URI 側で一部のデータをコントロールできるため、単なるランダムクラッシュではありません。

ただし、任意コード実行まで安定して持っていけるかは別の話です。

depthfirst の技術記事では ASLR 無効環境で RCE の PoC が示されています。一方で AlmaLinux 側も、ASLR が有効な標準構成で汎用的に安定した RCE にするのは簡単ではない、という見方を出しています。

ここは大事です。

「RCE と書いてあるから全台即侵害」でもないし、「ASLR があるからノーダメ」でもない。

worker を落とせるだけでも可用性の問題としては十分に嫌ですし、PoC が公開されている以上、攻撃側の調査も進みます。

影響を受けるか確認する

まず NGINX のバージョンを見ます。

nginx -v
nginx -V 2>&1

ただし、ここで nginx/1.24.0 のような古い本家バージョン番号が出たからといって、即アウトとは限りません。

Ubuntu、Debian、RHEL 系などは、上流のバージョン番号を大きく変えずにセキュリティパッチだけバックポートすることがあります。

なので、実運用では「本家のバージョン番号」だけで判断しないほうがいいです。

見るべきなのは、自分が使っている配布元の advisory とパッケージ changelog です。

# Ubuntu / Debian 系
apt policy nginx
apt changelog nginx | grep -i -C3 'CVE-2026-42945'

# RHEL / AlmaLinux / Rocky / Fedora 系
rpm -q nginx
rpm -q --changelog nginx | grep -i -C3 'CVE-2026-42945'

# Alpine
apk info -v nginx

コンテナイメージを使っている場合は、ベースイメージ側も見ます。

docker run --rm <image> nginx -v

ここも同じで、単純な表示バージョンだけではなく、イメージの配布元が CVE-2026-42945 の修正を取り込んでいるかを確認します。

rewrite 設定を確認する

次に、設定側です。

ngx_http_rewrite_module 自体は標準的な NGINX で普通に入っています。

ただ、脆弱性のトリガーには設定条件があります。

まずは全設定を展開して、rewrite、set、if を拾います。

sudo nginx -T 2>/dev/null | grep -nE '\b(rewrite|set|if)\b'

さらに、番号付きキャプチャを使っている箇所も見ます。

sudo nginx -T 2>/dev/null | grep -nE '\$[0-9]'

rewrite の置換先に ? があり、同じ server / location 内で $1 や $2 を使った後続の rewrite / if / set があるなら、かなり注意です。

grep だけで完全判定するのは無理です。

include で分割されていたり、管理ツールが設定を生成していたり、Ingress / WAF / コントロールパネルが裏側で NGINX を持っていたりします。

なので、grep はあくまで足がかりです。

すぐ更新できない場合の設定回避

F5 / depthfirst 側の説明では、すぐに更新できない場合の回避策として、番号付きキャプチャを named capture に置き換える方向が挙げられています。

たとえばこういうイメージです。

# 避けたいパターン
rewrite ^/users/([0-9]+)/profile/(.*)$ /profile.php?id=$1&tab=$2 last;

# named capture に寄せる
rewrite ^/users/(?<user_id>[0-9]+)/profile/(?<section>.*)$ /profile.php?id=$user_id&tab=$section last;

ただし、rewrite はアプリのルーティングやリダイレクトに絡むので、雑に置き換えると普通にサービスが壊れます。

設定回避はあくまで暫定策です。

本命は修正済みパッケージへの更新です。

ASLR は確認しておく

Linux では、次の値が 2 なら ASLR が有効です。

cat /proc/sys/kernel/randomize_va_space

ほとんどの一般的な Linux 環境では有効のはずです。

今回の脆弱性に限って言えば、ASLR が有効な環境では任意コード実行まで一直線に成功するケースは多くないと考えられます。

ただし、ASLR は脆弱性そのものを消す仕組みではありません。

クラッシュによる DoS は残りますし、環境次第では情報漏えいや別の条件と組み合わせて ASLR がバイパスされる可能性もあります。

randomize_va_space が 0 だった場合は、かなり嫌です。

理由があって無効化している環境以外では、有効化を検討したほうがいいです。

sudo sysctl -w kernel.randomize_va_space=2

永続化するなら /etc/sysctl.conf や /etc/sysctl.d/*.conf 側も確認します。

対応方針

やることは地味です。

1. NGINX を使っている場所を洗い出す
2. 配布元の advisory / changelog で CVE-2026-42945 の修正有無を見る
3. 修正済みパッケージへ更新する
4. 必要に応じて NGINX を restart し、新しいバイナリで動いているか確認する
5. rewrite 設定に危ないパターンがないか確認する
6. すぐ更新できない場合は named capture 化などの設定回避を検討する
7. ASLR が無効になっていないか確認する

NGINX Open Source を公式配布で入れているなら、1.30.1 または 1.31.0 以降へ更新します。

nginx -v
sudo nginx -t
sudo systemctl restart nginx

パッケージ更新後に、本当に新しい worker が動いているかも見ます。

ps -eo pid,lstart,cmd | grep '[n]ginx'

Docker / Kubernetes の場合は、イメージの rebuild / redeploy が必要です。

ホストのパッケージだけ更新しても、古い NGINX 入りコンテナがそのまま動いていたら意味がないです。

今回やらないほうがいい判断

まず、「NGINX のバージョンが 1.30.0 以下だから全部アウト」と騒ぐのは雑です。

ディストリビューションのパッケージは、枝番レベルではパッチ済みなのに、表示上の上流バージョン番号は古いまま、ということが普通にあります。

セキュリティスキャナの結果を見るときも同じです。

CVE が出た直後は、スキャナ側がディストリビューションのバックポート状況を追いきれていないことがあります。

逆に、「うちは ASLR 有効だから対応不要」も雑です。

ASLR は RCE の難易度を上げる仕組みであって、脆弱な rewrite パターンを安全に変えるものではありません。

この脆弱性は外部からリクエストを投げられる場所にあるので、インターネット公開 NGINX なら確認の優先度は高めでいいです。

大げさに騒ぐ必要はないけど、週明けまで寝かせるタイプでもないかなと。

参考リンク

• NVD - CVE-2026-42945
• nginx security advisories
• NGINX Rift - depthfirst
• NGINX Rift: Achieving NGINX Remote Code Execution via an 18-Year-Old Vulnerability - depthfirst
• NGINX Rift（CVE-2026-42945）: Patched nginx available in testing - AlmaLinux
• F5 Security Advisory K000161019
• NGINXのrewrite脆弱性 CVE-2026-42945 「NGINX Rift」は何を確認すべきか - ワルブリックス株式会社