nginx脆弱性CVE-2026-42533・60005・56434を解説 ― 影響条件の確認方法と対策(2026年7月)

初回公開: 2026年7月17日 / 最終確認: 2026年7月17日
現時点の悪用状況: 信頼できる一次情報から実悪用・公開PoCは確認できていません(詳細は本文参照)
修正版: nginx 1.31.3(mainline) / 1.30.4(stable)

結論(要点まとめ)

2026年7月15日、nginxの安定版1.30.4・開発版(mainline)1.31.3が公開され、3件のセキュリティ脆弱性が 修正されました。nginx公式アドバイザリでの深刻度は、CVE-2026-42533がmajor、 残り2件はmediumです。一方、CNA(採番機関)であるF5が付与したCVSS v4.0では、 CVE-2026-42533が9.2(Critical)、CVE-2026-60005が8.8(High)、 CVE-2026-56434が8.3(High)と評価されています。評価の主体が異なる点は後述します。

• CVE-2026-42533: mapディレクティブの正規表現マッチングに起因するヒープバッファオーバーフロー(CWE-122)。特定の条件下で、未認証の攻撃者が細工したHTTPリクエストによりワーカープロセスを再起動させられ、ASLRが無効・回避された環境ではコード実行に至る可能性があります。
• CVE-2026-60005: ngx_http_slice_module(バイト範囲配信用モジュール)を無名正規表現キャプチャと併用、または背景キャッシュ更新処理を使っている場合の未初期化メモリアクセスによるメモリ開示・ワーカー終了。
• CVE-2026-56434: ngx_http_ssi_module(SSI)のuse-after-free。上流(バックエンド)からのレスポンスを操作できる中間者的な立場の攻撃者が、限定的なメモリ改変やワーカークラッシュを引き起こせる可能性があります。

重要な前提として、「1.31.3/1.30.4未満だから3件すべてに今すぐ攻撃される」わけではありません。 上流のnginx OSSとしては影響対象バージョンに含まれますが、実際に攻撃が成立するかどうかは、使っている モジュールのビルド状況や設定内容(map・slice・ssi・proxy_buffering等の組み合わせ)に依存します。 恒久対策はアップデートで、アップデートまでの時間稼ぎとしてF5は 名前付きキャプチャ(named capture)への置き換えを推奨しています。以下、それぞれの 詳細と確認方法、対策を整理します。

対象となる3つの脆弱性

「nginx公式Severity」はnginx.orgのセキュリティアドバイザリが使っている5段階(critical/major/medium/minor/none)の表記、 「F5 CNA CVSSv4.0」はCVEの採番機関(CNA)であるF5が算出しNVDにも掲載されているスコアです。評価する 組織・基準が異なるため、両方を並記しました。社内のリスク基準がどちらを採用しているか確認した上で 深刻度の判断に使ってください。CVSS v3.1のスコアは順に8.1 / 8.2 / 6.5で、v4.0とは評価軸が異なるため 差が出ます。

現在悪用されているか

2026年7月17日時点で確認した範囲では、信頼できる一次情報から、これら3件が実環境で悪用された、 または実用的な公開PoCが出回っているという情報は見つかりませんでした。NVDに掲載されている CISA ADP(Authorized Data Publisher)のSSVC評価でも、CVE-2026-42533はExploitation: none Automatable: noとなっています。

ただし、公開からまだ2日程度しか経過していません。修正コミット自体は公開されているため、攻撃者が 差分(diff)を分析して再現方法を組み立てる可能性は否定できません。KEV(Known Exploited Vulnerabilities)登録やPoC公開を待たず、該当する構成では先にアップデートを進めることを推奨します。

30秒でわかる影響判定

1. nginx -vで1.31.3(mainline)/1.30.4(stable)未満か? → いいえなら原則として修正済みです。
2. 該当する機能(map+正規表現、slice、ssi+proxy_pass)を使っているか? → いいえなら攻撃露出は限定的ですが、更新自体は推奨します。
3. 外部からの入力や上流応答を攻撃者が操作できる位置にあるか? → はいの場合は優先度を上げて対応してください。

CVE-2026-42533:mapディレクティブのヒープバッファオーバーフローとは

