TITLE

nginx 緊急脆弱性 CVE-2026-42533 — 危険なのは「regex location × regex map」構成だけ、今すぐ確認すべきこと

投稿日：2026.07.21

何が起きたか

nginx の公式ニュースによれば、2026年7月15日のリリースで CVE-2026-42533 のほか、CVE-2026-60005(ngx_http_slice_module のメモリ情報漏洩)と CVE-2026-56434(ngx_http_ssi_module の use-after-free)も同時に修正されています。本記事で扱うのは CVE-2026-42533 のみです。The Hacker News の報道では、CVSS v4 が 9.2、CVSS v3.1 が 8.1 とされ、いずれも Critical 相当の評価です。脆弱性は map ディレクティブを regex と併用した際に発生する buffer overflow(バッファオーバーフロー)で、発見は Winfunc Research の Mufeed VH 氏と nginx メンテナの Maxim Dounin 氏、加えて 12 名の独立研究者が F5 に報告し、研究者 Stan Shaw 氏(cyberstan)が詳細分析を公開しています。

原因は nginx の内部で使われている「二段階(two-pass)スクリプト評価」という仕組みにあります。nginx は $1 のような正規表現キャプチャを含む文字列を組み立てる時、まず必要なバッファサイズを測る measuring パス(LEN)を実行し、そのサイズでメモリを確保してから、実際の値を書き込む writing パス(VALUE)を実行します。ここで、location の regex キャプチャより後に regex map の出力変数を同じ式の中で参照する構成があると、LEN パスと VALUE パスの間で map の regex が再評価され、$1 などの番号付きキャプチャの中身がすり替わってしまいます。LEN パスでは短い値を基準にバッファを確保したのに、VALUE パスでは攻撃者が X-Input ヘッダー経由で送り込んだ長い値が書き込まれる、というズレが起きるのが根本原因です。私たちはこのメカニズムを「二段撮りのキャプチャすり替え」と呼んでいます。

CVE-2026-42533 の原因メカニズム: LENパスがlocationのregexキャプチャ$1(短い値)でバッファサイズを計算 → その後mapのregexが再評価されキャプチャが攻撃者の長い値に上書き → VALUEパスが長いキャプチャで書き込み → 確保サイズ<書き込みサイズでヒープオーバーフロー

DevelopersIO(クラスメソッド)の検証では、脆弱版(1.30.3)と修正版(1.30.4)を Docker 上に並べ、1回の GET リクエストでヒープ上の情報が漏洩する挙動を再現し、修正版では解消されることを確認しています。同記事は RCE(リモートコード実行)の実演までは行っておらず、NGINX Plus およびストリームモジュールでのトリガーも検証範囲外としています。The Hacker News によれば、影響は主に worker プロセスのクラッシュと再起動による DoS(サービス拒否)で、特定条件下では RCE に発展する可能性があるとされています。ただし断定的な報告ではありません。Stan Shaw 氏は、既定の Ubuntu 24.04 ビルドではこの欠陥自体が ASLR(アドレス空間配置のランダム化)を回避する能力を攻撃者に与えると論じています。

なお、2026年7月20日時点で公開されているエクスプロイトコードはなく、CISA の Known Exploited Vulnerabilities カタログにも掲載されていません。Stan Shaw 氏はパッチ公開の21日後、8月5日頃に PoC(概念実証コード)を公開する予定だと述べています。裏を返せば、この記事を読んでいる今が、実際の攻撃コードが出回る前に対処できる時間的猶予がある期間だということです。

誰が該当するか

該当を確認する観点は 2 つです。どちらか一方だけでなく、両方を確認してください。

1つ目はバージョンです。nginx -v で確認し、stable 系は 1.30.4 未満、mainline 系は 1.31.3 未満、NGINX Plus は 37.0.3.1 未満であれば影響範囲に入ります。DevelopersIO の整理では、stable 0.9.6〜1.30.3・mainline 〜1.31.2・NGINX Plus R33〜R36 および 37.0.0.1〜37.0.2.1 が対象で、それぞれ 1.30.4・1.31.3・R36 P7 または 37.0.3.1 で修正されています。

