NGINXで5件の脆弱性を修正！HTTP/3やTLSを含む設定別の影響と更新確認

10月14日の修正を設定単位で確認する

NGINXは2026年10月14日、stable系列の1.30.6とmainline系列の1.31.7を公開しました。公式の変更履歴には5件のセキュリティ修正が記載されています。本記事は10月19日に一次資料を確認し、日本のWeb開発・サイト運営で確認したい影響条件と対応を整理したものです。今日新たに発見された脆弱性として扱うものではありません。

公表・修正リリース日は10月14日、情報確認日は10月19日です。被害の発生日や、個別サイトへ侵入が行われた日時とは異なります。今回参照した公式のアドバイザリー一覧と変更履歴だけでは、実際の悪用状況は判断できません。「悪用はない」とも「攻撃が急増している」とも断定しません。

重要なのは、NGINXを使っているという事実と、各問題の影響条件がそろうことを分けることです。公開側のリバースプロキシだけでなく、静的ファイル配信、TLS終端、内部向けの入口にも使われます。最初に稼働構成と担当範囲を把握してから、配布元が案内する修正へ進みます。

出典：NGINX公式｜1.31.7の変更履歴

修正された5件とバージョン範囲

次の表はNGINX公式アドバイザリー一覧をもとにした整理です。同一覧は5件をmediumと評価しています。本記事では別の評価主体のCVSSと混ぜて、すべて同じ数値の深刻度であるかのようには表示しません。表の範囲は上流版の情報であり、OS配布元による修正の取り込み状況を表すものではありません。

CVE	関係する機能	上流版の影響範囲
CVE-2026-15176	aliasとrewrite	0.1.29〜1.31.6
CVE-2026-93479	変数を含む文字列の評価	1.31.2〜1.31.6／1.30.0〜1.30.5
CVE-2026-95101	HTTP/3の本文処理	1.25.0〜1.31.6
CVE-2026-97629	TLSセッションチケット	1.23.2〜1.31.6
CVE-2026-97205	AIOとSSI	0.8.11〜1.31.6

5件とも上流版の修正先は1.30.6（stable）または1.31.7（mainline）以降です。各範囲内でも機能・設定条件との照合が必要です。

出典：NGINX公式｜セキュリティアドバイザリー

HTTP/3とTLSの問題を混同しない

公式変更履歴によると、CVE-2026-95101はHTTP/3で未知のフレームの一部を本文と扱うことがあり、client_max_body_sizeの制限回避や転送先へのデータ注入につながる可能性があります。CVE-2026-97629はTLSセッションチケットの鍵ローテーション時に鍵の一つが未初期化となり、セッションを偽造できる可能性がある問題です。

これはサイト全体のすべての認証が必ず突破されるという説明ではありません。TLSのセッションと、アプリケーションが管理するログインセッションを区別してください。入口で使う仕組みを調べずに、利用者のパスワード変更だけで本件の修正を代替することもできません。

本サイトの提案として、HTTP/3をどこで終端するかを確認します。例えばCDNとオリジンサーバーを組み合わせる構成なら、利用者からCDN、CDNからオリジンという二つの通信区間を分けます。外側がHTTP/3であるだけで、内側のNGINXも同じプロトコルを処理しているとは限りません。逆に、CDNがあるだけでオリジンへの直接到達が防がれているとも限りません。

TLSについても、証明書の有効期限を点検する作業と、セッションチケットを扱う設定・実装の更新を区別します。設定確認は必要ですが、特定の指示子を一つ変更すれば5件すべてを回避できるという一律の回避策は、今回確認した資料からは示せません。

出典：NGINX公式｜1.30.6の変更履歴

ファイル配信と変数評価の条件も点検する

残る3件はメモリーの扱いに関する修正です。CVE-2026-15176はaliasとrewriteを使い、変更されたURIをファイルパスへ対応付ける場合のバッファーオーバーフローです。CVE-2026-93479は変数を含む文字列の評価に関係し、http・streamのドキュメントルート計算やリクエストのログ記録に影響します。CVE-2026-97205はAIO利用時の特定構成で、SSIページのinclude virtualが関係する解放後使用です。

本サイトの提案は、設定ファイル内に単語があるかという検索を、確認の入口として使うことです。aliasが見つかったら該当するlocationとURIの扱い、SSIとAIOが見つかったらどのコンテンツに適用するかを追います。設定の存在だけで悪用可能と断定せず、見つからないことだけで全体が無関係とも判断しないでください。

仮想例として、アプリケーションの入口は単純なproxy_passでも、画像の配信先だけ別の設定ファイルでaliasを使っている構成を考えます。表側の設定だけ読むと見逃すため、includeで読み込む設定や、コンテナーに注入される設定も対象にします。共通テンプレートに一度修正を入れた場合も、全インスタンスへの反映状況は別に確認します。