nginxのmapディレクティブは、ある変数の値に応じて別の変数の値を決める、設定ファイル内では ごく一般的な仕組みです。IP判定、UA判定、レートリミットのキー生成など、幅広い用途で使われています。

nginx公式のchangelogでの説明は次のとおりです(意訳)。

mapディレクティブで正規表現マッチングを使う際、そのmapによる影響を受けるキャプチャの後に 続けて、同じ文字列式の中でmapの出力変数自体を参照していると、ワーカープロセスでヒープバッファ オーバーフローが発生し得る。非キャッシュ可能な変数(non-cacheable variable)を文字列式で使っている 場合も同様の問題が起き得る。

ポイントは、「1つの文字列式の中で、その正規表現によるキャプチャ変数($1など)と、 map自身の出力変数の両方を参照している」という組み合わせです。以下は、この評価順序の 問題を説明するための概念的な例です(実際の攻撃コードではなく、パターンを理解する ための簡略化した例としてご覧ください)。

# 概念例: mapによる影響を受けるキャプチャ($1)と、
# mapの出力変数($mapped_value)を同じ文字列式で参照している
map $request_uri $mapped_value {
    ~^/(.*)$  $1;
    default   "";
}
set $combined_value "$1:$mapped_value";

また、この脆弱性は「無名キャプチャ$1だけが対象」というわけではありません。 無名キャプチャは他の正規表現評価でも上書きされやすいため特に注意が必要ですが、名前付きキャプチャで あっても、その変数を対応する設定ブロックの外で再利用したり、同名の変数が別の処理で変更されたりする 場合には、同種の評価順序の問題が起こり得るとされています。「named captureにすれば無条件に安全」では なく、「対応する正規表現の設定ブロック内だけで使う」ことが重要です。

NVDの説明文には「未認証の攻撃者が、本人にはコントロールできない条件と合わせて、細工したHTTPリクエストで 悪用し得る」とあり、単純にmapを使っているだけで即座に脆弱というわけではなく、設定内容に 依存する点が明記されています。影響はデータプレーンに限定され、管理系(コントロールプレーン)への 影響はないとも記載されています。

CVE-2026-60005:ngx_http_slice_moduleの未初期化メモリ開示とは

ngx_http_slice_moduleは、大きなファイル(動画配信、大容量ダウンロード、再開可能ダウンロードなど) をバイト範囲(Range)ごとに分割してキャッシュ・配信するためのモジュールです。ビルド時に --with-http_slice_moduleを有効化している場合のみ関係します。

nginx公式のchangelogでは、次のいずれかの条件で発生し得るとされています。

• sliceディレクティブと無名の正規表現キャプチャを併用している
• 背景キャッシュ更新(background cache update)処理を使っている(proxy_cache_background_update on;など)

sliceを使っていないから無関係、と即断せず、背景キャッシュ更新の設定も併せて確認してください。 発生した場合、本来レスポンスに含まれるはずのないメモリ内容が漏洩するか、ワーカー プロセスが異常終了します。

自分の環境が対象かどうかは、後述の「nginx -Tを使った確認手順」でまとめて確認できます。

CVE-2026-56434:ngx_http_ssi_moduleのuse-after-freeとは

SSI(Server Side Includes)は、HTMLに埋め込んだ簡易的なディレクティブでファイルの読み込みや変数展開を 行う古くからの仕組みです。nginx公式のchangelogでは「ngx_http_ssi_filter_moduleで、 特殊に細工されたプロキシ経由のバックエンド応答を処理する際にuse-after-freeが起こり得る」とされています。 実務上、典型的な該当構成は次の組み合わせです。

• ssi on;でSSI処理を有効化しつつ、
• proxy_passでリバースプロキシとして上流(バックエンド)からのレスポンスをSSI処理し、
• proxy_buffering off;でバッファリングを無効化している(低遅延・ストリーミング用途で使われがちです)

攻撃者側の条件としては、上流からnginxへ返るレスポンスの内容を操作できる立場が必要です。 たとえば次のようなケースが考えられます(公式説明を実運用に当てはめた一例で、断定ではありません)。