2つ目は設定ファイルです。脆弱性が発火するのは、regex を使った location ブロック(location ~ "パターン")と regex を使った map ディレクティブを組み合わせ、location 側の番号付きキャプチャ($1 など)が map の出力変数より前に、同じ文字列式の中で参照されている構成です。DevelopersIO が検証に使った構成の要点は次のようなものです(既に公開されている識別用の構成例で、攻撃コードではありません)。

# http ブロック
map $http_x_input $mapped_var {
    default "nomatch";
    ~^(?<cap>.+)$ "matched";
}

# server ブロック内
location ~ "^/test/(.+)$" {
    add_header X-Debug "$1--$mapped_var--$1" always;
}

ポイントは、add_header や return のように 1 つの文字列式の中で location 由来の $1 と map の出力変数(この例では $mapped_var)を両方使っている点です。map ディレクティブ自体を持っていても、location の regex キャプチャと同じ式の中で組み合わせて使っていなければ、この経路では発火しません。逆に言えば、リバースプロキシ設定でヘッダーの出し分けやルーティングのために regex location と regex map を併用している構成は、確認の優先度が高くなります。今回この記事を書くにあたって私たちが最初に確認したのも、まさにこの2点(バージョンと、regex location・regex map の同居有無)でした。

対処: アップグレードが唯一の完全な対処

該当することが分かったら、優先すべきはアップグレードです。stable なら 1.30.4、mainline なら 1.31.3、NGINX Plus なら 37.0.3.1 へ上げれば、この脆弱性は解消されます。

すぐにアップグレードできない場合のワークアラウンドとして、該当する regex map を番号付きキャプチャでなく named capture((?<name>...) の形式)に切り替える方法が挙げられています。ただし、この対処は不完全です。Stan Shaw 氏の分析によれば、map が location の regex と同じ named group を定義している場合、named capture 化しても別のコード経路でオーバーフローに到達する経路が残ります。つまり、named capture 化は多くのケースでリスクを下げますが、構成によっては効かないケースが残ることが確認されています。完全な緩和策はパッチ版へのアップグレードのみです。ワークアラウンドは「今すぐアップグレードできない間の時間稼ぎ」であって、恒久対処の代替にはならないと理解しておく必要があります。

なぜ15年見つからなかったか — 二段階評価という設計上の盲点

DevelopersIO の指摘によれば、この脆弱性の原因コードは 2011年3月リリースの nginx 0.9.6 から存在し、約15年間気づかれずに残っていました。世界で最も広く使われている Web サーバーの一つで、この規模の見落としが15年続いていたことになります。

手がかりは、原因である二段階評価の構造そのものにあります。LEN パス(バッファサイズの計測)と VALUE パス(実際の書き込み)は、それぞれ単体で見れば正しく動作します。一般に、コードレビューやテストは各パスを個別に検証する形になりやすいものです。しかし今回の脆弱性は、2 つのパスの「間」で regex map が再評価され、キャプチャの中身がすり替わるという、両方のパスを跨いだ挙動のズレによって生じています。1 パスずつを見ている限り異常は見えず、location の regex キャプチャと map の regex 出力を同じ式の中で組み合わせるという、比較的限定的な構成を通した時にだけ表面化する — この「合わせて初めて壊れる」性質が、15年という長い期間、発見を遠ざけていたと考えられます。

まとめ

CVE-2026-42533 は Critical 評価の脆弱性ですが、今回押さえておきたいのは「危ないのは全部じゃない」という事実です。nginx を使っているというだけでは判断できず、regex location と regex map を同じ式の中で組み合わせている構成だけが対象になります。原因は「二段撮りのキャプチャすり替え」— LEN パスで測った後、VALUE パスまでの間に map の regex が再評価され、想定より長い値がバッファに書き込まれてしまう二段階評価の設計上のズレでした。該当する場合、named capture 化のようなワークアラウンドは残存経路が指摘されており不完全です。唯一の完全な対処はアップグレード(1.30.4 / 1.31.3 / NGINX Plus 37.0.3.1)であり、それが今回の実務上の結論です。8月5日頃に PoC 公開が予定されている以上、対応の優先度を下げる理由はありません。