NGINXの深刻なRCE脆弱性に設定スキャナー公開、8月には実証コード公開予定　即時のパッチ適用を推奨

NGINXに2011年から存在していた深刻なヒープバッファオーバーフローの脆弱性（CVE-2026-42533）について、設定ファイルの脆弱性を検出するスキャナーがGitHubで公開された。この脆弱性は、認証なしでの遠隔コード実行（RCE）につながる恐れがあり、2026年8月5日頃には完全な実証コード（PoC）が公開される予定と報じられている。影響を受けるシステムは世界中のWebサーバーの約3分の1に上るとみられており、セキュリティチームには速やかなパッチ適用と設定の監査が求められている。

■F5は「DoS」、発見者は「RCE」と主張。その違いが重要な理由

F5の公式アドバイザリでは、遠隔コード実行（RCE）の条件として「ASLR（アドレス空間配置のランダム化）が無効化されているか、回避可能であること」とされている。これは、デフォルトでASLRが完全に有効になっているUbuntu 24.04サーバーなどでは、影響が限定的であるかのように聞こえる。しかし、実際はそうではない。発見者のStan Shaw氏（GitHubではcyberstanとして活動）がThe Hacker Newsに語ったところによると、10回中10回成功するという極めて高い信頼性で実証された通り、この脆弱性自体がASLRを回避する手段（バイパス）を含んでいるという。

Shaw氏は、同じ根本的なバグから生じる2つの異なる攻撃プリミティブ（基本操作）を説明している。上書きされたキャプチャ変数が元の変数よりも小さい場合、NGINXは過剰なサイズのバッファを割り当て、レスポンスとして初期化されていないヒープバイト（libcやヒープのポインタを含む）を攻撃者に返してしまう。これが「プリミティブ1」であり、認証なしの単一のGETリクエストだけでASLRを無効化できる、クリーンな情報漏洩（インフォメーションリーク）である。一方、上書きされたキャプチャ変数が大きい場合、書き込み処理によってバッファがオーバーフローし、攻撃者が完全に制御可能なコンテンツで埋め尽くされる。これが「プリミティブ2」であるヒープオーバーフローそのものだ。これらを組み合わせることで（リークリクエスト1回、スプレ接続約40回、そしてオーバーフローを誘発するリクエスト1回）、前提条件なしで標準的なサーバー上で信頼性の高い遠隔コード実行が達成されると、Cyber Security Newsは報じている。

「F5のアドバイザリを読んだ人は、デフォルトのシステムではDoS（サービス拒否）しか発生しないと合理的に結論付けてしまうかもしれないが、実際はそうではない」とShaw氏はThe Hacker Newsに語った。

F5は、本記事の公開時点で、名前付きキャプチャによる緩和策の不備や、下流製品の修正スケジュールに関するThe Hacker Newsからの質問に回答していない。

■オバマ政権の第1期に誕生したバグ

この脆弱性は、2011年3月にリリースされたNGINXバージョン0.9.6にまで遡る。このバージョンで「map」ディレクティブに正規表現（regex）のサポートが追加された。Cyber Security Newsの報道によると、根本的な原因は、NGINXの内部スクリプトエンジンにおいてPCREキャプチャ状態の保存と復元（save/restore）が欠落していることにある。

NGINXはディレクティブの値を2つのパス（段階）で評価する。まず「LEN」パスで結果に必要なバイト数を測定し、正確にそのサイズのバッファを割り当てる。次に「VALUE」パスで実際のバイトを書き込む。どちらのパスも、現在のPCRE正規表現の一致グループ（$1、$2など）を保持する、共有かつ可変の配列である「r->captures」から読み取る。問題は、これら2つのパスの間に、正規表現の一致条件を持つmapディレクティブが実行された場合に発生する。そのmapの評価によって新たなPCRE一致処理が実行され、r->capturesが密かに上書きされてしまう。LENパスはあるキャプチャに基づいてバッファサイズを決定したが、VALUEパスは別のキャプチャから書き込みを行うことになる。7月15日の修正に関するnginx.orgの変更履歴（changelog）によると、攻撃者が制御する置換文字列が元の文字列より大きいか小さいかによって、バッファが小さすぎてオーバーフローするか、大きすぎて情報漏洩が発生する。

この挙動は、2014年にNGINXのコア開発者であるMaxim Dounin氏によってnginxのtracチケット上で欠陥として指摘されていた。しかし、当時はセキュリティ上の重大な問題としては対処されなかったと、Cyber Security Newsは報じている。

The Hacker Newsが確認したところによると、CVE-2026-42533は10人以上の研究者から個別にF5へ報告されていた。

