nginx CVE-2026-42533解説｜mapとregexのRCEを自分のサーバで確認する実行コマンド

nginxに、細工したHTTPリクエストでワーカープロセスのヒープを溢れさせる脆弱性 CVE-2026-42533 が公表されました。影響範囲は 0.9.6 から 1.31.2 まで、2011年以降のほぼ全バージョンに及びます。ただし「全nginxが危険」ではありません。成立には特定の設定の並びが要ります。この記事は、自分のサーバが本当に該当するかを実際に叩いて確かめる手順に振り切ります。以下のコマンドはすべて実機で実行し、出力を確認したものです。

CVEの読み解きと対策の全体像は、当サイトのピラー記事サプライチェーンセキュリティ2026｜攻撃手法・防御ツール・実践チェックリストでも扱っています。

時系列（Timeline）

まず、いつ何が起きたのかを一次ソースで確認できる範囲に絞って整理します。日付はすべて公式の公表内容および報道に基づきます。

発見と謝辞の帰属について

この件は報告者が複数いるため、クレジットが少し複雑です。正確に書いておきます。

nginx公式の変更履歴（CHANGES）が謝辞を載せているのは Mufeed VH 氏（Winfunc Research）と Maxim Dounin 氏です。一方、本記事のきっかけとなった詳細な技術解説を公開しているのは cyberstan（Stan Shaw 氏）で、こちらも独立にF5へ報告した研究者の一人と報じられています。報道によればF5は、この問題を独立に報告した研究者が十数名規模で存在したとしています。

つまり「一人の発見者がいる」構図ではありません。本記事では、技術的な詳細解説の出典として cyberstan の記事を参照しますが、公式の謝辞対象とは区別して扱います。

CVE-2026-42533で何が起きたのか

技術的な要点は3行で言えます。この「map regex」の組み合わせが鍵です。

・nginxは設定内の文字列式を2回に分けて評価する。1回目で必要なバイト数を測り（LENパス）、その長さでバッファを確保し、2回目で実際に書き込む（VALUEパス）
・正規表現のキャプチャ結果は r->captures という共有された可変状態に置かれる。正規表現を使う map を評価すると、そのマッチ結果で r->captures が上書きされる
・その結果、LENパスとVALUEパスが別々の文字列を見る。書き込み側が測定側より長ければヒープバッファオーバーフロー、短ければ確保しすぎた領域に初期化されていないヒープの残骸が残り、情報漏洩になる

公式の変更履歴は、この現象を次のように記述しています。「map ディレクティブを正規表現マッチとともに使用しており、その map の影響を受けるキャプチャより後ろで map 変数が文字列式に含まれている場合、ワーカープロセスでヒープバッファオーバーフローが発生する可能性がある。キャッシュ不可の変数を文字列式で使用した場合にも同様の問題が起きうる」。

重要なのは、これが map というごく一般的なディレクティブで起きるという点です。map はUser-Agentによる振り分け、ホスト名の正規化、A/Bテストの割り振りなど、実運用の設定で広く使われています。

影響を受けうる文字列式は map だけに閉じません。研究者の解析によれば、proxy_set_header / proxy_pass / fastcgi_param / uwsgi_param / scgi_param / grpc_set_header / return / add_header / rewrite / set / root / alias / access_log など、文字列式を組み立てる箇所が広く該当するとされています。HTTPモジュールとstreamモジュールの両方が対象です。

CVE-2026-42533の影響範囲マトリクス

バージョン範囲は、NVDの表記よりも nginx公式アドバイザリの記述が正確です。NVD側の範囲表記は修正版であるはずの 1.30.4 を含んでしまう書き方になっており、そのまま読むと誤解します。以下は nginx.org の記載に基づきます。

CVSSの評価は次のとおりです。数値が2つあるのは評価機関が割れているからではなく、同じF5がCVSSのバージョン違いで2つ算出しているためです。

自システムでの確認方法

