nginx 2026年6月のCVE 3件解説｜Critical 2件は条件付き、自分が対象か判定する手順

2026年6月17日、nginxが安定版1.30.3と開発版1.31.2を同時に公開した。 この2つのリリースには、3件のCVE（CVE-2026-42530 / CVE-2026-42055 / CVE-2026-48142）に対する修正が含まれる。 うち2件はCVSS 9.2のCriticalと報じられ、国内外のメディアでも「nginxに緊急パッチ」という見出しが並んだ。

ただし数値の派手さと、運用者が今すぐ動くべきかは別の話だ。 3件はいずれも既定設定のnginxでは発火しない、条件付きの脆弱性である。 この記事では、攻撃手順やPoCには触れず、運用者が「自分の環境が対象か」を判定し、修正版へ上げるところまでを、検知・防御・修正のコマンドに絞って整理する。

サーバソフトウェアの脆弱性対応を体系的に押さえたい運用者は、サプライチェーンセキュリティ2026｜攻撃手法・防御ツール・実践チェックリストも参照してほしい。本記事はその個別ケースにあたる。

3件のCVE一覧：深刻度・モジュール・影響バージョン・発火条件

まず全体像を表で押さえる。 深刻度の列には、CVSSスコアとnginx自身の深刻度ラベルの両方を併記した。 両者がずれているのが今回の特徴で、その読み方は次の節で扱う。

表で目を引くのは、CVE-2026-42055がCVSS 9.2でありながら、nginx自身は深刻度を「medium」と置いている点だ。 この差は誤記ではない。 CVSSと製品ベンダの評価が、別の前提に立っていることを示している。

なお、CVE-2026-42055の影響バージョン下限が1.13.10と古いのは、該当コードが長く存在していたことを意味する。 ただし「古くから存在する」ことと「既定で危険」であることは別問題で、発火には後述の3条件が要る。

CVSS 9.2の正しい読み方：条件付きCriticalとは何か

CVSSは「条件が最悪の形で揃った場合に、どれだけの被害が出るか」を測る指標だ。 攻撃成立の前提が満たされた瞬間の深刻度を表すのであって、「いま自分のサーバがどれだけ危険か」を直接表すものではない。

今回のCVE-2026-42530とCVE-2026-42055がCVSS 9.2になっているのは、条件が揃えば認証なしでワーカープロセスのメモリ破壊に至り、特定環境では任意コード実行まで到達しうるからだ。 裏を返せば、その「条件」を満たさない構成では、9.2という数字はそのままの重みを持たない。

BleepingComputerは、攻撃が成立した場合の帰結をこう整理している。

Successful exploitation of these issues would result in the NGINX worker process restarting, causing a denial-of-service (DoS) condition. If Address Space Layout Randomization (ASLR) is disabled or can be bypassed, the attacker can execute arbitrary code.

（訳）これらの問題の悪用が成立すると、nginxのワーカープロセスが再起動し、サービス妨害（DoS）の状態を引き起こす。ASLR（アドレス空間配置のランダム化）が無効化されている、あるいは回避できる場合、攻撃者は任意コードを実行できる。

出典: BleepingComputer: F5 issues out-of-band patches for critical NGINX vulnerabilities（2026-06-17）

ここで読み取るべき点は2つある。 1つは、まず確実に起きるのはDoS（ワーカーの再起動）であり、任意コード実行はASLRが無効、または回避可能という追加条件の上に乗るということ。 もう1つは、ASLRは多くのLinuxディストリビューションで既定有効であり、一部のコンテナや組み込み環境を除けば、RCEのハードルはDoSより高いということだ。

nginxが42055を「medium」、48142を「low」と置いているのも同じ理屈による。 ベンダは「既定設定でどれだけ起こりやすいか」を加味して深刻度を付ける。 CVSSが構成に依存しない最悪値を示すのに対し、ベンダ評価は既定構成での起こりやすさを織り込む。 運用者が見るべきは、この2つの間にある「自分のnginx.confが発火条件に該当するか」という一点だ。

「CVSS 9.2だから即危険」ではなく、「9.2の条件に自分が当てはまるか」を確認する。これが今回の3件すべてに共通する判断軸になる。