■9つのソースファイルにまたがる13の侵入経路

この脆弱性は単一のディレクティブに限定されない。Shaw氏の分析によると、NGINXのコードベース内の9つのソースファイルにわたって、少なくとも13の独立した呼び出し箇所が特定されており、HTTPモジュールとストリーム処理モジュールの両方に影響が及ぶという（Cyber Security News報道）。

正規表現のキャプチャソース（location、server_name、rewrite、またはifブロック）と、同じリクエストコンテキスト内でその後に評価される正規表現ベース of map変数を組み合わせる設定は、すべて悪用される可能性がある。影響を受けるディレクティブには、proxy_set_header、proxy_pass、fastcgi_param、add_header、rewrite、return、root、alias、access_log、grpc_set_header、set、uwsgi_param、scgi_paramなどが含まれる。

F5が提示している一時的な緩和策（影響を受ける正規表現mapを名前付きキャプチャに変更する）は、主要な攻撃経路を塞ぐ。しかし、Shaw氏がThe Hacker Newsに語ったところによると、これでは2つ目のコードパスが未対策のまま残るという。locationの正規表現と同じ名前付きグループを定義するmapは、AddressSanitizerで確認された別のメカニズムを通じて、同じオーバーフローに達する。「1.30.4または1.31.3へのアップグレードのみが、唯一の完全な修正策だ」と同氏は述べている。

F5のアドバイザリでは、NGINX Gateway Fabric、Ingress Controller、App Protect WAF、Instance Managerも影響を受ける製品として挙げられているが、本稿執筆時点ではこれら4製品の修正ビルドは公開されていない。

■過去のNGINX脆弱性パッチではカバーできない

CVE-2026-42945（通称「NGINX Rift」、2026年5月13日公開）、CVE-2026-9256（rewriteモジュールのヒープオーバーフロー、2026年5月22日公開）、CVE-2026-42055、またはCVE-2026-48142に対するパッチを適用済みの組織であっても、今回の脆弱性からは保護されない。Cyber Security Newsによると、それぞれの修正は独立している。

CVE-2026-42533 is the third heap overflow in NGINX's expression-evaluation code disclosed within roughly two months. All three share the same structural root cause: NGINX's two-pass script engine sizes a buffer in one pass and writes into it in the next, without guarding against side effects that can change the measurement between passes. The trigger differs across the three CVEs — a stale flag in Rift, overlapping captures in CVE-2026-9256, clobbered capture state here — but the architectural weakness is the same, The Hacker News reports.

NGINX Riftについては、公開から3日後にVulnCheckによってアクティブな悪用が確認された。同社のハニーポットシステムが標的型の攻撃トラフィックを検出したためだ。CVE-2026-42533は、7月20日時点で米国土安全保障省サイバーセキュリティ・インフラセキュリティ庁（CISA）の「既知の悪用された脆弱性（KEV）」カタログには登録されておらず、公開されたエクスプロイトコードも存在しないとThe Hacker Newsは報じている。しかし、その猶予期間は8月5日頃に狭まることになる。

■自社のNGINX設定は脆弱なパターンに該当するか？

この脆弱性は設定に依存するため、すべてのNGINXサーバーが危険にさらされているわけではない。影響を受けるのは、正規表現マッチングを伴うmapディレクティブを使用し、かつ同じ文字列式内でそれ以前の正規表現マッチからのキャプチャ変数を参照しているインスタンスのみである。このパターンは、リバースプロキシ、URLルーティング、ヘッダー操作の設定で一般的であるとCyber Security Newsは報じている。

Shaw氏が公開した静的設定スキャナー（0xCyberstan/CVE-2026-42533-Config-Scanner）は、nginxの設定ファイルを解析し、includeを追跡して、悪用可能なディレクティブの順序のみを検出する。これは外部ライブラリを必要としないPythonスクリプトであり、サーバーへの接続やトラフィックの送信は行わない。アップグレード前に実行することで、セキュリティチームは自社の露出状況を明確に把握できる。

■セキュリティチームが8月までに実施すべきこと

セキュリティチームは、実証コード（PoC）の完全な公開が予想される8月5日より前に、これを最優先の対処事項として扱うべきである。

第一に、直ちにnginx 1.30.4（安定版）、1.31.3（メインライン）、または対応するパッチ適用済みのNGINX Plusリリースにアップグレードすること。これらが唯一の完全な修正策である。