ここからが本題です。バージョンと設定の両方を確認します。片方だけでは判定できません。

手順1：バージョンを確認する

まずインストールされているnginxのバージョンを見ます。

# バージョンのみ表示
nginx -v

# 実行中のプロセスから確認（設定ミスで別バイナリを見ていないか確かめる）
sudo nginx -v 2>&1
ps -o pid,comm,args -C nginx | head -3

実機（nginx公式Dockerイメージ 1.31.3）での出力は次のとおりでした。

nginx version: nginx/1.31.3

表示されたバージョンが 1.31.3以上、または 1.30.4以上なら対象外です。それ以外（1.31.2以下、1.30.3以下、1.29系、1.28系以前）は影響範囲内です。

手順2：パッケージとビルド構成を確認する

ディストリ別のパッケージ確認コマンドです。

# Debian / Ubuntu
dpkg -l 'nginx*' | grep ^ii
apt-cache policy nginx

# RHEL / Rocky / AlmaLinux / CentOS
rpm -q nginx
dnf list installed 'nginx*'

# Alpine
apk info -v nginx

# ソースからビルドした場合：有効なモジュールとPCREの構成を確認
nginx -V 2>&1 | tr ' ' '\n' | grep -E '^--with|pcre'

nginx -V は、どのモジュールが組み込まれているかを示します。実機での出力（抜粋）は次のとおりでした。

--with-http_slice_module
--with-http_ssl_module
--with-http_v2_module
--with-http_v3_module

--with-http_slice_module が入っている場合、同時に修正された CVE-2026-60005（sliceモジュールのメモリ開示）にも該当します。後述します。

手順3：設定が成立条件を満たすか確認する ★

ここが本記事のいちばんの要点です。 バージョンが影響範囲内でも、設定が条件を満たさなければ発火しません。逆に、条件を満たす設定があるなら優先度は跳ね上がります。

まず、include を展開した完全な設定をダンプします。個別の設定ファイルを見るだけでは include の先を見落とします。

# includeを展開した設定全体をダンプ
nginx -T > /tmp/nginx-full.conf 2>/dev/null
wc -l /tmp/nginx-full.conf

# 正規表現を使っている map があるか
grep -nE '^\s*map\s' /tmp/nginx-full.conf
grep -nE '^\s*~\*?\s' /tmp/nginx-full.conf | head

正規表現を使う map が1つも無ければ、この脆弱性の主要な経路には該当しません。ある場合は、その出力変数がキャプチャと同じ文字列式に混在していないかを確認します。

次のスクリプトは、nginx -T の出力に対して「正規表現マップの出力変数」と「キャプチャ $1〜$9」が同一行に共存する箇所を洗い出します。あくまで機械的な絞り込みなので、出た箇所は目視で確認してください。

cat > /tmp/detect-42533.sh <<'SH'
#!/bin/sh
# CVE-2026-42533: 正規表現マップの出力変数とキャプチャが
# 同一の文字列式に共存する箇所を洗い出す（ヒューリスティック）
CONF="$1"
MAPVARS=$(awk '/^[[:space:]]*map[[:space:]]/{v=$3;inmap=1;next}
               inmap&&/~/{print v}
               inmap&&/}/{inmap=0}' "$CONF" | tr -d '$' | sort -u)
[ -z "$MAPVARS" ] && { echo "正規表現マップなし: 該当なし"; exit 0; }
echo "正規表現マップ変数: $MAPVARS"
for v in $MAPVARS; do
  grep -nE "\\\$[1-9].*\\\$$v|\\\$$v.*\\\$[1-9]" "$CONF" \
    | grep -vE "^[0-9]+:[[:space:]]*(~|map)" \
    && echo "  ^ 上記が \$$v とキャプチャの同一式内共存（要確認）"
done
SH
chmod +x /tmp/detect-42533.sh
/tmp/detect-42533.sh /tmp/nginx-full.conf