CVE-2026-42530（HTTP/3 use-after-free）の詳細と検知

CVE-2026-42530は、HTTP/3を処理するngx_http_v3_moduleで発生するuse-after-free（解放済みメモリの再使用）だ。 公式CHANGESの記述は次のとおり。

Security: use-after-free might occur when using HTTP/3 and processing a specially crafted QUIC session, allowing an attacker to cause worker process memory corruption or segmentation fault in a worker process (CVE-2026-42530).

（訳）HTTP/3を使用し、細工されたQUICセッションを処理する際にuse-after-freeが発生する可能性がある。これにより攻撃者は、ワーカープロセスのメモリ破壊またはセグメンテーション違反を引き起こせる。

出典: nginx CHANGES（1.31.2, 17 Jun 2026）

公式の表現は「細工されたQUICセッション」までで、それ以上の内部メカニズム（QPACKエンコーダストリームの再オープン等）に踏み込んだ解説が外部で見られるが、その詳細は公式アドバイザリには記載がない。 本記事では公式の記述に従い、追加のメカニズムは未確認として扱う。

自分が対象か：HTTP/3の有効・無効を確認する

このCVEはHTTP/3固有であり、対象範囲が他の2件より狭い。 3つの前提がすべて成立したときだけ対象になる。

・mainline版を使っている（バージョンが1.31.x）
・そのバージョンが1.31.0または1.31.1である
・nginxでHTTP/3（QUIC）を有効化している

安定版1.30系はHTTP/3実装の系統が異なり、このCVEの対象外だ。 まずビルドと設定の両面でHTTP/3の有無を確認する。

# ビルドにHTTP/3（QUIC）が含まれるかを確認
nginx -V 2>&1 | tr ' ' '\n' | grep -E 'http_v3|quic'

# 設定でQUIC/HTTP3をlistenしているかを確認
grep -RnE 'listen[^;]*(quic|http3)' /etc/nginx/

nginx -Vの出力に--with-http_v3_moduleが無く、設定にもquicやhttp3のlistenが無ければ、このCVEの対象ではない。 HTTP/3を明示的に有効化していない大半の環境は、この時点で対象外と判定できる。

検知：症状はワーカーの再起動

発火した場合にまず観測されるのは、ワーカープロセスのクラッシュと再起動だ。 エラーログにworker process ... exited on signal 11（SIGSEGV）が断続的に現れていないかを確認する。

# ワーカーの異常終了をログから探す（直近の傾向確認）
grep -E 'worker process [0-9]+ exited on signal (11|6)' /var/log/nginx/error.log | tail -20

ただし、この症状はメモリ不足や他の不具合でも起こりうる。 ログの兆候は「該当する可能性がある」までの材料であり、確証ではない。 最終的な判定は、バージョンとHTTP/3設定の照合で行う。

CVE-2026-42055（HTTP/2プロキシのバッファオーバーフロー）の詳細と確認

CVE-2026-42055は、ngx_http_proxy_v2_moduleとngx_http_grpc_moduleで発生するヒープバッファオーバーフローだ。 3件のなかでCVSSが9.2ながらnginx評価が「medium」と、最も差が大きい。 その理由は発火条件の厳しさにある。

Security: a heap memory buffer overflow might occur in a worker process when using a configuration with “ignore_invalid_headers off;” and “large_client_header_buffers” with large configured values when proxying a specially crafted request to HTTP/2 or gRPC backend, allowing an attacker to cause worker process memory corruption or segmentation fault in a worker process (CVE-2026-42055).

（訳）「ignore_invalid_headers off;」と、大きな値を設定した「large_client_header_buffers」を用いる構成で、HTTP/2またはgRPCのバックエンドへ細工されたリクエストをプロキシする際に、ワーカープロセスでヒープメモリのバッファオーバーフローが発生する可能性がある。

出典: nginx CHANGES（1.31.2, 17 Jun 2026）

3条件のAND：すべて揃って初めて成立する

公式の記述から、発火に必要な条件は次の3つに整理できる。 これらは「いずれか」ではなく「すべて同時」に満たされたときだけ成立する。