• nginxとバックエンド間の通信が暗号化されていないネットワーク
• 同一ネットワーク内に侵害されたホストが存在する
• 上流のバックエンド自体がすでに侵害されている
• 外部APIやユーザー指定のURLを上流として利用している構成

影響は限定的なメモリ改変やワーカープロセスの再起動です。設定変更による有効な回避策は報告されておらず、 アップデート以外に確実な対処法はありません。

nginx -Tを使った確認手順

個別にgrepするより先に、nginx -Tで「実際に読み込まれている設定(includeされる ファイルを含む)」を展開してから確認するのが確実です。単純なgrep 'slice'のようなやり方は、 コメントや変数名($slice_rangeなど)まで拾ってしまい誤検出が増えます。

注意: nginx -Tの出力にはホスト名・パス・内部の認証設定などが含まれる 場合があります。出力ファイルの取り扱い・共有には注意してください。

# バージョン・ビルドオプションの確認
nginx -V 2>&1

# 設定の構文チェック
sudo nginx -t

# includeを含む有効な設定を出力(取り扱い注意)
sudo nginx -T > /tmp/nginx-active-config.txt 2>&1

# mapディレクティブ
grep -nE '^[[:space:]]*map[[:space:]]+' /tmp/nginx-active-config.txt

# sliceディレクティブ
grep -nE '^[[:space:]]*slice[[:space:]]+' /tmp/nginx-active-config.txt

# 背景キャッシュ更新
grep -nE '^[[:space:]]*proxy_cache_background_update[[:space:]]+on[[:space:]]*;' /tmp/nginx-active-config.txt

# SSI
grep -nE '^[[:space:]]*ssi[[:space:]]+on[[:space:]]*;' /tmp/nginx-active-config.txt

# proxy_buffering off
grep -nE '^[[:space:]]*proxy_buffering[[:space:]]+off[[:space:]]*;' /tmp/nginx-active-config.txt

# proxy_pass
grep -nE '^[[:space:]]*proxy_pass[[:space:]]+' /tmp/nginx-active-config.txt

SSIについては、ssi on・proxy_pass・proxy_buffering offが それぞればらばらの場所にヒットしただけでは不十分です。同じlocationや継承関係にある 設定ブロックで、3条件がまとめて成立しているかどうかを確認してください。

対策1:アップデート(恒久対策) ― OSS/OSベンダー版/Docker/NGINX Plus別

すべてのCVEに対する唯一の恒久対策は、nginx 1.31.3(mainline)または1.30.4(stable)以降への アップデートです。ただし、どの経路でnginxを入れているかによって確認方法が変わります。

nginx公式パッケージ(OSS)を直接使っている場合

nginx -v
# mainline: 1.31.3以降であればOK
# stable:   1.30.4以降であればOK

OSディストリビューションのパッケージ版を使っている場合

Ubuntu/Debian/RHEL/AlmaLinuxなどのパッケージは、上流のバージョン番号を大きく変えずに、セキュリティ 修正だけをバックポートしていることがあります。nginx -vの数字だけで「まだ古いから 脆弱」と即断せず、ディストリビューション側のCVEトラッカーやパッケージのchangelogも確認してください。

# Debian / Ubuntu
apt-cache policy nginx
dpkg-query -W nginx
apt changelog nginx 2>/dev/null | grep -E 'CVE-2026-(42533|60005|56434)'

# RHEL / AlmaLinux / Rocky Linux
dnf info nginx
rpm -q nginx
rpm -q --changelog nginx | grep -E 'CVE-2026-(42533|60005|56434)'

# 更新コマンド例
apt-get update && apt-get install --only-upgrade nginx   # Debian/Ubuntu
dnf update nginx                                              # RHEL/AlmaLinux

Dockerで運用している場合

よくある誤解として「コンテナ内部でapt upgradeすれば更新できる」がありますが、それでは DockerfileやComposeで指定したベースイメージ自体は更新されません。その状態でコンテナを 再作成すると、元の脆弱なイメージに戻ります(「巻き戻る」というより「更新前の状態に 差し戻る」と考えると理解しやすいです)。イメージタグを固定(pin)している場合、その値自体を書き換えて 再取得するまでは、古い脆弱なバージョンを使い続けることになる点にも注意してください。

# Composeの最終的な設定内容を確認
docker compose config

