2026 年 7 月 15 日、nginx は 1.30.4（stable）と 1.31.3（mainline）をリリースし、CVSS 9.2 のヒープバッファオーバーフロー CVE-2026-42533 を修正しました。攻撃に認証は一切不要で、細工した HTTP リクエストだけで発火します。既定のビルドではワーカープロセスがクラッシュして再起動する（サービス拒否）結果になり、ASLR が無効化されている、あるいは回避可能な環境ではリモートコード実行に発展しうります。
発火条件：map + 正規表現 + キャプチャグループ
原因は HTTP パーサーではなく、nginx の2 パスのスクリプト評価にあります。長さを計算するパスと実際に値を書き込むパスが、同一の PCRE キャプチャ状態を共有しています。正規表現を含む map ディレクティブが、同じキャプチャグループ（例えば $1）への 2 回の参照の間で評価されると、その共有状態が静かに上書きされ、2 つのパスがバッファサイズについて食い違い、領域外書き込みが発生します。
つまり、すべての nginx が攻撃可能なわけではないものの、影響範囲は極めて広いということです。0.9.6 から 1.30.3（stable）／1.31.2（mainline）まで、2011 年以降に出荷されたほとんどのビルドが該当します。商用版では NGINX Plus R33〜R36 が影響を受け（R36 P7 で修正）、37.0.0.1〜37.0.2.1 は 37.0.3.1 で修正されています。
なぜ今すぐ対応すべきか
発見者はパッチ公開後、管理者に更新の猶予を与えるため完全な解説と PoC を意図的に 21 日間伏せました。その猶予はすでに終わっています。同じ年の別の事例が速度を物語ります。2026 年 5 月に修正された CVE-2026-42945（ngx_http_rewrite_module のヒープオーバーフロー、通称「Nginx Rift」）は、修正から約 1 週間で実際の攻撃に使われ、当時インターネットに露出した nginx のうち約 570 万台が影響を受けうるバージョンで稼働していたと推定されています。半年で同種の不具合が 2 件——「一度入れたら触らない」Web サーバーが現実のリスクであることの証明です。
3 ステップの自己点検
- バージョンを見る。ただし
nginx -vだけを信じない：Debian や Ubuntu は古いバージョン番号のままセキュリティ修正をバックポートします。1.24.0 と表示されていても修正済みのことがあります。ディストリビューションのパッケージならapt policy nginxのパッケージリビジョンを確認し、apt changelog nginxで当該 CVE の記載を探してください。公式リポジトリや自前ビルドの場合のみ、1.30.4 / 1.31.3 と直接比較します。 - 設定に正規表現つきの
mapがないか調べる：grep -rn "map " /etc/nginx/を実行し、~で始まるマッチ項目と、同一リクエスト経路で$1のようなキャプチャグループを繰り返し参照している箇所に注目します。この組み合わせがなければ露出は大幅に小さくなります。 - ワーカーが静かに再起動していないか確認する：
grep -i "worker process.*exited on signal" /var/log/nginx/error.log。signal 11 での終了が繰り返されるのが典型的な兆候で、利用者側からは「たまに 502 が出る」だけに見えるため、回線の不調として片付けられがちです。
更新の手順
ディストリビューションのパッケージ：sudo apt update && sudo apt install --only-upgrade nginx のあと sudo nginx -t && sudo systemctl reload nginx。公式リポジトリや自前ビルドの場合は 1.30.4 / 1.31.3 以降へ更新し、nginx -t で確認してから reload します。reload は確立済みの接続を切りませんので、メンテナンス枠は不要です。なお同じリリースで CVE-2026-60005（ngx_http_slice_module のメモリ露出）と CVE-2026-56434（ngx_http_ssi_module の解放後使用）も修正されており、1 回の更新で 3 件が片付きます。
「自分でパッチを当てられる」ことを選定条件にする
この種の勧告にどれだけ速く動けるかは、root 権限があるか、reload のタイミングを自分で決められるかで決まります。共有ホスティングでは事業者のスケジュール待ちで、完全な error.log すら読めないことが普通です。自分の VPS なら、勧告を見てから reload まで 10 分で足ります。SharkCloud の日本・シンガポール・香港・米国ノードはいずれも独立したインスタンスで、OS と Web サーバーのバージョンはあなたの管理下にあります。次のメンテナンス枠を待つのではなく、勧告が出た当日に対応できます。