3条件はいずれもnginxの既定値ではない。 ignore_invalid_headersは既定でon、large_client_header_buffersの既定値は4 8kだ。 この2つを既定のまま使い、かつHTTP/2・gRPCへのプロキシをしていなければ、対象外と判定できる。

なお、large_client_header_buffersの「大きな値」が具体的に何バイト以上を指すかは、公式アドバイザリに数値の明記がない。 外部解説では2MB超を目安とする記述も見られるが、その閾値は未確認として扱う。 判断は閾値の推測ではなく、3条件すべてに該当するか否かで行うのが安全だ。

nginx.confの設定を確認する

自分の設定が3条件に当たるかは、grepで該当ディレクティブの有無を見るだけで判定できる。 これは設定を読むだけのコマンドであり、攻撃とは無関係だ。

# (1) ignore_invalid_headers off; が設定されているか
grep -RnE 'ignore_invalid_headers\s+off' /etc/nginx/

# (2) large_client_header_buffers の設定値を確認
grep -RnE 'large_client_header_buffers' /etc/nginx/

# (3) HTTP/2 もしくは gRPC バックエンドへのプロキシ設定があるか
grep -RnE 'grpc_pass|proxy_http_version\s+2|http2' /etc/nginx/

(1)が何も返さなければ、ignore_invalid_headersは既定のonであり、その時点で対象外だ。 3つすべてに該当して初めて、このCVEの修正を急ぐ理由になる。

認証ゲートウェイ運用での位置づけ

3条件が揃いやすいのは、nginxをHTTP/2やgRPCのリバースプロキシ、あるいは認証ゲートウェイとして使い、ヘッダ検証を緩めている構成だ。 ignore_invalid_headers off;は、独自ヘッダを通すために明示的に設定されることがある。 こうした構成のnginxは、3条件の(1)を自前で満たしている可能性がある。 該当する運用者は、残る2条件と合わせて優先的に確認しておきたい。

CVE-2026-48142（charsetモジュールのバッファオーバーリード）の詳細

CVE-2026-48142は、ngx_http_charset_moduleで発生するヒープバッファオーバーリード（確保範囲外の読み取り）だ。 3件のなかで影響が最も限定的で、nginx評価は「low」とされている。

Security: a heap memory buffer overread might occur in a worker process while handling a specially sent response with decoding from UTF-8 via the “charset_map” directive, allowing an attacker to cause a limited disclosure of worker process memory or segmentation fault in a worker process (CVE-2026-48142).

（訳）「charset_map」ディレクティブによりUTF-8からデコードしながら、細工された応答を処理する際に、ワーカープロセスでヒープメモリのバッファオーバーリードが発生する可能性がある。これにより、ワーカープロセスメモリの限定的な漏えい、またはセグメンテーション違反を引き起こせる。

出典: nginx CHANGES（1.31.2, 17 Jun 2026）

公式の記述で起点とされているのは、charset_mapディレクティブによるUTF-8デコードだ。 影響は「限定的なメモリ漏えい、またはセグメンテーション違反」とされ、コード実行には言及がない。 帰結の重さがCVE-2026-42530・42055より一段低いことが、「low」評価に表れている。

自分が対象か：charset_mapの利用を確認する

charset_mapによる文字コード変換を設定していなければ、起点となるデコード処理が走らない。 設定の有無はgrepで確認できる。

# charset_map / charset / source_charset の設定有無を確認
grep -RnE 'charset_map|source_charset|^\s*charset\s' /etc/nginx/

charset_mapが設定されていなければ、このCVEの起点には当たらない。 影響範囲が広いバージョン（0.3.50以降）に及ぶ一方で、深刻度はlowにとどまる点を踏まえ、優先度は42530・42055の次に置くのが妥当だ。

判定フローチャート：自分が対象か3点で見分ける

ここまでの3件を、1つの判定フローにまとめる。 HTTP/3の有無、HTTP/2・gRPCプロキシの3条件、charset_mapの利用、という3つの入り口で振り分ける。

このフローで「非該当」に着地しても、修正版へのアップグレード自体は推奨される。 発火条件に該当しないことと、脆弱なコードを抱えたままにすることは別であり、次の定期メンテナンスで修正版へ上げておくのが運用上の落としどころだ。