# イメージタグを新しいバージョンに書き換えた後
docker compose pull nginx
docker compose up -d --force-recreate --no-deps nginx

# コンテナ内部の実バージョンとビルドオプション
docker compose exec nginx nginx -V
docker compose exec nginx nginx -t

# イメージIDやダイジェストも記録しておくと監査しやすい
docker inspect --format '{{.Config.Image}} {{.Image}}' "$(docker compose ps -q nginx)"

NGINX Plus / Ingress Controller / Gateway Fabricなどの製品版を使っている場合

NGINX Plusもこの3件の対象で、修正版はF5の情報によればR37(37.0.3.1以降)、 R36(R36 P7以降)とされています。NGINX OSSの1.30.4/1.31.3にただ置き換えるのではなく、 F5の公式サポート情報に従って対応してください。同様に、NGINX Ingress Controller、 Kubernetesディストリビューション同梱のIngress、WAFやロードバランサーに組み込まれたnginx、 OpenRestyなどの派生製品も、内蔵nginxのバージョン番号だけで判断せず、それぞれの製品ベンダーの アドバイザリを確認してください。

対策2:恒久対策までのつなぎ(named captureへの移行)

すぐにアップデートできない事情がある場合、F5はCVE-2026-42533/60005の緩和策として、正規表現の 無名キャプチャを名前付きキャプチャ(named capture)に置き換えることを推奨しています。

# Before(無名キャプチャ)
map $request_uri $mapped_value {
    "~^/articles/(\d+)"  $1;
    default                "";
}

# After(named capture)
map $request_uri $mapped_value {
    "~^/articles/(?<article_id>\d+)"  $article_id;
    default                              "";
}

(?<name>...)という書き方で名前付きキャプチャを定義し、$1の代わりに $nameで参照します。ただし、単純な文字列置換だけで完了するとは限りません。 キャプチャ名の重複、別の正規表現による同名変数の上書き、対応する設定ブロック外での再利用がないかを 確認してください。F5は、名前付きキャプチャを対応する正規表現の設定ブロック内だけで使う ことを推奨しています。変更後はnginx -tの構文チェックだけでなく、実際のルーティング・ レート制限・キャッシュキー・アクセスログの値についても回帰テストを行ってください。 これはあくまで緩和策であり、根本対策ではありません。アップデートの計画は別途進めてください。

更新後の確認

nginx -vの表示が新しくなっただけでは不十分です。実際に新しいバイナリでワーカーが 動いていることまで確認してください。グレースフルリロードでは、新しいワーカーが起動した後、 古いワーカーは処理中のリクエストを終えてから終了するため、更新直後は一時的に新旧のワーカーが 混在します。

sudo nginx -t && sudo systemctl reload nginx
systemctl status nginx --no-pager
ps -o pid,lstart,cmd -C nginx
journalctl -u nginx --since "15 minutes ago"

可能であれば、本番反映の前にステージング環境でmap・キャッシュ・SSIまわりの回帰テストを 行い、問題発生時のロールバック手順(直前のイメージ・パッケージバージョンに戻す手順)も準備しておいて ください。

WAF/IPSでの監視の考え方

これらの脆弱性はいずれも「正常なHTTPリクエスト・レスポンスの形をした異常」で発生し得るため、単純な シグネチャマッチだけで検知しきるのは簡単ではありません。WAF/IPSはアップデートの代替には なりません。レート制限や入力長制限は攻撃回数や影響を減らす補助策にはなりますが、メモリ安全性 そのものの不具合を修正するものではない点は明確にしておきます。

また、攻撃の入力経路はmapで判定に使っている値次第で、URIだけとは限りません。 クエリパラメータ、Host、Cookie、User-Agent、Referer、独自HTTPヘッダー、上流から設定された変数なども 対象になり得ます。「長いURIを遮断するルール」だけでは網羅できない点に注意してください。

効果的な監視の例:

• ワーカープロセスの異常終了・再起動の頻度(通常時のベースラインからの逸脱)
• systemdによるサービス再起動、Docker/KubernetesのRestartCount
• SIGSEGV・SIGABRTなど異常シグナルによる終了、コアダンプの生成
• Rangeリクエストの急増(sliceに関連)
• 5xx・499・upstream prematurely closed connectionの増加(SSI/プロキシ関連)
• 更新前後でのメモリ使用量・クラッシュ頻度の比較

