NGINXの未認証ヒープバッファオーバーフロー(CVE-2026-42533)。map正規表現の二段階評価がバッファを壊す機構

世界のWebサイトの多くが、配信の前段にNGINXを置いています。Webサーバーとして、リバースプロキシとして、ロードバランサーとして、ユビキタスに使われるこのソフトウェアの本体に、認証を通さずにワーカープロセスを壊せる脆弱性が見つかりました。CVE-2026-42533です。種類はヒープバッファオーバーフロー(CWE-122)で、細工したHTTPリクエスト一つで発火します。ただし誰の環境でも刺さるわけではなく、発火するのは特定のmapディレクティブと正規表現キャプチャを組み合わせた設定に限られます。この記事は、Webサーバーやリバースプロキシを運用する開発者や情報システムの担当者に向けて、何がどう壊れるのかという機構と、確認すべき対象、対応の順序を、nginx公式アドバイザリ、NVD、F5のアドバイザリをもとに整理します。攻撃を再現する細工リクエストや実証コードは扱いません。事実は執筆時点(2026年7月26日)で確認できた範囲に限ります。

どんな製品でどこに影響するか#

NGINXは、HTTPの受け口として幅広く使われるソフトウェアです。単体のWebサーバーとして静的コンテンツを返すだけでなく、背後のアプリケーションサーバーへ振り分けるリバースプロキシや、複数のバックエンドへ負荷を分けるロードバランサーとして、インターネットとアプリケーションの境界に置かれます。KubernetesのIngressコントローラーやAPIゲートウェイの内部でも動いており、直接インストールした覚えがなくても、基盤の一部として稼働している場合があります。

この位置づけが、今回の脆弱性の影響範囲を広げます。境界に置かれるということは、外部からの到達性が高いということです。CVE-2026-42533は認証を必要とせず、細工したHTTPリクエストで発火するため、該当する設定のNGINXが公開されていれば、リクエストを届けられるだけで狙われます。ただし前提として、発火するのは後述する特定のmap設定を持つ環境に限られる点は、影響範囲を見積もるうえで重要な区別になります。

発火する設定条件#

この脆弱性は、NGINXを動かしていれば一律に刺さるものではありません。F5のアドバイザリとNVDは、成立条件を主にmapディレクティブの使い方で説明しています。

具体的には、mapディレクティブが正規表現マッチを使っていて、なおかつ文字列式がmapの出力変数を参照するより前に、その正規表現のキャプチャ変数($1などの取り込みグループ)を参照している構成のときに成立します。F5とNVDは、これとは別に、特定の条件下では文字列式のなかでキャッシュ不可能変数(non-cacheable variable)を使う場合にも同じ結果に至りうるとしています。したがって、自組織のnginx.confとインクルードされる設定ファイルで、正規表現を伴うmapブロックと、その出力を使う変数式の記述順を確認することは影響判定の出発点になりますが、成立経路が一つに限られないため、設定の点検だけで安全と判断せず、更新を優先する前提で進めるのが安全です。

NVDのページはCVE-2026-42533を、mapディレクティブが正規表現マッチを使い、文字列式がmapの出力変数を参照する前にその正規表現キャプチャ変数を参照するときにNGINXワーカープロセスでヒープバッファオーバーフローが起きうる脆弱性と記載し、特定条件下では文字列式でキャッシュ不可能変数を使う経路でも同じ結果になりうるとしています。CWEはCWE-122で、CVSS(v3.1で8.1、v4.0で9.2)はNVD自身ではなく採番機関のF5 Networksによる評価としてNVDページに掲載されています。

二段階評価で測長と書き込みがずれる機構#

問題の核心は、NGINXが設定内の文字列式をリクエストのたびに組み立てる仕組み、いわゆるスクリプトエンジンにあります。このエンジンは文字列を二段階(two-pass)で評価します。1回目のパスで、組み立てる結果に必要なバッファの長さを測ります。2回目のパスで、そのバッファへ実際にデータを書き込みます。確保と書き込みを別のパスに分けるこの設計が、今回のずれの土台になっています。

正規表現mapの出力をキャプチャ変数より後に参照する構成では、1回目のパスと2回目のパスとで、参照される正規表現のキャプチャ状態が食い違います。1回目はあるキャプチャ状態のもとでバッファ長を見積もり、2回目は別の、攻撃者が制御しうるデータのもとで書き込みます。この1回目と2回目でキャプチャ状態がそろわないことが、測長と書き込みのずれを生みます。結果として、測った長さより長いデータが書き込まれ、確保したヒープ領域の境界を越えます。境界を越えた書き込みが隣接するメモリを壊すというバッファオーバーフローの原理そのものは、次の記事で基礎から整理しています。

あわせて読みたい

バッファオーバーフローの仕組みと対策。境界を越えた書き込みがコード実行に至る理由

nginx公式のセキュリティアドバイザリは、CVE-2026-42533をmapと正規表現を使ったときのバッファオーバーフローとし、影響を受ける版を0.9.6から1.31.2、修正版を1.31.3以降および1.30.4以降と記載しています。

DoSとRCEを分ける条件#

境界を越えた書き込みがどこまでの被害になるかは、環境の防御機構によって変わります。F5はこの脆弱性の既定の影響を、ワーカープロセスのクラッシュや再起動によるサービス妨害(DoS)と位置づけています。ヒープを壊された結果ワーカーが落ちて再起動する状態で、可用性が損なわれます。