修正版とアップグレード手順（apt / yum / Docker）

修正版は安定版1.30.3と開発版1.31.2で、いずれも2026年6月17日に公開された。 公式告知は次のとおり。

nginx-1.30.3 stable and nginx-1.31.2 mainline versions have been released, with fixes for buffer overflow vulnerability in the ngx_http_proxy_v2_module and ngx_http_grpc_module (CVE-2026-42055), and buffer overread vulnerability in the ngx_http_charset_module (CVE-2026-48142). Additionally, nginx-1.31.2 includes a fix for use-after-free vulnerability in the ngx_http_v3_module (CVE-2026-42530).

（訳）安定版nginx-1.30.3と開発版nginx-1.31.2を公開した。proxy_v2・grpcモジュールのバッファオーバーフロー（CVE-2026-42055）と、charsetモジュールのバッファオーバーリード（CVE-2026-48142）を修正している。加えて1.31.2には、v3モジュールのuse-after-free（CVE-2026-42530）の修正も含まれる。

出典: nginx news: 2026

この告知から、系統ごとの選び方が決まる。

apt（Debian / Ubuntu、nginx公式リポジトリ）

ディストリ標準のnginxはバージョンが古い場合がある。 nginx公式リポジトリを使っている環境では、次の手順で更新する。

# パッケージ情報を更新し、入手可能なnginxバージョンを確認
sudo apt update
apt-cache policy nginx

# nginx を更新
sudo apt install --only-upgrade nginx

# バージョンが修正版になったか確認
nginx -v

yum / dnf（RHEL系）

# キャッシュを更新し、nginx を更新
sudo dnf makecache
sudo dnf update nginx

# バージョン確認
nginx -v

ディストリの標準リポジトリではバージョンが1.30.3や1.31.2に届かない場合がある。 その際はnginx公式リポジトリの導入を検討するか、ディストリのセキュリティバックポート（修正だけを取り込んだパッケージ）が出ているかを確認する。

Docker

イメージタグを修正版に固定して入れ替える。

# 安定版なら 1.30.3、mainline なら 1.31.2 を取得
docker pull nginx:1.30.3

# 既存コンテナを停止・削除し、新イメージで起動し直す
docker stop my-nginx && docker rm my-nginx
docker run -d --name my-nginx -p 80:80 -p 443:443 \
  -v /etc/nginx:/etc/nginx:ro nginx:1.30.3

# コンテナ内でバージョンを確認
docker exec my-nginx nginx -v

latestタグ運用でも、明示的にdocker pullしてからコンテナを作り直さないと、古いレイヤーが残ることがある。 更新後は必ずnginx -vでバージョン表記を確認する。

アップグレードできない場合の暫定回避策

修正版への更新がすぐにできない事情がある場合、発火条件を崩す暫定回避で時間を稼げる。 いずれも防御側の設定変更であり、攻撃の成立を妨げる方向の対応だ。

CVE-2026-42530（HTTP/3）は、QUICのlistenを一時的に外せば起点を断てる。

# HTTP/3（quic）のlisten行を確認し、暫定的に無効化する箇所を特定
grep -RnE 'listen[^;]*quic' /etc/nginx/
# 該当行をコメントアウトしたうえで構文検証・再読み込み
sudo nginx -t && sudo nginx -s reload

CVE-2026-42055は、3条件のどれか1つを崩せば成立しなくなる。 最も影響が少ないのは、ignore_invalid_headersを既定のonへ戻す方向だ。

# off になっている箇所を洗い出し、on へ戻せるか検討する
grep -RnE 'ignore_invalid_headers\s+off' /etc/nginx/
# 変更後は必ず構文検証してから反映
sudo nginx -t && sudo nginx -s reload

CVE-2026-48142は、charset_mapによるUTF-8デコード設定の必要性を見直す。 不要なら外し、必要なら修正版への更新を優先する。

暫定回避はあくまで時間稼ぎだ。 設定変更がアプリケーションの挙動に影響しないかをステージングで確認したうえで適用し、本対応として修正版へのアップグレードを計画する。