journalctl -u nginx | grep -Ei 'signal|segfault|core|worker process.*exited'
coredumpctl list nginx

実際にIPS側でこれらのCVEに対応する検知シグネチャを追加した際の考え方は、当サイトの他の脆弱性対応記事 でも触れています。1つの脆弱性ごとに対処するのではなく、「入口(異常リクエストの検知)」と「出口(異常 終了・異常なメモリアクセスの兆候の監視)」の両方を継続的に強化していく姿勢が重要だと考えています。

見落としがちなポイント

mapを使っているだけで攻撃されるのか

いいえ。mapを使用しているだけで直ちに脆弱というわけではありません。正規表現キャプチャや 非キャッシュ変数を、mapの出力変数と同じ文字列式の中で組み合わせて使っている、という条件が必要です。 ただし設定の見た目だけで判断するのは難しいため、条件に心当たりがなくても修正版への更新は推奨されます。

ASLRが有効なら更新しなくてよいのか

いいえ。ASLRが有効でも、ワーカープロセスをクラッシュさせるサービス拒否(DoS)のリスクは残ります。 コード実行に発展するのはASLRが無効・回避された場合という条件であり、DoS自体はASLRの有無に関わらず 起こり得ます。

CDNやWAFの背後なら安全か

完全に安全にはなりません。CDNやWAFは試行回数の抑制や明らかに異常な入力の遮断には役立ちますが、 業務上は正常に見える入力が脆弱な処理経路に到達する可能性は残ります。

sliceを使っていなければCVE-2026-60005は無関係か

sliceを使用していない場合でも、背景キャッシュ更新(proxy_cache_background_update on;) が関係する可能性があるため、その有無も確認してください。

チェックリスト

• [ ] nginx -v / nginx -Vで現在のバージョンとビルドオプションを確認した
• [ ] nginx -Tで実際に読み込まれている設定を確認した(includeファイル含む)
• [ ] mapディレクティブの正規表現とキャプチャ変数の使い方を棚卸しした
• [ ] sliceディレクティブ・背景キャッシュ更新(proxy_cache_background_update on)の使用有無を確認した
• [ ] ssi on + proxy_pass + proxy_buffering off の組み合わせがないか確認した
• [ ] OSベンダーのCVE情報・パッケージchangelogを確認した(パッケージ版の場合)
• [ ] 1.31.3(mainline)/1.30.4(stable)以降へのアップデート計画を立てた
• [ ] Docker運用の場合、ベースイメージ自体を更新し、コンテナを再作成した(コンテナ内更新だけで終わらせない)
• [ ] NGINX Plus等の製品版を使っている場合、ベンダーのアドバイザリに従って対応した
• [ ] アップデートが難しい箇所は named capture へ暫定的に置き換えた(対応ブロック内限定)
• [ ] ステージング環境でmap・キャッシュ・SSI関連の回帰テストを実施した
• [ ] 更新後、新しいワーカープロセスへ切り替わったことを確認した
• [ ] 問題発生時のロールバック手順を準備した
• [ ] IPS/WAF側でワーカー異常終了・異常リクエストの監視を強化した

まとめ

今回のnginx 1.31.3 / 1.30.4は、アクセス制御・レート制限・ルーティングなどで広く使われる mapの問題に加え、大容量コンテンツ配信で使われるslice、特定の動的HTML生成 環境で使われるssiの問題をまとめて修正するリリースでした。特にCVE-2026-42533は一般的な map設定に関係し得るため、mapディレクティブを使っているサイトは優先的に 設定を棚卸しする価値があります。

「バージョンを上げて終わり」にせず、①自分の設定のどこが該当するパターンかをnginx -T等で具体的に 把握する、②アップデートを妨げる事情があればnamed captureのような緩和策でつなぐ、③再発防止のため バージョンpinの管理・監視体制を見直す、という3段構えで対応することをおすすめします。

参考一次情報

• nginx security advisories(nginx.org公式)
• Changes with nginx 1.31.3(公式changelog)
• NVD - CVE-2026-42533