そのうえでF5は、ASLR(アドレス空間配置のランダム化)が無効または回避可能な環境では、任意コード実行(RCE)に至りうるとしています。ASLRはメモリの配置を実行のたびに変え、攻撃者が書き込み先や飛び先を予測しにくくする緩和です。これが効いている限り制御奪取の難易度は高く、外れれば書き込んだ内容を実行の流れへ結びつけられる余地が生まれます。なお研究者のStan Shaw氏は、この脆弱性がASLR回避の手がかりを自ら供給しうると指摘し、既定構成でもDoSだけにとどまらない可能性を主張しています。評価には幅があるため、DoSに限られると決めつけず、RCEの可能性も織り込んで優先度を組み立てるのが実務的です。

影響を受ける版と修正版#

影響と修正の対応は次の表のとおりです。バージョンはnginx公式アドバイザリとNVDの記載にもとづきます。NGINX Open SourceはstableとmainlineでツリーがわかれるためF5の記載に沿って両系統を示します。

このバグは、2011年にmapディレクティブが正規表現に対応して以来、およそ15年にわたり潜在していたとされます。長く残った理由は、キャプチャ状態を保存し復元する処理の欠落という、スクリプトエンジンの内部にとどまる小さな不備だった点にあります。アドバイザリは公開日を2026年7月15日としています。

CVSSは採番機関のF5 Networksによる評価で、v4.0が9.2(Critical、ベクトルCVSS:4.0/AV:N/AC:H/AT:N/PR:N/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N)、v3.1が8.1(High、ベクトルCVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H)です。NVD自身の評価は執筆時点では未提供です。攻撃元区分はネットワーク、必要な権限はなし、攻撃条件の複雑さは高(AC:H)と評価されています。

The Hacker Newsは、overflowがNGINXのスクリプトエンジンにあり、正規表現mapの二段階評価が食い違うことで測長と書き込みがずれると説明し、F5の暫定緩和が該当する正規表現mapを名前付きキャプチャへ変えることだと伝えています。あわせて先行事例のCVE-2026-42945(2026年5月公開、式評価コードのヒープオーバーフロー)に触れ、研究者がパッチ後21日でPoC公開を予告したと報じています。

運用側がとる対応#

該当しうるNGINXを運用している場合、影響判定と更新を並行して進めます。次の順序で手を付けます。

前段のWAFで異常なリクエストを絞る運用は、更新までのつなぎとして有効です。WAFに何ができて何ができないかは、次の記事で整理しています。

あわせて読みたい

WAFの役割と限界、正しい使い方。シグネチャと振る舞い、回避される前提、根本対策との補完

NGINXのように境界に置かれるソフトウェアは、攻撃者から最初に見える面になります。境界のソフトウェアやアプライアンスに脆弱性が出たときの考え方は、次の記事も参考になります。

あわせて読みたい

境界に置くエッジ機器の脆弱性が侵入口として狙われる理由

優先度をどう決めるか#

この脆弱性への対応をいつ行うかは、自組織のNGINXが発火条件に該当するか、外部にどれだけ露出しているか、DoSとRCEのどちらまで織り込むかで変わります。執筆時点で公開エクスプロイトは確認されていないものの、研究者がパッチ後21日前後でのPoC公開を予告しており、猶予は限られます。先行事例のCVE-2026-42945が同じ式評価コードで起きている点も、この領域に注意が続いていることを示します。

CVSSの数値だけで緊急度を決めるより、発火条件への該当と露出の度合い、実悪用や公開エクスプロイトの有無を合わせて判断するのが現実的です。KEVへの収録状況やEPSSのスコアを使って修正の優先順位を組み立てる考え方は、次の記事で整理しています。

あわせて読みたい

脆弱性対応の優先順位付け。CVSSだけに頼らないEPSSとCISA KEVの使い方

更新を後回しにすると、修正済みの版が出ているのに旧版のまま公開し続ける状態が生まれます。更新をためらう理由と、それでも早く上げるべき理由の整理は、次の記事も参考になります。

あわせて読みたい

ソフトウェア更新が脆弱性を塞ぐ仕組みと放置したときのリスク

確認チェックリスト#

対応の抜けを防ぐための確認項目を整理します。

まとめ#

CVE-2026-42533は、NGINXのスクリプトエンジンで文字列式を二段階評価する仕組みに起因するヒープバッファオーバーフローです。正規表現mapの出力変数をキャプチャ変数より後に参照する構成のとき、1回目のパスがあるキャプチャ状態でバッファ長を測り、2回目のパスが異なるデータで書き込むため、確保した領域を越えて書き込みます。未認証の細工HTTPリクエストで発火し、既定の影響はワーカーのクラッシュによるサービス妨害、ASLRが無効または回避可能な環境では任意コード実行に至りうるとされます。影響はNGINX Open Source 0.9.6から1.31.2とNGINX PlusのR36 P7や37.0.3.1より前で、修正版は1.30.4、1.31.3、37.0.3.1です。発火条件が限定的である一方、成立経路は一つに限られず、境界に置かれるソフトウェアで到達性が高い点を踏まえ、設定の点検だけで安全と決めつけずに更新を最優先し、更新までは名前付きキャプチャの暫定緩和と露出低減でつなぐ判断が妥当です。脆弱性の検証は、許可された自組織の資産に対してのみ行います。