検証のため、条件を満たす設定と満たさない設定の2つを用意して実行しました。条件を満たす側の設定は次のような並びです（これは検知の説明用であり、攻撃コードではありません）。

map $http_user_agent $ua_kind {
    ~^(Mozilla)/(\S+)   "$1-$2";
    default             "other";
}

server {
    location ~ ^/files/(.+)/(.+)$ {
        add_header X-Trace "$1-$ua_kind-$2";   # キャプチャ → マップ変数 → キャプチャ
        return 200 "ok\n";
    }
}

実機での検知結果は次のとおりでした。

### 条件を満たす設定
正規表現マップ変数: ua_kind
10:            add_header X-Trace "$1-$ua_kind-$2";
  ^ 上記が $ua_kind とキャプチャの同一式内共存（要確認）

### 正規表現マップの無い設定
正規表現マップなし: 該当なし

条件を満たす側だけが検知され、そうでない側は素通りしました。なお両方の設定は nginx -t で構文エラーになりません。構文チェックはこの問題を教えてくれません。

Dockerとディストリの落とし穴

パッケージやイメージの経路によって、更新のされ方が大きく違います。ここは実測しました。

Docker公式イメージ：ローリングタグは更新済み、固定タグは取り残される

2026年7月20日 JST 時点で、Docker Hub の公式 nginx イメージを実際に取得してバージョンを確認しました。

for t in latest stable mainline alpine stable-alpine 1.31.2 1.29 1.28; do
  printf "%-16s " "nginx:$t"
  docker pull -q nginx:$t >/dev/null 2>&1 \
    && docker run --rm --entrypoint nginx nginx:$t -v 2>&1
done

実測結果です。

nginxの公式イメージは素早く更新されていました。ローリングタグ（latest / stable / alpine）を使っているなら、pullし直せば修正版になります。

問題は固定タグです。nginx:1.29 を使い続けている環境は、いくらpullしても 1.29.8 のままです。そして修正版のタグが存在しないことも確認しました。

for t in 1.29.9 1.28.4 1.30.4 1.31.3; do
  printf "%-8s " "$t"
  docker manifest inspect nginx:$t >/dev/null 2>&1 && echo "存在する" || echo "存在しない"
done

1.29.9   存在しない
1.28.4   存在しない
1.30.4   存在する
1.31.3   存在する

docker pull nginx:latest
docker run --rm --entrypoint nginx nginx:latest -v
docker image inspect nginx:latest --format '{{.Created}}'

docker ps --format '{{.Names}}\t{{.Image}}' | grep -i nginx
docker exec <コンテナ名> nginx -v
docker exec <コンテナ名> nginx -T 2>/dev/null | grep -nE '^\s*map\s'

Kubernetes（ingress-nginx）：同梱nginxは別系列

Kubernetesで ingress-nginx を使っている場合、判定対象はコントローラに同梱されたnginxです。ホストの nginx -v は関係ありません。同梱バージョンを実測しました。

# コントローライメージの同梱nginxバージョンを確認
docker run --rm --entrypoint /usr/local/nginx/sbin/nginx \
  registry.k8s.io/ingress-nginx/controller:v1.12.1 -v

# 稼働中のクラスタから直接確認する場合
kubectl -n ingress-nginx get pods -o jsonpath='{.items[*].spec.containers[*].image}'
kubectl -n ingress-nginx exec deploy/ingress-nginx-controller -- \
  /usr/local/nginx/sbin/nginx -v

実測結果です。

どちらも nginx 1.25.5 を同梱しており、これは影響範囲（0.9.6〜1.31.2）に入る番号です。1.25系はすでに更新が止まった系列で、その系列としての修正版は出ていません。

# 生成された実際のnginx.confを取り出して検査する
kubectl -n ingress-nginx exec deploy/ingress-nginx-controller -- \
  cat /etc/nginx/nginx.conf > /tmp/ingress-nginx.conf