出典：NGINX公式｜1.31.7の変更履歴

更新対象はホスト名ではなく稼働単位で洗い出す

ここからは本サイトによる対応手順の提案です。まず、公開ホスト、ロードバランサーの背後、管理用ゲートウェイ、ジョブ用コンテナーなど、NGINXが動く場所を挙げます。各項目へ、利用者からの到達性、機能、配布元、現在のパッケージ、更新担当を記録します。更新権限がないレンタルサーバーでは、提供会社へ対応状況を確認してください。

一つのドメインが複数台で応答する構成では、1台だけの確認では不十分です。コンテナーでは、レジストリのイメージが更新済みでも古いイメージから作られた稼働中の個体が残ることがあります。イメージの識別子、デプロイ先、実際の稼働個体を対応付けると、更新漏れを追いやすくなります。

OS配布元が修正を取り込む場合、上流の版番号だけでは判定できないことがあります。導入済みパッケージの版と、配布元が示す当該CVEの対応状況を照合します。本記事は特定のLinux配布物やコンテナー製品が修正済みであると確認したものではありません。古い番号だから直ちに未修正、新しい表示だから必ず安全という両方の早合点を避けてください。

優先順位は、外部から到達できるか、該当する機能が有効か、停止したときの影響が大きいかを合わせて決めます。内部向けも、侵入後の移動経路や他サービスからの到達を考慮し、一覧から除外するのではなく公開側との実施順序を判断します。

設定テストとバイナリー更新は別の確認

公式のコマンドライン資料では、nginx -vは版、nginx -Vは版・コンパイラー・ビルド設定、nginx -tは構文と参照ファイルの確認、nginx -Tはそれに加えて設定を標準出力へ表示する操作とされています。使用する場合は、サービスが利用する実行ファイルと設定パスを確認してください。

本サイトの提案として、これらの結果を作業記録へ残す場合はアクセス権を制限します。設定出力に認証情報や内部接続先が含まれる可能性があるため、公開チケットやチャットへ無加工で貼らないでください。また、構文テストが成功することは、脆弱性が修正されたことや、決済などの業務が正常に動くことの証明ではありません。

パッケージを更新した後は、稼働プロセスにも修正が反映されたかを確認します。公式のプロセス制御資料は、設定の再読み込みと実行ファイルの更新を区別しています。設定をreloadしただけで、ディスク上の新しい実行ファイルへ必ず切り替わると考えないでください。

実施方法はOSやサービス管理、コンテナーの運用に合わせます。通常の更新手順で再起動するのか、段階的に再配置するのか、専門的な無停止バイナリー更新を行うのかを事前に決めます。記事のコマンドをそのまま本番で試すのではなく、保守手順に沿って検証環境から実施してください。

出典：NGINX公式｜コマンドライン引数

更新後に確認したいのは実際の通信経路

本サイトが勧める検証は、トップページが表示されるかだけではありません。APIの送信、アップロード、静的ファイル配信、認証を要する経路など、実際に使用する機能を確認します。HTTP/3を利用している場合は、HTTP/2へ自動的に切り替わった成功結果だけを見て、同じ経路の試験が終わったと扱わないようにします。

ファイル配信の試験では、許可されたテスト用データを使い、URIと返される内容の対応を確認します。アップロード上限の試験も、運用者が許可した検証環境で行ってください。本番へ攻撃用の入力を送信して脆弱性を再現することを、更新確認の必須条件にはしません。

複数台構成なら、切り替え前後のエラー率や応答時間に加えて、全個体が期待した版へ移行したかを記録します。旧workerが接続を処理し終えるまで残る仕組みもあるため、残存している理由と終了状況を確かめます。更新コマンドの終了コードだけでなく、稼働状態までを完了条件にします。

切り戻し条件も先に決めます。障害対応で未修正版へ戻す場合は、公開範囲の縮小などを合わせて再判断し、元に戻したことを安全性の回復と混同しないでください。更新後に異常があれば、時刻、対象個体、設定差分、ログを保全し、修正作業と原因調査を切り分けます。

出典：NGINX公式｜プロセス制御と実行ファイルの更新

今回分かることと分からないこと

今回の5件は、上流の1.30.6と1.31.7に修正が含まれること、影響する機能とバージョン範囲が一次資料で確認できるニュースです。一方、特定サイトの悪用、侵害件数、AIによる攻撃、各配布元の修正済みパッケージまでは本記事で確認していません。確認できなかった数値や状況は補いません。

対応は、稼働場所の棚卸し、設定条件と配布元の確認、更新計画、プロセスの切り替え、業務経路の検証の順で進めます。目的はNGINXの番号を新しく表示することではなく、必要な通信を維持しながら、修正された実装が実際のリクエストを処理する状態へ移すことです。