結論：Webサーバ「nginx」に深刻なヒープバッファオーバーフローの脆弱性（CVE-2026-42533、CVSS v4.0スコア9.2）が見つかり、開発チームは2026年7月15日（現地時間）に修正版 1.30.4（stable）/ 1.31.3（mainline）を公開しました。認証不要の攻撃者が細工したHTTPリクエストを送るだけでワーカープロセスを再起動（サービス妨害）させられるほか、環境によってはコード実行に至るおそれがあります。nginxをリバースプロキシやWebサーバとして使っている組織は、影響の有無を確認して早急な更新を計画してください。
この記事でわかること
- 今回修正された3件の脆弱性の内容と深刻度
- 影響を受けるバージョンと悪用の条件
- すぐ更新できない場合の緩和策と、情シスが確認すべきポイント
何が起きたのか
nginx開発チームは2026年7月15日、セキュリティ修正を含む nginx 1.30.4（stable）と 1.31.3（mainline）をリリースしました。修正されたのは次の3件で、オープンソース版・商用版（NGINX Plus）の両方が対象です。
| CVE番号 | 内容 | 深刻度 | 影響バージョン |
|---|---|---|---|
| CVE-2026-42533 | mapディレクティブで正規表現を使う構成でのヒープバッファオーバーフロー | CVSS v4.0：9.2（クリティカル）／ v3.1：8.1 | 0.9.6〜1.31.2 |
| CVE-2026-60005 | ngx_http_slice_module使用時のメモリ内容の開示 | Medium | 1.15.8〜1.31.2 |
| CVE-2026-56434 | ngx_http_ssi_module（SSI）使用時のuse-after-free | Medium | 0.8.11〜1.31.2 |
最も深刻なCVE-2026-42533は、CVSS v4.0基準で9.2と「クリティカル」評価です。CVSSスコアの読み方はCVSSの解説記事も参考にしてください。
どんな構成が影響を受けるのか
CVE-2026-42533が発現するのは、mapディレクティブで正規表現マッチングを使い、文字列式の中でmapの出力変数より先に正規表現のキャプチャ変数を参照している構成です。また、特定条件下でキャッシュ不可能な変数を文字列式で使っている場合も同様の問題が起きるとされています。つまり「nginxを使っていれば必ず危険」ではなく、設定に依存します。
ただし悪用に認証は不要で、細工したHTTPリクエストを送信できれば攻撃が成立します。想定される影響は次の2段階です。
- サービス妨害（DoS）：ワーカープロセスがクラッシュ・再起動を繰り返す。
- コード実行：ASLR（アドレス空間配置のランダム化）が無効な環境、または攻撃者がASLRを回避できる場合に限り、コード実行に至る可能性。
影響はデータプレーン（トラフィック処理側）のみで、コントロールプレーンは対象外とされています。
すぐ更新できない場合の緩和策は？
F5は緩和策として、mapディレクティブの正規表現で「名前なしキャプチャ」ではなく「名前付きキャプチャ」を使うことを推奨しています。恒久対応はあくまで修正版（1.30.4 / 1.31.3以降）への更新ですが、変更管理の都合ですぐ上げられない場合は、設定ファイルを確認して該当パターンを書き換えることでリスクを下げられます。
現場目線の課題：nginxは「気づかないところ」にいる
nginxが厄介なのは、情シスが把握しているWebサーバだけでなく、コンテナイメージ、Kubernetesのingress、ロードバランサ、ベンダー製アプライアンスの内部など、資産管理台帳に「nginx」と書かれていない場所に大量に潜んでいる点です。今回のような脆弱性が出るたびに痛感しますが、「うちはnginx使っていたっけ？」の確認自体に時間がかかるのが実情ではないでしょうか。
もう一つの落とし穴はディストリビューション提供パッケージのバージョン表記です。RHELやDebian系のnginxはバージョン番号が古いまま修正だけがバックポートされることが多く、「1.31.3未満だから脆弱」と番号だけで判断すると誤ります。OSベンダーのセキュリティアドバイザリで該当CVEの修正状況を確認してください。逆に、Dockerイメージや自前ビルドのnginxは自動では直らないので、イメージの再取得・再ビルドが必要です。先月のApache HTTP Server 2.4.68のときと同様、Webサーバ系の更新は影響範囲の棚卸しが対応の8割を占めます。
情シスはどうすべきか
- 資産の棚卸し：公開系のリバースプロキシ・Webサーバを最優先に、コンテナ・ingress・アプライアンス内のnginxも含めて洗い出す。
- 設定の確認：
nginx -Tなどで設定を出力し、mapディレクティブで正規表現キャプチャを使っている箇所、slice・SSIモジュールの利用有無を確認する。 - 更新の計画：該当構成があれば1.30.4 / 1.31.3以降（ディストリ版は各ベンダーの修正版）へ更新。すぐ更新できない場合は名前付きキャプチャへの書き換えで緩和する。
公開サーバの手前にWAFを置いている場合でも、今回のような細工されたリクエストを確実に止められる保証はありません。時間稼ぎにはなっても、根本対応はあくまでバージョン更新です。また、体制面の底上げには IPA の中小企業の情報セキュリティ対策ガイドラインが脆弱性対応の運用ルール整備の出発点として参考になります。
まとめ
- nginxに3件の脆弱性。最も深刻なCVE-2026-42533はCVSS v4.0で9.2、認証不要でDoS、条件次第でコード実行のおそれ。
- 影響はmapディレクティブ＋正規表現キャプチャなど構成依存。
nginx -Tで自社設定を確認し、1.30.4 / 1.31.3以降へ更新を。 - コンテナ・アプライアンス内の「見えないnginx」とディストリ版のバックポートに注意。バージョン番号だけで判断しない。