grep -nE '^\s*map\s' /tmp/ingress-nginx.conf
/tmp/detect-42533.sh /tmp/ingress-nginx.conf

さらに重い前提があります。ingress-nginx はすでに提供終了（EOL）です。 Kubernetes公式ブログが2025年11月に告知したとおり、ベストエフォートのメンテナンスは2026年3月で終了し、以降は新規リリースもバグ修正も、発見されたセキュリティ脆弱性への対応も行われません。

つまり ingress-nginx を使い続ける限り、今回のCVEに限らず今後のnginx脆弱性の修正は届きません。当初後継とされていた InGate も十分に成熟せず、こちらも取りやめとなりました。公式が案内している移行先は Gateway API、あるいは他のIngressコントローラです。ingress-nginx を運用しているなら、今回の件は移行計画を前倒しする判断材料として扱うのが妥当です。

ディストリのパッケージ：検証時点では未対応

Ubuntu Security のCVEページを確認したところ、全リリースで「Needs evaluation」の状態でした（26.04 LTS / 24.04 LTS / 22.04 LTS / 20.04 LTS など）。修正済みパッケージのバージョンは記載されていません。

つまり Ubuntu の nginx パッケージを使っている環境では、検証時点で apt upgrade を実行してもこの脆弱性は直りません。優先度は Medium と評価されています。

ディストリ利用者の選択肢は次のとおりです。

・ディストリの対応を待ち、それまで設定側の緩和（後述）で凌ぐ
・nginx公式のリポジトリ（nginx.org）からパッケージを導入して 1.30.4／1.31.3 に上げる
・コンテナ化されているなら公式イメージのローリングタグへ寄せる

自分のディストリの状況は、次のコマンドとセキュリティトラッカーで確認できます。

# Debian / Ubuntu：利用可能なバージョンと変更履歴を確認
apt-cache policy nginx
apt changelog nginx 2>/dev/null | grep -i -m5 '42533'

# RHEL系
dnf updateinfo list --security | grep -i nginx
rpm -q --changelog nginx | grep -i -m5 '42533'

侵害を受けていないかの確認

この脆弱性が実際に踏まれた場合、最も観測しやすいのはワーカープロセスの異常終了です。攻撃が成功してもしなくても、メモリ破壊はしばしばクラッシュとして表面化します。

# ワーカープロセスの異常終了をエラーログから探す
sudo grep -aiE 'worker process .* exited on signal|SIGSEGV|SIGABRT|signal 11' \
  /var/log/nginx/error.log*

# systemd 経由で動いている場合
sudo journalctl -u nginx --since '30 days ago' \
  | grep -iE 'exited on signal|segfault|core dump'

# カーネル側のsegfault記録
sudo dmesg -T 2>/dev/null | grep -iE 'nginx.*(segfault|general protection)'
sudo grep -i 'nginx' /var/log/kern.log 2>/dev/null | grep -i segfault

正常運用のnginxで worker process ... exited on signal 11 が繰り返し出るのは通常ではありません。頻度と時刻を確認してください。

コアダンプが有効なら、クラッシュの記録が残っている可能性があります。

# coredumpの設定と履歴
sudo coredumpctl list 2>/dev/null | grep -i nginx
ls -la /var/lib/systemd/coredump/ 2>/dev/null | grep -i nginx
grep -rn 'working_directory\|worker_rlimit_core' /etc/nginx/nginx.conf

アクセスログ側では、map の入力になっている値（多くはUser-Agentやホスト名、URI）に異常に長い、あるいは異常な文字列が入っているリクエストを探します。ただしこれは正常なトラフィックにも該当しうるため、単独では判断材料になりません。

# User-Agentが極端に長いリクエストを抽出（閾値は環境に合わせる）
sudo awk 'length($0) > 2000' /var/log/nginx/access.log | head -20

# 直前にクラッシュがあった時刻の前後のアクセスを突き合わせる
sudo grep -a 'exited on signal' /var/log/nginx/error.log \
  | awk '{print $1, $2}' | tail -5