検知方法：バージョン確認とログ監視のポイント

対応の起点は、稼働中のnginxバージョンを正確に把握することだ。 プロセスとして動いているバイナリと、設定上のバージョンがずれていることもあるため、実体を確認する。

# 稼働バイナリのバージョンとビルドオプションを確認
nginx -v
nginx -V 2>&1 | tr ' ' '\n' | grep -E 'nginx/|http_v3|http_v2'

# 実際に動いているマスタープロセスの実行パスを確認
ps -o pid,cmd -C nginx | head

複数ホストを束ねている場合は、構成管理ツールやSCA（ソフトウェア構成分析）ツールでバージョンを横断的に棚卸しすると、対象ホストの特定が早い。 コンテナイメージ・ホスト双方をスキャンできるツールを使えば、「どこに古いnginxが残っているか」を機械的に洗い出せる。

ログ面では、ワーカープロセスの異常終了が継続して観測されないかを監視する。 前述のとおり、worker process ... exited on signal 11の頻発は手がかりにはなるが、それ単体では確証にならない。 バージョンと発火条件の照合を主、ログ監視を従として組み合わせるのが妥当だ。

関連する過去のnginx CVEと位置づけ

nginxのCVEは、影響範囲と発火条件の組み合わせで性格が大きく変わる。 2026年に公表された主要なnginx関連CVEを時系列で並べると、今回の3件の位置づけが見えやすい。

2026年5月に公表されたCVE-2026-42945（通称NGINX Rift）は、ngx_http_rewrite_moduleに18年潜伏したヒープバッファオーバーフローで、公表直後にアクティブ攻撃が観測された事例だった。 今回の3件は、現時点で大規模な攻撃が報じられているわけではなく、発火条件も限定的という点でRiftとは性格が異なる。 Riftの背景と緩和策はNGINX Rift CVE-2026-42945：18年潜伏のヒープバッファオーバーフローとアクティブ攻撃の全容で詳しく扱っている。

サーバ脆弱性をどう棚卸し・追跡するかという運用面では、構成情報の整理が前提になる。 ソフトウェア部品表（SBOM）の考え方はSBOM入門｜ソフトウェア部品表でサプライチェーンの可視化を始めるが参考になる。 nginxのような基盤ソフトの版数を機械的に追える状態にしておくと、新規CVE公表時の影響範囲特定が早くなる。

参考リソース

一次情報は、nginx公式アドバイザリとCHANGES、各CVE個別のF5アドバイザリだ。 深刻度の解釈は、CVSS値とnginx自身のラベルの両方を見比べてから判断したい。

・nginx公式: security advisories（CVE一覧と修正版の対応）
・nginx公式: CHANGES（1.31.2 / 1.30.3 のSecurity項目の逐語記述）
・F5: 各CVE個別アドバイザリ（K000161616 / K000161584 / K000161585）
・MITRE / CVE.org・NVD: CVE-2026-42530 / 42055 / 48142 のレコードとCVSS

まとめ

nginxが2026年6月17日に公開したCVE 3件は、CVSS 9.2のCriticalを2件含むが、いずれも既定設定では発火しない条件付きの脆弱性だ。 CVE-2026-42530はHTTP/3を有効にしたmainline 1.31.0／1.31.1、CVE-2026-42055はHTTP/2・gRPCプロキシで3条件が揃った構成、CVE-2026-48142はcharset_mapでUTF-8デコードを使う構成が対象になる。

運用者がまず行うのは、攻撃の心配をすることではなく、nginx -vとnginx -V、そしてnginx.confのgrepで「自分が対象か」を判定することだ。 対象なら、安定版は1.30.3、mainlineは1.31.2へ上げる。 すぐ上げられないなら、HTTP/3の無効化やignore_invalid_headersを既定へ戻すといった設定変更で発火条件を崩し、時間を稼ぐ。

CVSSの数字は、条件が揃った場合の最悪値を示す道しるべであって、優先度そのものではない。 9.2という値に反応するのではなく、その条件に自分が該当するかを確認する。 この順序を守ることが、限られた運用リソースを正しく配分する近道になる。