英語版で読む
技術 約5分で読めます

nginxの18年越しrewrite脆弱性CVE-2026-42945は設定パターン次第で未認証RCEに届く

セキュリティ CVE nginx 脆弱性 RCE
いけさん目次

TL;DR

影響 nginx 0.6.27〜1.30.0、nginx Plus、Ingress Controller、WAF製品群など。ngx_http_rewrite_module を使い、特定の rewrite / if / set の並びを持つ設定

対応 nginx 1.30.1 stableまたは1.31.0 mainlineへの更新。nginx Plusや関連製品はF5の各アドバイザリに沿った修正版

暫定 更新まで rewrite の無名PCREキャプチャ（$1、$2 など）と ? を含む置換文字列、その後に続く rewrite / if / set の確認

F5が2026年5月13日に、nginxの ngx_http_rewrite_module にあるCVE-2026-42945を公開した。
nginx 0.6.27から1.30.0までが影響を受け、修正版は1.30.1 stableと1.31.0 mainline。
NVD上のCNA（CVE採番機関、今回はF5）評価はCVSS v4.0で9.2 CRITICAL、CVSS v3.1で8.1 HIGHになっている。

嫌なのは「nginxを使っているだけで即RCE」ではなく、「昔からあるrewrite設定の一部が、細工されたURIでワーカープロセスのヒープ破壊に落ちる」形である点だ。
構成依存なのでスキャナーのバージョン判定だけでは足りない。
nginxの設定ファイル、テンプレート生成、移行ツールが吐いたrewriteを見ないと、自分の環境が踏むかどうか分からない。

壊れていたのはrewriteのバッファ計算

発火条件はかなり具体的だ。
F5アドバイザリを引用したoss-sec投稿とNVDの説明では、rewrite ディレクティブの後に rewrite、if、set のいずれかが続き、無名PCREキャプチャ（$1、$2 など）と ? を含む置換文字列を組み合わせた場合に問題が出る。

Depthfirstの技術メモでは、nginxが出力先バッファをあるエスケープ前提で計算し、実際の書き込みでは別のエスケープ前提で書くため、確保済み領域を越えて書き込むと説明されている。
結果は nginx worker process のヒープベースバッファオーバーフロー（CWE-122）。
通常はワーカーのクラッシュと再起動に見えるが、ASLR（Address Space Layout Randomization、メモリアドレスをランダム化して悪用を難しくする仕組み）が無効なシステムではコード実行まで届く。

# 形だけを示す例。公開環境でこのまま使うものではない。
rewrite ^/old/(.*)$ /new?path=$1 last;
set $marker "value";

URIに含まれる攻撃文字列だけでなく、サーバー側の設定が条件になる。
古いPHPアプリ、CMS移行、.htaccess 由来の変換、管理画面から投入されたカスタムsnippetがある環境では、手書き設定よりも生成済み設定のほうに残っていることがある。

1.30.1はCVE-2026-42945だけの更新ではない

nginx.orgの2026年5月13日の告知では、1.30.1 stableと1.31.0 mainlineで複数の脆弱性が同時に修正されている。
同じリリースに、ngx_http_proxy_module のHTTP/2 request injection、ngx_http_scgi_module / ngx_http_uwsgi_module のbuffer overread、ngx_http_charset_module のbuffer overread、HTTP/3のaddress spoofing、OCSP resolverまわりのuse-after-freeも含まれる。

セキュリティ一覧ではCVE-2026-42945自体のSeverityはmedium表記だが、NVDのCNAスコアはCVSS v4.0で9.2になっている。
このズレは、nginx側が「設定条件つき」「ASLRの影響あり」と見ている一方で、CNAスコアは認証不要・ネットワーク到達・機密性/完全性/可用性への高影響を強く反映しているためだと読める。
パッチ判断では「mediumだから後でいい」より、対象設定があるか、公開エンドポイントに届くか、ワーカー権限で何を読めるかを見るほうが現実に近い。

NIST NVDがCVE全件エンリッチメントを断念した件でも書いたが、公開直後のCVEはNVDがまだAwaiting Enrichmentのままでも、CNA情報やベンダーadvisoryのほうが先に判断材料を持っている。
今回もNVDページにはF5由来の説明、CVSSベクタ、CWE-122が入っているが、NVD自身の解析はまだ付いていない。

nginx-uiのCVEとは別物

4月に書いたnginx-uiのMCPエンドポイント認証欠如は、nginx本体ではなくWeb管理ツール側の認証バイパスだった。
あちらは /mcp_message へ未認証で到達し、設定ファイルを読み書きできるという管理面の問題。
今回のCVE-2026-42945は、nginx本体のrewrite処理に残っていたメモリ破壊だ。

ただし、運用上はつながる。
nginx-uiのような管理ツール、ホスティングパネル、.htaccess 変換器が、ユーザー入力からnginx設定を生成している場合、CVE-2026-42945の条件を満たすrewriteを知らないうちに置いていることがある。
「nginx -t が通る設定」でも、この脆弱性の条件を避けている保証にはならない。

更新までに見る設定

最短はnginxを1.30.1または1.31.0へ上げることだ。
パッケージ配布を待つ環境では、設定側の確認を先に走らせる。

探す対象は、rewrite、無名キャプチャ、? を含む置換文字列、後続の rewrite / if / set の組み合わせ。
単純な grep rewrite だけだと、includeされたsnippetやテンプレート生成後の実体を落としやすい。
nginx -T で展開後の設定を出し、vhost、location、includeされたconfをまとめて見るほうが早い。

Kubernetes側ではIngress ControllerやWAF製品群も影響範囲に入る。
ただ、IngressのアノテーションやConfigMapが最終的にどんなnginx設定へ展開されるかはコントローラ実装とバージョンで変わる。
マニフェストだけ見て安心せず、実際に生成された nginx.conf まで確認する。

どうでもいいけど、いまだにrewriteルールを空で書けないし、一発で利かせられたためしがない。
このサイトのラボにも.htaccessジェネレーターがあるので、AIに全部任せたくない人はそちらをどうぞ。

参考