サーバが乗っ取られた可能性を疑う段階なら、一般的な侵害調査に移ります。

# nginxが起点の想定外プロセス
ps -ef --forest | grep -A3 nginx | grep -vE 'grep|nginx: (master|worker)'

# nginx実行ユーザの権限で最近書き換わったファイル
sudo find /usr/share/nginx /var/www /etc/nginx -type f -mtime -30 -ls 2>/dev/null

# 想定外のアウトバウンド接続
sudo ss -tunap 2>/dev/null | grep -i nginx

# バイナリと設定の改変確認（Debian系：パッケージとの差分）
sudo debsums -c nginx 2>/dev/null
# RHEL系
rpm -Va nginx 2>/dev/null

対策手順

優先度別に整理します。

緊急（今すぐ）

修正版へ更新する。 これが唯一の恒久対策です。

# 公式リポジトリを使っている場合
sudo apt update && sudo apt install --only-upgrade nginx   # Debian/Ubuntu
sudo dnf update nginx                                       # RHEL系
sudo apk upgrade nginx                                      # Alpine

# 更新後に必ずバージョンを実測する
nginx -v
sudo nginx -t && sudo systemctl reload nginx

目標は 1.30.4 以上（stable系）または 1.31.3 以上（mainline系）、NGINX Plus は R36 P7 / 37.0.3.1 です。

Dockerの場合は、ローリングタグならpullし直し、固定タグならタグそのものを変更します。

docker pull nginx:1.31.3     # または nginx:1.30.4
docker compose up -d --force-recreate nginx
docker compose exec nginx nginx -v   # 実測して確認

nginx:1.29 nginx:1.28 を使っている場合、その系列に修正版は出ません。1.30.4 または 1.31.3 への系列移行が必要です。マイナーバージョンをまたぐため、設定の互換性を検証してから移行してください。

推奨（すぐ上げられない場合の緩和）

より確実な緩和は、該当する文字列式そのものを解消することです。手順3で検知された箇所について、次のいずれかを行います。

・キャプチャ（$1 等）とマップ出力変数を同じ文字列式に混在させない。中間変数に一度受けて分離する
・該当する map の正規表現マッチをやめ、完全一致や default ベースの分岐に置き換える
・その add_header / proxy_set_header / return などが本当に必要か見直し、不要なら削除する

前段にWAFやリバースプロキシがあるなら、map の入力となっているヘッダ（多くはUser-Agent）の異常に長い値を落とすルールも、成立条件を狭める方向に働きます。ただしこれは根本対策ではなく、入力経路が1つとは限らない点に注意してください。

変更後は必ず構文確認と再読み込みを行います。

sudo nginx -t
sudo systemctl reload nginx
nginx -T 2>/dev/null | /tmp/detect-42533.sh /dev/stdin

長期

・バージョン固定の運用を見直す。nginx:1.29 のような固定タグは、その系列のサポートが終われば修正が届かなくなる。サポート継続中の系列（stable / mainline）に寄せる
・nginx -T の定期監査をCIに入れる。設定の並びに起因する脆弱性は今後も出うる。設定ダンプに対する静的チェックを仕組みにしておく
・ワーカーの異常終了を監視対象にする。worker process ... exited on signal は、この種の問題の最初のシグナルになる
・nginx公式のセキュリティアドバイザリを購読する。nginx.org のアドバイザリページと nginx-announce メーリングリストが一次情報

同時に修正された他のCVE

1.30.4 / 1.31.3 では、CVE-2026-42533 以外に2件のセキュリティ修正が入っています。更新の判断材料になるため併記します。

nginx -V の出力に --with-http_slice_module が含まれ、かつ slice ディレクティブを使っているなら CVE-2026-60005 にも該当します。SSIを使っているなら CVE-2026-56434 も対象です。いずれも同じ 1.30.4 / 1.31.3 で修正されます。