第二に、パッチ適用の前後で、すべての本番環境 of NGINX設定に対して静的設定スキャナー（0xCyberstan/CVE-2026-42533-Config-Scanner）を実行し、脆弱なディレクティブの順序を特定すること。スキャナーは、設定ファイル内の脆弱なパターンが存在する正確な場所を特定する。

第三に、過去のパッチで十分であると仮定しないこと。CVE-2026-42945、CVE-2026-9256、CVE-2026-42055、およびCVE-2026-48142に対する最近の修正は独立しており、CVE-2026-42533には対処していないとCyber Security Newsは報じている。

第四に、Kubernetesの運用者への注意点として、NGINXは大多数 of Kubernetesクラスターでイングレスコントローラーとして使用されている。すでにアーカイブされている「kubernetes/ingress-nginx」リポジトリ（NGINX 1.27.1を同梱）はベンダーによる修正を受け取らないため、このイングレスコントローラーを経由してルーティングされるワークロードは恒久的に脆弱な状態のままとなり、代替戦略が必要となる。

第五に、異常なHTTPリクエストパターンの監視を行うこと。単一のソースから類似したGETリクエストが集中し、その後に1つの大きな、または異なる構造のリクエストが続くパターンは、ASLR回避のための偵察行為と、それに続くエクスプロイトの送信を示している可能性がある。

Shaw氏が完全なエクスプロイトの公開を控え、公開前にF5のSIRT（セキュリティインシデント対応チーム）と連携したことは、影響の大きいサーバーソフトウェアに対する責任ある開示への慎重なアプローチを反映している。21日間の猶予期間は、CVE-2026-42945が公開された後に何が起こったか（公開から72時間以内に悪用が始まったこと）を明確に考慮して設定された。

■注目ポイントQ&A

●私のNGINXサーバーはASLRが有効になっています。遠隔コード実行（RCE）から保護されていますか？

ASLRが有効であることだけでは保護されません。F5のアドバイザリでは、RCEの条件としてASLRが無効であるか回避可能であることを挙げていますが、発見者のShaw氏の研究により、CVE-2026-42533自体にASLRを回避する手段が含まれていることが実証されています。単一のGETリクエストで初期化されていないヒープメモリ（libcやヒープのポインタを含む）を攻撃者に返す情報漏洩（プリミティブ1）が発生するため、攻撃者はこのアドレス情報を利用してオーバーフロー（プリミティブ2）を実行し、コード実行を達成できます。唯一の確実な保護策は、パッチ適用済みのバージョンにアップグレードすることです。

●使用しているNGINXのバージョンによって、脆弱性の有無は変わりますか？

バージョンは影響を受ける条件の一つですが、それだけでは決まりません。影響を受けるバージョンは、NGINXオープンソース版の0.9.6から1.30.3（安定版）、および1.31.2（メインライン）まで、またNGINX PlusのR33からR36、および37.0.0.1から37.0.2.1までと、非常に広範囲にわたります。ただし、これらのバージョンを使用していても、設定において正規表現マッチングを伴うmapディレクティブを使用し、かつ同じリクエストコンテキスト内で以前の正規表現マッチからのキャプチャ変数を参照している場合のみ、脆弱性が悪用される可能性があります。GitHubで公開されている静的設定スキャナーを使用すれば、自社の設定が危険にさらされているかどうかを数秒で確認できます。

●完全な実証コード（PoC）は本当に8月5日頃に公開されるのですか？

はい。発見者のShaw氏は、7月15日のパッチ公開から21日後（およそ8月5日）に完全な実証コードを公開すると表明しています。これは単なる予測ではなく、公表されている計画です。そのため、8月5日以降は、脆弱な設定のまま放置されているNGINXサーバーは、理論上の脅威ではなく、実際に悪用可能な攻撃に直面することになります。過去の「NGINX Rift」の例では、実証コードの公開から数日以内に実際の悪用が始まっており、この日までにアップグレードとスキャンを完了させることが強く推奨されます。

●「NGINX Rift」（CVE-2026-42945）や他の2026年のヒープオーバーフロー脆弱性の修正を適用していれば、今回の脆弱性も防げますか？

いいえ、防げません。CVE-2026-42945、CVE-2026-9256、CVE-2026-42055、およびCVE-2026-48142は、それぞれ異なるコードパスに対処したものであり、今回のCVE-2026-42533が対象とするmapディレクティブの挙動には対処していません。例えば、CVE-2026-9256の対策としてNGINX 1.31.1にアップグレードした組織であっても、今回の脆弱性に対しては依然として無防備であり、1.31.3または1.30.4への再度のアップグレードが必要です。

元記事: NGINX Map Regex RCE Gets Public Scanner: Patch Now, Full Exploit Due August