過去のnginx CVEとの違い

2026年のnginxは修正が続いており、混同しやすい状況です。当サイトで扱った過去の件との違いを整理します。5月のNGINX Rift CVE-2026-42945：18年潜伏のヒープバッファオーバーフローとアクティブ攻撃の全容、6月のnginx 2026年6月のCVE 3件解説｜Critical 2件は条件付き、自分が対象か判定する手順と併せて読むと、傾向が見えます。

3件に共通するのは、いずれも「条件付き」で成立するという点です。CVSSの数値だけを見て一律に緊急対応するのでも、条件付きだからと放置するのでもなく、自分の設定が条件に当たるかを確認する運用が現実的です。当サイトが毎回「自システムでの確認方法」に紙面を割いているのはそのためです。

なおAIエージェント基盤やLLMのAPIゲートウェイをnginxの背後に置いている場合、nginx自体はAI固有の問題を持たなくとも、前段が落ちればサービス全体が停止します。DoSの影響は「nginxが落ちるだけ」では済まない構成が多い点も考慮してください。関連して、依存パッケージ経由の攻撃面についてはRenovate・Dependabotでサプライチェーン攻撃を防ぐも参考になります。

まとめ

・CVE-2026-42533 は実在の公表済み脆弱性。nginx公式アドバイザリ、公式変更履歴、NVDのいずれでも確認できる。影響 0.9.6〜1.31.2、修正 1.30.4 / 1.31.3、NGINX Plus は 37.0.3.1
・バージョンだけでは判定できない。正規表現マップの出力変数をキャプチャより後に参照する設定の並びが必要。nginx -T で設定を展開して確認する
・確実な影響はワーカーのクラッシュ（DoS）。「nginx RCE」として報じられているが、コード実行はF5評価では条件付き。研究者はASLR有効環境での再現を主張しているものの、第三者検証もPoC公開も現時点では無い
・ingress-nginx 利用者は移行の検討を。同梱nginxは 1.25.5 で、EOL済みのため修正は届かない
・Docker公式のローリングタグは修正済み、固定タグは取り残される。nginx:1.29 nginx:1.28 には修正版が存在しない
・Ubuntuは検証時点で全リリース未評価。apt upgrade では直らない
・名前付きキャプチャへの書き換えは部分的な緩和。恒久対策は更新のみ

PoC公開が予告されている以上、猶予は長くありません。まずは nginx -v と nginx -T を実行するところから始めてください。

参照ソース

・nginx security advisories — nginx公式のアドバイザリ一覧。CVE-2026-42533 の影響範囲（0.9.6-1.31.2）と修正版（1.31.3+, 1.30.4+）、深刻度 major の記載
・nginx CHANGES — Changes with nginx 1.31.3 — 2026年7月15日公開の公式変更履歴。脆弱性の technical な記述と謝辞（Mufeed VH／Winfunc Research、Maxim Dounin）、同時修正の CVE-2026-60005 / CVE-2026-56434
・NVD — CVE-2026-42533 — CVSS v3.1 8.1（High）／v4.0 9.2（Critical）、CWE-122、ASLR条件の記述
・F5 Security Advisory K000162097 — ベンダー公式アドバイザリ。NGINX Plus のバージョン範囲
・Critical NGINX Vulnerability Can Crash Workers and May Allow Remote Code Execution（The Hacker News） — F5の緩和策と、それが部分的である旨の報道
・CVE-2026-42533 技術解説（cyberstan） — 独立に報告した研究者による詳細分析。二段階評価とキャプチャ上書きの機序、PoC公開方針
・Ubuntu Security — CVE-2026-42533 — ディストリの対応状況（検証時点で全リリース Needs evaluation）
・Ingress NGINX Retirement: What You Need to Know（Kubernetes公式ブログ） — ingress-nginx のEOL告知。2026年3月以降はセキュリティ修正も行われない