過去の記事の日付: 2026-10-14 (開示およびセキュリティ リリース日)。出典はチェックされ、2026-10-27 を通じて情報が補足されました。

この記事はイベントの日付ごとにアーカイブされます。 10 月 14 日以降にリリースされたバージョンおよびリリースの更新は以下に含まれます。 対象者: NGINX Open Source / NGINX Plus Web サイトおよびリバース プロキシの運用保守担当者、セキュリティ対応担当者、配布保守担当者、および NGINX をセルフコンパイルしてサードパーティ モジュールを保守するエンジニア。

この記事では、2026 年 10 月 14 日に公開され集中的に修正された 5 つの NGINX コア脆弱性に焦点を当て、また、2026 年 5 月から 9 月までの代表的なメモリの安全性とリクエストの整合性の脆弱性を振り返ります。内容は、トリガー条件、コードレベルの原因、影響範囲、修復ワークフロー、短期的な軽減策、公式パッチの実装、古いブランチへのバックポート、および運用検証をカバーしています。 S1 などの参照は、ソース付録へのリンクです。構成例は、展開と監査のアイデアを説明するためにのみ使用されており、実装前に実際のバージョン、構成の継承、依存関係、ビジネス能力に基づいて検証する必要があります。

TL;DR: 優先アクション

  1. セキュリティのアップグレードを優先します。のために nginx.org オープンソースパッケージ、アップデート Stable 1.30 少なくとも分岐する 1.30.6 そして Mainline 1.31 少なくとも分岐する 1.31.7. 認証日の時点では、 1.31.8 最新です Mainline リリース。これらは個別のブランチ ベースラインです。ブランチ間でその数を比較しないでください。 S1 S2
  2. 完全なパッケージ バージョンで配布インストールを確認します。 Ubuntu 22.04 / 24.04 / 26.04 / 26.10 ベンダーのバックポートがある。 Debian 13 ( trixie ）少なくとも必要です 1.26.3-3+deb13u10 。検証では、 Debian 12 ( bookworm ） パッケージ 1.22.1-9+deb12u10 まだ影響を受けているとマークされています。各 CVE を確認します。の Debian 13勧告はそれを確立していません Debian 12は固定です。 S13 S14 S15
  3. 5 つの構成の組み合わせを監査します。 alias + rewrite + $request_filename , map + 正規表現 + 変数評価、 aio + ssi + include virtual , HTTP/3 と proxy_request_buffering on 、 そして ssl_session_cache shared:... 自動付き TLS セッションチケットキーのローテーション。ディレクティブの存在だけでは悪用可能性は確立されません。リクエストのパスと構成の範囲を評価します。 S1 S3 S4
  4. 古いプロセスとコンテナをすべて置き換えます。 nginx -t を実行し、サービスを再起動するか、高可用性のローリング展開を実行します。古い master/worker プロセスが終了していることを確認します。 nginx -s reload だけでは、実行中のバイナリが変更されたことを証明することはできません。
  5. 実際のエンドポイントを確認します: HTTP/1.1、HTTP/2、HTTP/3 (有効な場合)、プロキシ アップロードと API リクエスト本文、mTLS 証明書認証、SSI ページとアクセス ログ。各エンドポイントのパッケージの出所、バージョン、イメージ ダイジェスト、実行中のプロセスと結果を記録します。
  6. 即時アップグレードが不可能な場合は、該当するトリガー条件を削除します。不要なトリガー条件を無効にします。 SSI / AIO または HTTP/3 、レビューの脆弱性 alias / rewrite / map 変数参照、および一時的な評価 ssl_session_tickets off; 影響を受けた人のために mTLS サービス。 WAF , ASLR 、レート制限と構成の変更は一部の条件のみをカバーし、公式パッチを置き換えることはできません。 S3 S4 S8 S12

1. 脆弱性の概要とリスク判断

NGINX は 2026 年 10 月 14 日に 1.30.6（Stable）と 1.31.7（Mainline）をリリースし、5 件のセキュリティ問題を修正しました。このうち 3 件はヒープバッファオーバーフローまたは解放後使用で、F5 の CVSS v4.0 評価はそれぞれ 9.2 / Critical です。残る 2 件は HTTP/3 リクエストの完全性と TLS クライアント証明書認証に影響します。S1S2S3

評価体系を区別する必要があります。nginx.org は 5 件すべてを medium としていますが、F5 の CVSS v4.0 評価や一部の国家セキュリティ機関は、3 件のメモリ安全性の問題を Critical と分類しています。これは 5 件すべてで無条件にリモートコード実行が可能という意味ではありません。設定、通信経路の到達可能性、攻撃者が制御できない条件を考慮する必要があります。メモリ破壊の発生と、安定した RCE の成立は異なる証拠水準です。S1S3S4

CVE技術的な問題と一般的なトリガー条件コアインパクト評価と廃棄
CVE-2026-15176alias パスマッピング + rewrite 変更 URI + 評価 $request_filenameヒープ バッファ オーバーフロー、Worker クラッシュ。特定の条件下で潜在的な RCEF5 CVSS v4.0 9.2;トラブルシューティングを優先する
CVE-2026-93479HTTP/Stream スクリプト評価、特に map 正規表現キャプチャと root ディレクトリ、ログ変数の相互参照予約されたバッファが上書きされ、ヒープがオーバーフローします。特定の条件下で潜在的な RCEF5 CVSS v4.0 9.2;前回の修復後の回帰リスクがある
CVE-2026-97205SSI 仮想インクルードおよび AIO/非同期操作。未処理の操作数のオーバーフローUse-After-Free、Worker クラッシュ、メモリ破損。潜在的な RCEF5 CVSS v4.0 9.2;デフォルト以外の構成が必要です
CVE-2026-95101HTTP/3 不明なフレームがバッファ間で断片化されており、プロキシ リクエスト本文のバッファリングが有効になっています非 DATA バイトをアップストリームのリクエスト本文に誤って挿入し、リクエスト本文のサイズ制限をバイパスしている可能性があります。この脆弱性はリクエストの整合性に影響します。それ自体はリモート コード実行 (RCE) を提供しません。
CVE-2026-97629共有 TLS セッション キャッシュ、自動キー ローテーション、および Worker キー ミラーリングセッションチケットの偽造。影響を受ける mTLS サービスでクライアント証明書の認証バイパスが発生する可能性があります証明書認証タイプ API のビジネスへの影響には特別な注意を払う必要があります。

上記の CVSS スコアは F5 による v4.0 評価です。同じ脆弱性でも、CVSS 3.1、nginx.org 独自の分類、ディストリビューションの評価では重大度が異なる場合があります。S1S3S4

1.1 CVE スコアだけではなく展開の公開を優先する

導入形態調査のポイント廃棄の優先推奨事項
パブリック ネットワーク リバース プロキシ (カスタマイズされた rewrite、alias、および複雑な map を含む)5 月から 7 月にかけての CVE-2026-15176、CVE-2026-93479 および書き換え/マップの脆弱性P0: すぐに監査して更新します
API / クライアント証明書を唯一またはメインの入口認証として使用する管理プレーンCVE-2026-97629のセッションチケットと共有キャッシュ構成P0: 認証境界を直ちに確認して更新します
外部 HTTP/3 アップロード、ステータス変更インターフェイス、トランザクション クラス API を提供しますCVE-2026-95101、特にリクエスト本文はバックエンドにプロキシされますP0/P1: ビジネスの重要性に応じて配置
SSI 動的ページまたは非同期ファイル I/OCVE-2026-97205P1：組み合わせ条件を確認し、早めに修理してください
静的ページのみ + 単純な HTTP/1.1/2 リバース プロキシ構成とバージョンは引き続き監査する必要がありますが、一部の CVE 条件が欠落している可能性がありますP1: 緊急セキュリティ アップグレード ウィンドウに含まれる
廃止された Kubernetes コミュニティ ingress-nginx を使用するプロジェクトはセキュリティ保守を停止し、リスクはこれら 5 つの CVE に限定されません個別のコントローラーの移行計画を立てる

P0/P1 は、この記事で説明されている、パブリック ネットワークの露出と認証の機密性に関する運用および保守の廃棄に関する提案です。これは正式な CVSS 分類ではなく、企業の内部資産を置き換えたり、リスク評価を変更したりすべきではありません。

1.2 衝撃境界と攻撃権限

このバッチの中核となる脆弱性は主に NGINX データ プレーンにあります。攻撃のエントリ ポイントはクライアント接続とリクエストであり、実際の影響は通常、Worker プロセスで発生します。メモリ破損の悪用可能な条件が満たされた場合、コードの実行権限は通常、実行中のユーザー、コンテナの制約、Linux の機能、Worker のマウントおよびネットワーク権限によって制限されます。潜在的な RCE は、自動的に root 権限やホストの侵害を意味しません。 S4

ただし、プロセスに特権がない場合でも、プロキシ資格情報、証明書の秘密キーを含む読み取り可能なファイル、アップストリーム サービス トークン、一時ファイル、内部 API、および到達可能なネットワークにアクセスできる可能性があります。 mTLS の場合、認証バイパス自体がビジネスに重大な影響を与える可能性があり、必ずしもコードの実行を伴う必要はありません。

2. 原因分析

2.1 NGINX でエラーが発生しやすい 3 つの境界を理解する

NGINX worker は、リクエスト ステータス、非同期操作、およびプロトコル パーサーを維持する、存続期間の長いイベント駆動型のプロセスです。この脆弱性は、次の 3 つのエンジニアリング レベルでの制約を具体化しています。

  1. 変数の評価とメモリ サイズは一貫している必要があります: rewrite リクエスト URI を変更した後、パス マッピングは現在有効な location と一貫している必要があります。スクリプト インタプリタが可変長を計算するとき、書き込みスペースは実際の出力領域と予約領域をカバーする必要があります。
  2. 非同期操作では、要求されたメモリのライフ サイクルを延長する必要があります。未完了のファイルの読み取りと書き込み、キャッシュ待機、またはスレッド タスクがある場合、関連する要求メモリ プールを事前に解放することはできません。
  3. プロトコル ステータスとセキュリティ ステータスを混合または省略することはできません: HTTP/3 不明なフレーム スキップの長さを DATA リクエスト ボディの長さと見なすことはできません。 TLS 署名検証に参加するすべてのキー スロットは、セッション チケットのローテーション中に正しく初期化され、同期される必要があります。

以下の内容は、 NGINX アップストリームの修正コミットとベンダーの発表で、引き起こされる可能性のある障害メカニズムを説明します。サンプルのフラグメントは分析用であり、運用環境の修復に直接使用できる完全なコードではありません。 S5 S6 S7 S8 S9

2.2 CVE-2026-15176: alias と書き換えられた URI の間のパス マッピングが無効です。

NGINX では、一致した location とその alias によってファイル パスが決まります。 rewrite は現在のリクエスト URI を変更できます。書き換え後は、元の location マッピングで使用されていた前提が当てはまらなくなる可能性があります。

影響を受ける処理パスは、ngx_http_map_uri_to_path() の alias ステータスをチェックするときに、リクエストが書き換えられたかどうかを適切にチェックしませんでした。再書き込み後に構成が $request_filename の評価を継続すると、現在の URI 状態に準拠しない仮定でパスが構築される可能性があり、最終的にはヒープ メモリへの範囲外書き込みがトリガーされます。 S5

一般的な組み合わせ (構成監査の反例としてのみ使用され、導入は推奨されません):

# 仅用于识别风险模式：不是修复配置
location /foo/ {
    alias /srv/alias-root/;
    rewrite ^/foo/.*$ /new-path;
    return 200 $request_filename;
}

危険はそれだけではありません return : set , if , add_header , log_format 、などの場合も監査が必要です。 $request_filename 評価は同じリクエストプロセスでトリガーされます。 return この例では、この状態パスを見やすくするだけであり、すべての実稼働構成でオーバーフローが発生することを推測するために使用することはできません。 S5 S10

攻撃の結果: リクエストを作成すると、次のような問題が発生する可能性があります。 Worker 再起動またはサービスの中断。などの条件下で ASLR 閉鎖されているかバイパスできる場合、潜在的な可能性があります。 RCE 。上流パッチの核心は、書き換えの完了を拒否することです。 URI のパスマッピング alias 単に特定のバッファを拡張するのではなく、無効になったコンテキストを拡張します。 S5 S10

2.3 CVE-2026-93479: スクリプト評価における「予約スペース」と実際の変数長の不一致

NGINX の HTTP および Stream モジュールには、リテラル文字列と変数値を結果文字列に連結するスクリプト エバリュエーターがあります。アプリケーションの例には、HTTP ドキュメント root のパス、アクセス ログのパス、Stream の変数式が含まれます。

map + 正規表現の特定の構成では、map 結果変数が評価される前に、キャプチャされた値を他の式で読み取ることができます。予約された長さのスクリプト実行方法と組み合わせると、古い実装では、len の予約スペースが事前に評価された長さのアキュムレーターにカウントされるため、後続の書き込みポインターの計算はバッファー境界と一致しなくなります。特定の変数評価シーケンスでは、後続の文字列の書き込みにより予約領域が上書きされ、ヒープ オーバーフローが発生する可能性があります。 S6

参加型要素なぜ注目する価値があるのか
mapの正規表現キャプチャ変数の評価には独立したライフサイクルとキャッシュ動作がある場合があります
$1、$2 などの匿名キャプチャ。他の正規表現や表現によって簡単に上書きされるため、所有権の追跡が困難になります
root の変数パス構築トリガー時のスクリプト実行とバッファ予約
log_format/動的ログパス同じタイプの評価がリクエストの後半でトリガーされる可能性があります
stream のスクリプト式アップストリームの修正では、ngx_stream_script_run() も変更されます。 HTTP モジュールのみをレビューすることはできません。

重要な回帰関係: この脆弱性に関連するコードは、修正された以前の変更に関連しています。 CVE-2026-42533 。公式 DSA は、 Debian 13 には、影響を受けるコードが導入されたことが明確に記載されています。 trixie 以前のセキュリティ バックポート経由でパッケージ化されます。そこで、「7月」 map 脆弱性パッチがインストールされました」というメッセージは、10 月のパッチを意味するものではありません。 CVE-2026-93479 カバーされています。完全なセキュリティ修正チェーンをチェックする必要があります。 S6 S14 S17

ここでの潜在的な RCE リスクはメモリ保護環境に関連しており、map 正規表現だけが匿名の攻撃者によって悪用される可能性があると主張すべきではありません。 S11

2.4 CVE-2026-97205: AIO 未完了の操作数のラップアラウンドにより Use-After-Free が発生する

この脆弱性は単に「SSI をオンにすると UAF が発生する」というものではありません。鍵となるのは、メインリクエストが保持する非同期操作の参照カウントです。

NGINX まだ完了していない非同期処理を追跡するには、r->main->blocked を使用します。古い実装では、8 ビット数でした。一部のパスは、カウントを増加する前に上限チェックを実行しませんでした。同じメイン リクエストに 256 の未処理のオペレーションが蓄積されると、カウントは 255 から 0 に循環する可能性があります。後続のプロセスは、リクエストの解放を妨げる非同期オペレーションが存在しないと誤って認識し、その結果、タスクによってまだ参照されているリクエスト メモリ プールが解放されます。 S7

失敗のプロセスは次のように分類できます。

  1. 関連する非同期 I/O/スレッド パスが有効になっているため、SSI ページには、include virtual を介した複数のサブリクエストまたは読み取り操作が導入されます。
  2. 特定のメインリクエストの未処理のオペレーションは、count フィールドで示される上限まで蓄積されます。
  3. 8 ビットのカウントが循環し、「保留中の操作がない」と誤って表現されます。
  4. リクエスト メモリ プールは解放されますが、ファイルの読み取り、キャッシュの待機、またはスレッド タスクのコールバックはそのメモリ プールへの参照を保持したままになります。
  5. 後続の非同期完了コールバックは解放されたメモリにアクセスし、その結果、UAF、Worker がクラッシュしたり、メモリが破損する可能性があります。

公式修正では、リクエスト ヘッダー ファイルに NGX_HTTP_MAX_BLOCKED 250 が追加され、出力フィルター、キャッシュ読み取り、およびアップストリーム スレッド パスに制限が追加されます。しきい値に達すると、同期されたパスを使用した操作は同期的に完了し、安全に処理できない場合は、保留中のタスクのそれ以上の追加は拒否されます。 S7

該当性判断：以下のことを評価する必要がある。 SSI , AIO 、仮想インクルージョン、サブリクエスト、および関連する非同期操作は、同じリクエスト チェーン内で組み合わせて発生する可能性があります。これらは通常、デフォルトのプレーンな静的プロキシ構成ではありません。 aio off; または ssi off; 特定のトリガー要素を削除できますが、最初にビジネス関数の依存関係を確認する必要があります。 S4 S7 S25

2.5 CVE-2026-95101: HTTP/3 不明なフレームが DATA リクエストボディのステータスと混同されています

HTTP/3 フレーム パーサーは、DATA フレーム (HTTP リクエスト本文の処理に渡す必要がある) とスキップすべき不明なフレームを区別する必要があります。ネットワーク バッファ間でフラグメント化する場合は、不明なフレームの長さも正確に保持する必要があります。

ngx_http_v3_parse_data() の古い実装では、未知のフレームをスキップするときに st->length フィールドを使用して「スキップされる残りのバイト数」を保存していましたが、リクエスト本文フィルターは同じフィールドを「残りの DATA ペイロード長」として解釈していました。未知のフレームが複数の解析呼び出しにまたがる場合、解析が中断された後の次のバイトのバッチがリクエスト本文の一部と誤って認識される可能性があります。 S8

次の 2 種類のリスクが発生します。

  • リクエストボディの挿入: クライアントによって送信された非 DATA フレーム ペイロードが上流のアプリケーションに送信され、バックエンドによって実際に受信されたデータが変更される可能性があります。
  • サイズ制限は client_max_body_size およびその他の制限を回避します。予期されるチェックは DATA パスに集中しており、誤って変換されたコンテンツは対応する検証をバイパスする可能性があります。

公式が説明する典型的なトリガーシナリオは次のような場合です。 ngx_http_v3_module 受け取る HTTP/3 リクエストと転送 proxy_request_buffering on 。プロキシ リクエスト本文のバッファリングはデフォルトで有効になっています。 ngx_http_proxy_module 。したがって、オンになるリバース プロキシは、 HTTP/3 最初にチェックする必要があります。という理由だけでトリガー条件がないと仮定するのは適切ではありません。 proxy_request_buffering on; 明示的には書かれていない。 S8 S18

この脆弱性の直接的な影響は、バックエンド リクエストの整合性とセキュリティ境界の変更に属します。これは、NGINX コアで直接完了する RCE と同等の表現ではありません。最終的なビジネスへの影響は、これらのバイトが上流でどのように解析され、信頼されるかによって決まります。 S24

2.6 CVE-2026-97629: TLS チケットのローテーションで 3 番目のキー スロットが見つかりません

影響を受ける構成では、NGINX は共有メモリ キャッシュを通じて TLS セッション チケット キーを自動的に生成およびローテーションできるため、複数の Worker が同じバッチのチケットを処理できるようになります。

関連する同期ロジックは、Worker ごとに 3 つのキー スロットを割り当て、復号化コールバックもこれらのスロットを通過します。しかし、古い実装では毎回共有メモリから 2 つのキー スロットのみがコピーされるため、キー名、HMAC キー、および 3 番目のスロットの AES が作成されます。キーは初期化されていないままになる可能性があります。チケットのキー識別子がこのステータスと一致する場合、初期化されていないキー素材が署名の検証と復号化に使用され、TLS セッションを偽造するパスが形成される可能性があります。 S9

リスクの高い導入の組み合わせは通常次のとおりです。

# 仅为排查触发条件所示：共享缓存本身不是恶意配置
ssl_session_cache shared:SSL:10m;
# 未显式配置 ssl_session_ticket_key 文件，使用自动轮换机制

この脆弱性による最も深刻なビジネス上の影響は、クライアント証明書認証 ( mTLS ） で ssl_verify_client on; などの方法で、偽造された回復セッションがクライアント証明書の検証をバイパスする可能性があります。攻撃が成功するかどうかは制御不能な条件にも左右されます。通常のサーバー側 HTTPS 証明書のみを使用し、クライアント証明書による認証を使用しないサイトは、「攻撃者が Web サイトのログイン全体をバイパスできる」という誤った特徴付けをされるべきではありません。 S9 S12

これは、TLS セッション認証ステータスの問題であり、サーバーの TLS 秘密キーがクラックされるかどうか、またはパブリック CA root 証明書が影響を受けるかどうかとは関係がありません。 S24

2.7 DoS、RCE、認証バイパス、および既知のエクスプロイトを理解する方法

  • DoS: メモリ エラーにより、Worker がクラッシュするか、大幅に再起動します。全体的な可用性の低下を引き起こすかどうかは、トラフィックの圧力、プロセスの再起動能力、接続の維持時間、および高可用性アーキテクチャに関連しています。
  • 潜在的な RCE: 一部の発表では、ASLR が閉じられるかバイパスされるとコードが実行される可能性があることが示されています。これは、コマンドを安定かつ普遍的に実行できる公開攻撃チェーンが公開されたことを意味するものではありません。 S4
  • リクエストインジェクション・認証バイパス：保護されている業務ステータスやリクエスト内容を直接変更する可能性があり、シェルを直接取得しないからといって無視することはできません。
  • 攻撃の試みを発見しました。2026 年 5 月の CVE-2026-42945 では、実際の悪用活動が報告されています。この歴史的事実が、10 月の 5 つの CVE すべてが大規模な悪用に成功したことを意味すると直接推測すべきではありません。 S23

3. 修復バージョンとパッチの選択

3.1 NGINX Open Source 公式パッチ ベースライン

上流支店10月に5つの脆弱性をカバーする最初の正式版をリリース2026-10-27 時点の推奨事項
Stable 1.30.x1.30.6（2026-10-14）少なくとも 1.30.6 をインストールし、後続のセキュリティ バージョンをフォローアップしてください。
Mainline 1.31.x1.31.7（2026-10-14）1.31.8（2026-10-21）
以前の NGINX Open Source ブランチ「古い脆弱性パッチが適用されている」だけでは判断できませんまず、保守されているブランチに移行します。それ以外の場合、ベンダーは CVE-by-CVE ベースの裏付けの正式な証拠を提供する必要があります。

これらは、バージョンの結論です。 nginx.org アップストリームのソース コード/公式ブランチを使用する必要があり、ディストリビューション ベンダーが提供するバックポートされた修正を含むセキュリティ パッケージを直接拒否するために使用しないでください。たとえ 1.31.6 より大きい 1.30.6 ですが、メインライン ブランチのパッチ ベースラインよりもまだ低いです。 S1 S2

3.2 5 つの CVE の上流影響範囲

次の範囲は、nginx.org セキュリティ情報の原文に従ってリストされており、「現在実行中のブランチ」および「実際の構成パス」と併せて理解する必要があります。

CVE上流タグが影響を受けるバージョン公式にラベル付けされた修正バージョン
CVE-2026-151760.1.29–1.31.61.30.6+ または 1.31.7+、それぞれのブランチ内
CVE-2026-934791.30.0–1.30.5，1.31.2–1.31.6同上
CVE-2026-972050.8.11–1.31.6同上
CVE-2026-951011.25.0–1.31.6同上
CVE-2026-976291.23.2–1.31.6同上

CVE-2026-93479 には、特定の導入バージョン制限があります。すべての古い NGINX バージョンがこの回帰の影響を受けるわけではありません。これらの範囲外の古いバージョンでも、以前の map 正規表現の脆弱性 CVE-2026-42533 の影響を受ける可能性があります。 S1

3.3 Ubuntu: ディストリビューション バックポート (USN-8955-1)

Canonical USN-8955-1 2026 年 10 月 26 日は、4 つの Ubuntu ビルドのセキュリティ アップデートを提供します: S13

Ubuntu バージョンnginx と同じソース パッケージの修正バージョン説明
22.04 LTS1.18.0-6ubuntu14.22これはベンダーのバックポートです。アップストリームのバージョン番号は依然として 1.18.0 と表示されます
24.04 LTS1.24.0-2ubuntu7.19同上
26.04 LTS1.28.3-2ubuntu1.12同上
26.101.30.4-7ubuntu1.1同上

この発表には、nginx-core、nginx-extras、nginx-full、nginx-light などの同種パッケージの対応する修正バージョンが含まれています。 nginx -v で示される上流部分だけから修正するかどうかの結論を出さないでください。 Ubuntu 24.04 や 1.24.0-2ubuntu7.19 などはこのベンダーによってパッチが適用されていますが、どのソースからの 1.24.0 も本質的に安全というわけではありません。

Ubuntu は、CVE-2026-95101 は Ubuntu 26.04 / 26.10 にのみ影響し、CVE-2026-97629 は Ubuntu 24.04 / 26.04 にのみ影響することも公式に明確にマークされています。 /26.10. ここでは、Ubuntu 独自のパッケージングと機能範囲を示します。これは、他のディストリビューションに直接プロモートすることはできません。 S13

3.4 Debian: バージョン間の違いは個別に確認する必要があります

Debian アドバイザリー DSA-6575-1 (2026-10-21) は、これら 5 つの CVE をカバーし、Debian 13 / trixie の修正された nginx パッケージを次のように識別します。

1.26.3-3+deb13u10

ただし、このレポートの検証時点では、Debian 12 / bookworm の 1.22.1-9+deb12u10 は、依然として Debian Security Tracker によって脆弱であるとフラグが立てられています。したがって:

  • Debian 13 DSA-6575-1 に従って更新して受け入れるだけです。
  • Debian 12 は、現在の Security Tracker または ELTS ベンダーによって提供されるセキュリティ修正を 1 つずつ確認する必要があります。発表で修正が確認される前に、apt upgrade の成功に基づいて 5 つの項目すべてが修正されたと宣言しないでください。
  • Debian ソース パッケージには、nginx.org バージョン番号とは関係なくパッチ セットが含まれる場合があります。カスタム ビルドの場合は、完全なソース コード パッケージの修正セットを確認する必要があります。単一のアップストリーム コミットをコピーするだけで、それが完了したとみなすことはできません。

上記の区別は、DSA および CVE 追跡記録に基づいています。 S14 S15 S16

3.5 NGINX Plus、njs および Ingress コントローラー

製品/コンポーネントセキュリティの選択と検証の重要なポイント
NGINX Plus（商用版）F5 に対応する Plus ブランチの発表とアップグレード手順を参照してください。検証時の最新の CR は PLS.37.2.0.1 で、LTS のセキュリティ ビルドは PLS.37.0.7.1 です。 Plus バージョンと付属のバックポートは、オープンソースの 1.30/1.31 しきい値で直接置き換えることはできません。 S19
njs / ngx_http_js_module2026-10-14 は njs 1.0.2 をリリースし、CVE-2026-101019 と CVE-2026-101025 を修正します。 njs を使用している場合は、モジュールと NGINX の互換性も確認する必要があります。 S20
F5 NGINX イングレス コントローラー/ゲートウェイ ファブリックNGINX コアは、関連はしていますが、独立したソフトウェア配布チェーンです。それぞれのコントローラー、イメージ、リリース ノートを使用して、関連する脆弱性を修正します。ポッド内の NGINX バイナリを単に置き換えることはできません。
Kubernetes コミュニティ kubernetes/ingress-nginxこのプロジェクトは 2026 年 3 月に廃止され、新たなセキュリティ メンテナンスは提供されなくなります。リリース番号を F5 NGINX Ingress コントローラーと間違えるのではなく、メンテナンス済みのコントローラーまたは Gateway API への移行を計画する必要があります。 S21

3.6 実際にどのパッチを選択すればよいですか?

導入形態推奨される実践方法修理証明書
nginx.org 公式 DEB/RPM パッケージ上流ブランチの修正バージョンにアップグレードするnginx -v/-V、パッケージ ソース、公式セキュリティ発表
Ubuntu/Debian 公式リポジトリベンダーのセキュリティ パッケージをインストールするフルパッケージバージョン + ベンダー USN/DSA + CVE ステータス
RHEL/Alma/Rocky/SUSE/その他のディストリビューション特定のディストリビューションのセキュリティ情報とパッケージのバージョンに従ってアップグレードする対応ベンダーCSAF/アナウンス、Ubuntu/Debianバージョンは適用不可
公式またはカスタムのコンテナイメージ検証済みの修復イメージを再構築またはプルし、ローリング ベースで置き換えます。イメージ ダイジェスト、ビルド SBOM、実行中のポッド/コンテナ イメージ ID
セルフコンパイルされた NGINX、OpenResty、Tengine、またはサードパーティ モジュールでパッチが適用されたバージョンメンテナの完全なセキュリティ バージョンの使用を優先します。必要に応じて、ターゲット ソース ツリーのレビュー済みパッチ バックポートを実行します。5 つの脆弱性修正、ABI/モジュールの互換性、ユニットとビジネスの回帰

OpenResty と Tengine は異なるリリース システムです。この表では検証方法のみを説明します。これは、そのすべてのバージョンが標準の NGINX と同時に影響を受けることを意味するものではなく、アップストリーム コード パッチが無条件に適用されることもありません。

4. 正式な修理プロセス

4.1 外部トラフィックを受信する実際のインスタンスのインベントリ

少なくとも各エントリを照合します。

  • ドメイン名、負荷分散/CDN/エッジ プロキシ リンク、オリジン サイトの公開方法、および使用されるネットワーク プロトコル。
  • NGINX 製品 (オープン ソース、Plus、Ingress など)、フル バージョン、パッケージ リポジトリ ソース、イメージ ダイジェスト。
  • nginx -V は、構築モジュールとコンパイル パラメータを表示します。 njs、Lua、OpenResty、およびサードパーティの動的モジュールがあるかどうか。
  • 実際に実行されている master/worker PID、サービス ユニット/コンテナ/ポッド、レプリカ、および Worker ノード。
  • 実際に有効な http/stream、server、location、include 構成。
  • HTTP/3、mTLS、SSI/AIO、動的ログ パス、複雑な map、および正規表現キャプチャを有効にするかどうか。

デフォルトの /etc/nginx/nginx.conf だけをチェックしないでください。実稼働環境では、多くの場合、複数のサイト、TLS、および include を介したモジュール構成がロードされます。複数の NGINX インストール パスまたは複数のプロキシ レイヤーが存在する場合もあります。

4.2 バージョンとコンパイル情報を確認する

# NGINX 版本及构建选项
nginx -v
nginx -V 2>&1

# Linux：查看实际运行的 NGINX 进程
ps -eo pid,ppid,user,comm,args | grep '[n]ginx'

# Debian / Ubuntu：查看完整已安装包版本、来源
apt-cache policy nginx
# 兼顾 nginx-core / nginx-full / nginx-extras 等实际已安装包
dpkg-query -W 'nginx*' 2>/dev/null

# RPM 系：以实际安装包及仓库公告为准
rpm -qa | grep '^nginx'

nginx -V は、コマンドライン パスで見つかったバイナリのビルドを報告します。実行中の worker がそれをロードしたことを証明するものではありません。 nginx -v ではディストリビューションの完全なパッケージ サフィックスが省略されている場合があるため、パッケージ マネージャーまたはサプライ チェーン レコードも確認してください。

4.3 有効な構成をエクスポートし、静的スクリーニングの最初のラウンドを実行します。

nginx -T は構成をテストし、マージされた構成をダンプします。出力には、認証資格情報、キー パス、内部ホスト名などの機密情報が含まれる場合があります。制御対象の端末を root 権限とプライベート ファイル 権限で保存し、元のファイルを公開作業指示書に投稿しないことをお勧めします。

sudo sh -c 'umask 077; nginx -T > /root/nginx-effective.conf 2> /root/nginx-config-check.log'

sudo grep -nE \
  'alias|rewrite|map[[:space:]]|request_filename|aio[[:space:]]|ssi[[:space:]]|quic|http3|proxy_request_buffering|ssl_session_cache|ssl_session_ticket_key|ssl_session_tickets|ssl_verify_client|log_format|root[[:space:]]' \
  /root/nginx-effective.conf

これは単なる候補パス ロケーターであり、信頼できる CVE 自動決定ツールではありません。

  1. grep は、変数が同じ location にあるのか、同じリクエスト評価チェーンにあるのかを判断できません。また、構成の継承関係を推測することもできません。
  2. proxy_request_buffering on、一部のキャッシュおよびチケット構成にはデフォルト値があり、対応する指示を書かなくてもリスクがなくなるわけではありません。
  3. リバース プロキシ、CDN、コンテナ サイドカー、またはコントローラによって生成された構成は、手動で検査したファイルとは異なる場合があります。
  4. NGINX Plus および動的モジュールの特性は、それぞれの公式管理ツールを使用して確認する必要がある場合があります。

4.4 信頼できるチャネルを通じて修正を展開する

Debian/Ubuntu (公式配布リポジトリ):

sudo apt-get update
apt-cache policy nginx

# 升级发行版仓库中已经安装的 NGINX 及相关包；
# 先确认 Candidate 属于修复版本，再执行升级。
sudo apt-get install --only-upgrade nginx

# 对实际安装的 nginx-core / nginx-full / nginx-extras 等包
# 确认它们的版本和依赖一同达到厂商修复要求。
dpkg-query -W 'nginx*' 2>/dev/null

この一連のコマンドは、まだ利用可能になっていないセキュリティ修正を何もないところから生成することはできません。特に Debian 12、アップグレードされたパッケージがセキュリティ追跡システムによってまだ脆弱であるとみなされる場合、追加のベンダーの修復、隔離、または移行の対策が必要です。 S13 S14 S15

nginx.org 公式パッケージ:

# 先确认仓库来自 nginx.org、目标分支和候选版本
apt-cache policy nginx
# 经变更审批后再执行对应仓库的升级命令
sudo apt-get install --only-upgrade nginx

セルフコンパイルの OpenResty、Tengine、または NGINX Plus を使用する場合は、対応するメンテナがサポートする修正バージョンを使用し、nginx.org、ディストリビューション、およびサードパーティのリポジトリ パッケージを混合しないでください。元のバイナリ/イメージ、構成、署名、およびロールバック展開マニフェストは保存する必要があります。

Containers/Kubernetes: 不変イメージを更新し、そのダイジェストを記録し、すべての古いレプリカを段階的ロールアウトで置き換えます。 kubectl rollout status は、デプロイメント コントローラーが終了したことのみを確認します。また、イメージ ダイジェスト、イングレス ルーティング、異常なレプリカも検証します。

4.5 構成を確認し、古い Worker を置き換えます

sudo nginx -t
# 按服务实际名称、主机高可用和变更窗口执行重启
sudo systemctl restart nginx
sudo systemctl status nginx --no-pager

# 核查真正存在的 master / worker
ps -eo pid,ppid,user,comm,args | grep '[n]ginx'

nginx -s reload を新しいバイナリが実行されている証拠として扱わないでください。通常の構成のリロードにより、古い master は実行可能ファイルを置き換えることなく新しいワーカーを開始できます。 NGINX は専用のオンライン バイナリ アップグレード手順をサポートしていますが、追加の手順と検証が必要です。確立された手順がなければ、高可用性トラフィック スイッチを使用してからサービスを再起動するか、代替コンテナを展開します。 S22

systemd ソケット、コンテナ エントリ スクリプト、または複数のインストールを介して NGINX を管理する場合は、systemctl restart nginx がすべてのインスタンスをカバーすると直接想定するのではなく、実際の起動ターゲットとプロセス パスを確認する必要があります。

4.6 実際の外部入口からのビジネス回帰を受け入れて実行する

少なくとも以下を実行することをお勧めします。

  • 通常の HTTPS、書き換えられたルート、静的リソース、および alias マッピング ページは正しいですか。
  • 通常の map ディストリビューション、変数 root パス、アクセス ログ パス、SNI/証明書ルーティング、および Stream プロキシは正しいですか。
  • 通常のアップロード、チャンク アップロード、API リクエスト、および HTTP/3 のアップストリーム ボリューム制限 (有効な場合) は期待どおりですか。
  • mTLS: 正当な証明書リクエストは成功するはずです。見つからない証明書、期限切れの証明書、または未承認の証明書は引き続き拒否される必要があり、TLS の再開/再接続で誤って権限が変更されるべきではありません。
  • SSI ページと非同期ファイル アクセスが正常かどうか。エラー ログには、異常なメモリ参照要求や Worker クラッシュの繰り返しは示されていません。
  • トラフィックの切り替え後、古いバージョンのプロセスと古いイメージのレプリカが終了しているはずです。

テストは独自の環境または許可された環境で実施する必要があります。通常のリクエスト スモーク テストだけでは、メモリの脆弱性が修正されたことを証明できません。最終的には、サプライヤーの修正バージョン、ソース コード パッチ、およびランタイム テストが共同で承認される必要があります。

5. すぐにアップグレードできない場合の緩和策

このセクションはリスク軽減オプションであり、パッチの置き換えではありません。すべての一時的な構成変更はバックアップして実行する必要があります nginx -t 、バッチでリリースされ、必要に応じてすぐにロールバックされます。 S3 S4

5.1 外部エクスポージャに基づいてトラフィックの優先順位を制御

時間内にアップグレードできないサービスの攻撃対象領域を減らすことを優先します: 管理面および内部 API 信頼できるソース アクセス制御、上流のネットワーク分離、または短期間のオフラインを追加します。高リスクの入口に接続、リクエスト本文、およびレート制限を追加します。リクエスト処理チェーンの前に、エントリ関連の NGINX でソース認証が行われるようにします。ほとんどの脆弱性自体はデータ プレーン内の NGINX にあることに注意してください。従来の WAF ルールではカスタム構成のトリガー条件が正確に決定されない可能性があります。

5.2 alias / rewrite: 書き換え後の $request_filename の評価を回避します

以下を確認して調整することをお勧めします。

  • alias を使用して、location と同時に URI を変更する rewrite を実行しないようにしてください。
  • URI を書き換えても正しい位置合わせが完了していない場合は、$request_filename の使用を避けてください。
  • return、set、if、add_header、アクセス ログ形式、およびインクルード ファイルでの間接変数参照を確認します。
  • ビジネスが許可する場合は、クリア root/try_files/独立した location を使用しますが、alias を root に変更するだけです。また、ファイル パスのセマンティクスも変更される可能性があるため、1 つずつ確認する必要があります。

インターネット上の一般的な「安全な書き換えテンプレート」を直接コピーして、既存の構成を上書きしないでください。 location プレフィックスと書き換えターゲットが異なると、まったく異なる意味でパス スプライシングが行われます。 S5

5.3 map/正規表現: キャプチャ変数の状態の混合を削減します。

$1 などの匿名キャプチャを時間の経過とともにさまざまな正規表現評価パス間で再利用できるようにするのではなく、名前付きキャプチャを優先し、その伝播範囲を制限することをお勧めします。たとえば:

# 演示具名捕获的结构，实际变量名和匹配表达式须按业务调整
map $host $tenant_root {
    default /srv/www/default;
    ~^(?<tenant>[a-z0-9-]+)\.example\.net$ /srv/www/$tenant;
}

このスニペットは、監査しやすい変数の所有権の構造を示しているだけです。すべてを独立して排除することが証明されたという意味ではありません CVE-2026-93479 へのパスをトリガーします。特に、キャプチャ変数が他の変数によって事前に参照されているかどうかを確認します。 root または log_format 、があるかどうか volatile 、動的パス、および相互依存する評価チェーン。 F5 /CERT は、短期的な救済策として、名前付きキャプチャを使用し、対応する通常の一致構成に使用範囲を制限することをお勧めします。 S3 S6

5.4 AIO + SSI: 不要な機能の組み合わせをシャットダウンします。

SSI または非同期ファイル I/O を必要としないサーバー/パスの場合は、次を使用します。

# 在适当的 http/server/location 上下文中配置
ssi off;
aio off;

脆弱性を引き起こす条件の観点から見ると、通常、説明されている特定のチェーンを削除するには、2 つのうちの 1 つを閉じるだけで十分です。同時に終了することは、ビジネスがこの機能に依存しないシナリオにのみ適用されます。 include virtual、サブリクエスト、キャッシュ、およびスレッド プールの動作を確認します。リバース プロキシの負荷が高い場合、AIO をシャットダウンすると、遅延と I/O パフォーマンスが変化する可能性があります。 S7

5.5 HTTP/3 ボディ注入リクエスト: 必要に応じて入口を一時的に閉鎖します

HTTP/3 に関連する quic リスナーを無効にし、HTTP/3 を通知する Alt-Svc 応答ヘッダーをキャンセルし、エッジ レイヤー/ロード バランサーが依然として QUIC リクエストを修復されていない NGINX に直接送信しているかどうかを確認します。

# 示意：保留 HTTPS/TCP；暂时移除此前的 QUIC/UDP listen
server {
    listen 443 ssl;  # 保留 HTTPS/TCP 入口
    # 对支持新版语法的构建，可在此使用 http2 on;
    # 删除原有的 listen 443 quic reuseport;
    # 删除原有的 add_header Alt-Svc ...;（仅限宣传 h3 的那项）
    # 其余证书、server_name、location 等配置保持不变
}

上記は変更の違いの単なる説明であり、個別に有効にできる完全なサーバー構成ではありません。 HTTP/2 の設定構文は、NGINX バージョンに関連しています。 HTTP/2 を保持する必要がある場合は、http2 on; または対応するバージョンに応じた既存の有効な構文を使用し、nginx -t で確認する必要があります。セクション全体をこのセクションで置き換えるのではなく、展開前に既存のサーバー構成とマージする必要があります。また、UDP 443 ファイアウォール、HTTP/3 終端位置、および CDN/フロント プロキシのクライアント フォールバック パスもチェックします。

別の種類の短期緩和策は、 proxy_request_buffering off; 影響を受けるプロキシ パス上ですが、これにより、上流のリクエスト本文のストリーミング、失敗した再試行、および一部のアップロード ワークフローの動作が変わります。ディレクティブが影響を受けることを十分にテストし確認した後にのみ使用してください。 HTTP/3 プロキシパス。 S8 S18

5.6 TLS セッションチケット: 優先保護 mTLS 認証境界

アップグレードが不可能で、インスタンスが共有セッション キャッシュ + チケット キーの自動ローテーションに依存している場合は、次を評価します。

# 在 nginx http/server 适当作用域进行配置
ssl_session_tickets off;

これにより、 TLS セッション チケット メカニズム。これにより、この脆弱性で説明されているチケット偽造パスが削除されます。ただし、セッション再開のパフォーマンスに影響する可能性があります。単にオフにすることはできません mTLS 「脆弱性を回避」するためにクライアント証明書を検証します。これにより、元の認証境界が直接削除されます。 S9 S12

明示的な ssl_session_ticket_key ファイルと安全なローテーションは、プロの TLS 管理プロセスによって自動生成された条件を回避するために使用することもできますが、キーの保管、完全なノードの配布、ローテーション、および古いチケットのライフサイクルはすべて慎重に監査する必要があります。一時的な緊急事態に備えて、通常の Web 構成やスクリプトに長期的に再利用可能なキーをハードコーディングすることはお勧めできません。 mTLS を使用する重要なサービスは、TLS セッション再開動作と有効なクライアント証明書のないリクエストの拒否についても監視する必要があります。 S12

5.7 オペレーティング システムと国境警備の役割

# Linux：常见值 2 表示进程地址空间随机化处于完整启用状态
sysctl kernel.randomize_va_space

ASLR、非 root ワーカー、読み取り専用コンテナ ファイル システム、最小限のファイル アクセス許可、およびネットワーク分離により、潜在的な RCE の影響を軽減できます。 ASLR はヒープ オーバーフローや UAF を修正せず、ワーカーがクラッシュしないことを保証できません。 WAF、レート制限とリクエスト本文のサイズ制限は、TLS チケット キーの同期を修正しません。 S4

5.8 よくある誤解: これらの操作では修復を完了するのに十分ではありません

共通操作なぜ不十分なのでしょうか?
「nginx -v は比較的新しいようです」所属するブランチ、リリース バージョンの完全なバックポート パッケージ バージョン、およびオンライン プロセスはチェックされません。
「イントラネットの 1 つだけがアップグレードされました」古い Worker/古いコンテナ/古い CDN オリジン インスタンスは引き続きリクエストを受信します
「サイトでは PHP/動的タグが使用されていません」この欠陥は、NGINX コア パスまたはプロトコル解析で発生し、PHP の実行には依存しません。
「WAF/Cloudflareを開くだけで十分です」WAF が、すべての NGINX 構成に依存するメモリの欠陥または TLS の再開の欠陥をブロックすることは証明されていません。
「すでにASLRをオープンしました」難易度の緩和を利用しているだけです。リクエスト注入による DoS は引き続き可能です
「HTTP/3 はパブリック ネットワークに公開されていないため、アップグレードする必要はまったくありません。」他の 4 つの CVE は依然として独立した評価が必要です。そして隠された起源との直接的なつながりがあるかもしれない
「7 月の map 脆弱性は修正されました」10 月 CVE-2026-93479 には、その後のスクリプト評価の回帰問題が含まれます
「キャッシュを無効にするとすべての問題が解決します」一部の TLS キャッシュまたは AIO シナリオにのみ影響し、エイリアス、スクリプト、HTTP/3 は対象外

6. 公式パッチ導入の考え方と検討ポイント

このセクションは、2026 年 10 月のアップストリームに続きます NGINX 修正します。スニペットは、パッチレビュー用の代表的な変更を示しています。これらは完全ではなく、独立してコンパイル可能な修正です。カスタム ビルドの場合は、完全なコミット、周囲のコードとテストを確認し、完全にサポートされているリリースを優先してください。 S5 S6 S7 S8 S9

6.1 CVE-2026-15176: URI は、alias パス マッピングの拒否条件を含めるように書き直されました。

アップストリーム コミットは、src/http/ngx_http_core_module.c の ngx_http_map_uri_to_path() を変更しました。

- if (alias && !r->valid_location) {
+ if (alias && (!r->valid_location || r->uri_changed)) {

レビューの焦点: URI が変更されたが、alias の対応する場所のセマンティクスが信頼できなくなった場合、ファイル システム パスの計算を続行することはできません。これは、事前状態制約の機能強化です。リクエスト URI に不正な文字が含まれているかどうかは、単純なチェックではありません。 S5

6.2 CVE-2026-93479: 出力データ長と予約長を正しく区別します。

アップストリーム コミットは、src/http/ngx_http_script.c と src/stream/ngx_stream_script.c を同時に更新します。中心となる意図は次のように要約できます。

- n = len;
+ n = 0;
  /* ...计算实际脚本输出长度... */
- value->len = n;
- value->data = ngx_pnalloc(pool, n);
+ value->len = n + len;
+ value->data = ngx_pnalloc(pool, n + len);

ここで、pool はパラメータ名を説明するためのものであり、実際の HTTP と Stream の割り当て式は異なります。この変更により、最初にスクリプトの出力長が計算され、次に予約された長さが最終的な割り当てに追加されるため、出力によって予約された領域が上書きされなくなります。 S6

監査およびバックポートを行う場合、HTTP/Stream の対応するエバリュエーターもカバーする必要があります。 map の構成構文ファイルをチェックするだけでは、欠陥が修正されたことを証明できません。

6.3 CVE-2026-97205: 8 ビット非同期操作カウントの安全しきい値を設定

アップストリームは src/http/ngx_http_request.h に追加されました:

#define NGX_HTTP_MAX_BLOCKED 250

また、非同期ファイル読み取り、キャッシュ待機、出力フィルタリング、スレッド操作にも同様のエントリを追加します。

if (r->main->blocked >= NGX_HTTP_MAX_BLOCKED) {
    /* 使用同步路径，或者拒绝新的异步操作 */
}

レビューの焦点: r->main->blocked を追加するすべての実際のコード パスをカバーする必要があります。しきい値定数を単にヘッダー ファイルに書き込むことはできません。また、バックポートは、タスクの直接の拒否によってデッドロックや参照漏洩が発生しないように、同期フォールバック、非同期コールバック、およびエラーリターンの完全な調整をチェックする必要があります。 S7

6.4 CVE-2026-95101: 未知のフレームに対して個別に skip ステータスを維持します

アップストリームは、HTTP/3 パーサー ステータス構造に skip フィールドを追加し、ステータス分離を実行します。

if (st->type != NGX_HTTP_V3_FRAME_DATA && st->length > 0) {
    st->skip = st->length;
    st->length = 0;
    st->state = sw_skip;
}
/* ... */
rc = ngx_http_v3_parse_skip(b, &st->skip);

重要なのは、「不明な HTTP/3 フレームを無効にする」ことではなく、複数の読み取りにわたって、スキップされたバイト数と DATA ペイロード長が常に独立した状態によって管理されるようにすることです。レビューでは、未知のフレームのクロスバッファーシャーディングと、client_max_body_size の最終的な整合性に焦点を当てる必要があります。 S8

6.5 CVE-2026-97629: 完全な TLS キー スロット アレイを同期します

アップストリームの変更は src/event/ngx_event_openssl.c にあります。

  ngx_memcpy(keys->elts, cache->ticket_keys,
-            2 * sizeof(ngx_ssl_ticket_key_t));
+            keys->nelts * sizeof(ngx_ssl_ticket_key_t));

元のイメージには 3 つのキー スロットが含まれていましたが、最初の 2 つだけがコピーされました。代わりに、配列要素の実際の数に基づいて同期し、Worker の投票キー セットが共有メモリと一致していることを確認します。レビューするときは、memcpy の長さの変更を一度だけ確認するのではなく、配列の割り当て、初期化、共有ロック、および回転ロジックが一貫していることも確認してください。 S9

6.6 分散したパッチの断片のみを適用することが推奨されないのはなぜですか?

これら 5 つの変更はそれぞれ src/http、src/stream、src/http/v3、src/event に及び、古いバージョンにはセキュリティ バックポートや非公式拡張機能が含まれている可能性があります。バックポートでは、次のチェック マトリックスを形成する必要があります。

チェックオブジェクト確認しなければならないこと
パッチソース正式な提出、ターゲット バージョンの一致、完全なパッチと署名の検証
オリジナルパッチセットCVE-2026-42533、ディストリビューション バックポートなどの過去の変更と競合しません。
コードパスHTTP + Stream スクリプト、AIO/スレッド、HTTP/3、OpenSSL チケットがすべてカバーされます
コンパイル済み互換性OpenSSL、PCRE、モジュール ABI、動的モジュール、およびリンクの依存関係は一貫しています
機能的回帰alias 書き換え、動的ログ、SSI/AIO、HTTP/3 アップロード、mTLS セッション再開
ランタイムすべての Worker/Pod は新しい検証済みビルドを実行し、レガシー イメージは残りません

独自のリリースを保守するチームの場合、各 CVE の監査可能なパッチ ID、パッケージ バージョン、ビルド ログ、および回帰レポートを保持することをお勧めします。通常の運用とメンテナンスの場合、最も安全な解決策は、ベンダーの完全なセキュリティ アップデートをインストールすることです。

7. 過去の脆弱性の遡及、古いブランチおよびその他の製品

7.1 NGINX 2026 年 5 月から 9 月に同時確認に値するコア脆弱性

長期間更新されていない多くの NGINX インスタンスは、10 月の新しい問題の影響を受けるだけではありません。近い将来の代表的な修復ノードは次のとおりです: S1S2

CVE最初の修正リリース監査が必要な主なリスクと状況
CVE-2026-42945Stable 1.30.1 / Mainline 1.31.0、5 月 13 日rewrite 匿名の正規表現キャプチャおよび置換ロジックによりヒープ オーバーフローが発生し、潜在的な RCE。野外攻撃の試みに関する公的報告があります
CVE-2026-9256Stable 1.30.2 / Mainline 1.31.1、5 月 22 日rewrite で正規表現のキャプチャと長さの推定が重複するとオーバーフローが発生する
CVE-2026-42055Stable 1.30.3 / Mainline 1.31.2、6 月 17 日HTTP/2 アップストリームまたは gRPC への特定の構成、大きなリクエスト ヘッダー条件によりバッファ オーバーフローがトリガーされる
CVE-2026-42530Mainline 1.31.2、6 月 17 日HTTP/3 解放後使用。公式マーク影響範囲 1.31.0–1.31.1
CVE-2026-42533Stable 1.30.4 / Mainline 1.31.3、7 月 15 日map + 正規表現キャプチャ変数の評価によりヒープ オーバーフローが発生し、後続のパッチには 10 月の CVE-2026-93479 と回帰相関があります
CVE-2026-60005Stable 1.30.4 / Mainline 1.31.3、7 月 15 日ngx_http_slice_module 特定の変数およびキャッシュ更新条件下でメモリ内容がリークする
CVE-2026-56434Stable 1.30.4 / Mainline 1.31.3、7 月 15 日SSI は UAF に関連しています。 root の原因は 10 月の AIO カウント脆弱性とは異なります
CVE-2026-90439Stable 1.30.5 / Mainline 1.31.6、9 月 15 日HTTP/3 + 特定の OpenSSL バージョンの組み合わせの限定的なヒープ オーバーフロー。主にクラッシュ/限定的なメモリ破損として現れます。

2026 年に発表された NGINX コア、HTTP/2、文字セット、SMTP などの他の脆弱性も、公式のセキュリティ情報に従って調査する必要があります。この表は、現在の NGINX の公開リバース プロキシ展開に最も関連しており、メモリの安全性やリクエストの整合性に影響を与える典型的なイベントに意図的に焦点を当てています。 2026 年のすべての CVE ではありません。リスト。 S1

CVE-2026-42945 に特に注意を払う理由

5 月には、この rewrite 脆弱性に対する実際の悪用活動と公開された悪用コード情報を記録する政府機関からのセキュリティ情報があります。したがって、5 月から現在まで長期間パッチが適用されておらず、複雑な正規表現の書き換えがパブリック ネットワーク上で公開されているインスタンスの場合は、修復の完了に加えて、Worker の異常なクラッシュ、そのときのアクセス ログ、および不審な変更を追加でレビューする必要があります。 S23

「攻撃の試みが発生した」ということは、攻撃者がすべてのターゲットに対して確実にコマンドを実行したことを自動的に証明するわけではありません。インシデント対応が関係する場合は、侵害の兆候とプロセスのクラッシュを、権限昇格や永続性の実際の証拠とは別に調査する必要があります。

7.2 古いバージョンとディストリビューション バックポートの修復

NGINX ブランチごとに独自のサポート サイクルと脆弱性の導入時期が異なります。 5 つの新しいパッチは、レビューなしにすべての初期ソース ツリーに展開することはできません。

シーン推奨される戦略
リリース版では完全なセキュリティパッチが発表されましたベンダー パッケージを使用し、完全なパッケージ バージョンを文書化します。互換性のない上流のベアバイナリとの置き換えを避ける
Debian 12 およびこのバッチのすべての CVE でまだカバーされていないその他の影響を受けるリリースリスク作業指示を提出し、外部暴露を制限し、サプライヤー/ELTS ステータスを確認します。必要に応じて、検証可能なメンテナンス リリース チェーンを移行または使用する
アップストリームサポートが終了した歴史的なブランチサポートされているバージョンへの移行を優先します。短期的なバックポートが必要な場合、メンテナは依存関係とパッチの互換性を評価し、完全なテストを作成します。
NGINX フォーク (OpenResty、Tengine、カスタマイズされたゲートウェイ) が付属まず、対応するコード パスが含まれているかどうかを確認してから、フォーク メンテナのセキュリティ ステートメントを使用します。アップストリーム バージョンと直接同等になることはできません。
セキュリティ パッチはビジネス機能の変更につながります段階的なロールアウト、バージョン間のトラフィック切り替え、構成の適応を採用します。パブリック ネットワークの未修正バージョンを分離せずに復元することは適切ではありません。

7.3 njs、Ingress、および NGINX コアの個別の修復

  • njs: NGINX メイン プログラムに加えて、NGINX JavaScript モジュール自体のバージョンも確認する必要があります。 njs 1.0.2 は、2026 年 10 月に発生した XML 解析のメモリ枯渇とエンティティ参照属性に関する XML 検証の不一致の問題を修正します。 nginx-saml を使用した XML 署名検証に関連する展開の場合は、プラグイン シナリオに関する公式の njs 手順をさらに読む必要があります。 S20
  • F5 NGINX Plus / NGINX イングレス コントローラー: さらに、コントローラーとゲートウェイ ファブリックにはそれぞれ追加のセキュリティ情報、異なるパッケージ バージョン、および固有のポリシーの脆弱性がある可能性があります。 1 つのレイヤーをアップグレードしても、別のレイヤーが自動的に更新されるわけではありません。 S19
  • Kubernetes コミュニティ ingress-nginx: Kubernetes 関係者は、コントローラーが 2026 年 3 月にメンテナンスを停止したことをすでに発表しており、その倉庫を F5 コントローラーと混同することはできません。影響を受ける企業は、新しいセキュリティ バージョンを待つのではなく、スムーズな移行を計画し、Ingress アノテーションと Gateway API セマンティクスの違いを検証する必要があります。 S21

8. 合否基準と事後検査

変更作業指示書の受け入れ条件として次のリストを使用することをお勧めします。

プロジェクト資格基準保存できる証拠
アセットとポータルの対象範囲CDN をバイパスできるすべての外部インスタンスと直接接続されたインスタンスがインベントリされています。ドメイン名、LB、IP、ポッド/コンテナリスト
パッケージのソースと修復範囲該当するすべての CVE をカバーすることが確認されたバージョンを使用するアップストリーム セキュリティ アドバイザリ、USN/DSA、パッケージ バージョン、イメージ ダイジェスト
古いプロセスが終了する古い master/worker/コンテナはすべて置き換えられましたPID/開始時刻、ローリング展開ステータス、実行イメージ
構成監査リスクの高い組み合わせは削除されるかパッチでカバーされ、継承関係が検証されています。nginx -T の編集された概要と監査記録
TLS/mTLS信頼できる証明書は合格します。無効な証明書または欠落している証明書は拒否されます。セッションの再開では認証がバイパスされませんネガティブ/ポジティブ認証テスト、管理された TLS テスト結果
HTTP/3 リクエストボディ有効パスが修正されました。アップストリームのリクエスト本文とスロットリングが正しく動作するHTTP/3、プロキシアップロード、ボリューム制限回帰テスト
SSI/AIO関数は要件を満たしており、Worker には異常終了はありませんビジネスの回帰、クラッシュ、エラー率の監視
運用保守監視明らかな例外はありません 5xx、SIGSEGV、プロセスが繰り返し終了します変更前後のサービス指標とログ
ロールバック戦略ロールバックが必要な場合は、まず露出を制限し、セキュリティ境界を維持します変更指示、緊急フロー、隔離計画
その後のライフサイクルセキュリティ情報のサブスクリプション、コンテナの更新頻度、ブランチの移行計画を決定する台帳、責任者、次回監査日をアップグレードします。

8.1 ログと実行ステータスで注目すべき点は何ですか?

長期間公開されていたサーバーの異常 ( worker process exited on signal 、 SIGSEGV )、リクエスト失敗のスパイク、異常なソース アクセス集約、予期しない TLS セッション再開/認証の成功、バックエンド リクエスト本文の異常な動作のトラブルシューティングを行います。これらの指標は調査の手がかりとしてのみ使用でき、特定の CVE が悪用されたことを直接証明するのに十分な証拠ではありません。 ; 関連するログがないからといって、攻撃がなかったことは証明されません。

8.2 推奨される最終的なリスク結論の文言

実稼働環境の受け入れレポートでは、次の正確な表現を使用する必要があります。

NGINX 外部サービス入口とソフトウェア パッケージ ソースが特定されました。該当するすべてのインスタンスがアップストリームの公式セキュリティ バージョンにアップグレードされているか、リリース ベンダーによって確認されたバックポートが完了している。古い Worker と古いコンテナは置き換えられました。エイリアス/リライト/マップ、AIO/SSI、HTTP/3 リクエスト本文、および TLS セッション チケット/mTLS 関連の構成は監査され、機能、認証、およびリクエストの整合性回帰テストに合格しています。アップグレードがまだ完了していないインスタンスの場合は、暴露エリア、補償措置、責任者、完了期限を追加で登録します。

Debian 12 または他のリリースのパッチがまだ不完全な場合、受け入れフォーム全体を「完了」と判断するのは適切ではありません。未解決の CVE、対応するトリガー構成の有無、分離ステータス、および最終的なアップグレード ルートを明確に記録する必要があります。

付録: 引用元とリンク

説明: 本文中の [Sx] 番号は、このセクションに一律に対応しています。以下では、上流のプロジェクトのセキュリティに関する発表、コードのコミット、サプライヤーのリリースの発表、および国家安全保障機関の情報が優先されます。引用された脆弱性の重大度は、各発行組織の評価基準に従って説明されています。データ検証日は 2026 年 10 月 27 日です。

S1 — NGINX Open Source 公式セキュリティ情報

アップストリームの影響を受けるバージョン、修正ブランチ、10 月の 5 つの CVE の公式重大度レベルが含まれており、2026 年までの歴史的な脆弱性もカバーしています。

S2 — NGINX 正式版リリース記録

2026-10-14 の 1.30.6 / 1.31.7、2026-10-21 の 1.31.8、および 5 月から 9 月までの重要なセキュリティ リリース マイルストーンを確認します。

S3 - シンガポールサイバーセキュリティ庁: F5 NGINX 3 つの重大な脆弱性

CVSS v4.0 9.2 スコア、必要な構成条件、および CVE-2026-15176、CVE-2026-93479、および CVE-2026-97205 の暫定的な軽減策の推奨事項の説明。

S4 - NHS イングランド: F5 NGINX 高リスク勧告

メモリの安全性の問題による DoS / 潜在的な RCE の影響、および ASLR のオフまたはバイパスなどの制約について説明します。

S5 — 公式ソースコミット: CVE-2026-15176

ngx_http_map_uri_to_path()のalias、r->uri_changedのステータスチェックに対応します。

S6 — 公式ソースコミット: CVE-2026-93479

HTTP/Stream スクリプトの長さと予約されたバッファ割り当てロジックに対応します。

S7 - 公式ソースコミット: CVE-2026-97205

r->main->blocked カウントしきい値 NGX_HTTP_MAX_BLOCKED 250 および非同期パス フォールバックに対応します。

S8 — 公式ソースコミット: CVE-2026-95101

HTTP/3 不明フレーム残り長と DATA リクエストボディ長に対応するステータス区切り。

S9 — 公式ソースコミット: CVE-2026-97629

同期 TLS セッション チケット ローテーション中のすべてのキー スロットに対応します。

S10 — F5: CVE-2026-15176 ベンダーの発表

alias、rewrite、$request_filenameなどのトリガー要因とアクセスログを一覧表示します。

S11 — F5: CVE-2026-93479 ベンダー発表

マップ正規表現キャプチャ、root パス、およびログ変数の評価条件をリストします。

S12 — NGINX 公式 TLS/SSL モジュール ドキュメント

説明 ssl_session_cache、ssl_session_tickets、ssl_session_ticket_key およびクライアント証明書の認証およびその他の指示。

S13 — セキュリティ勧告: Ubuntu USN-8955-1 (2026-10-26)

Ubuntu 22.04 / 24.04 / 26.04 / 26.10. の完全なソフトウェア パッケージ修正バージョンと配布範囲を提供します。

S14 — セキュリティ勧告: Debian DSA-6575-1 (2026-10-21)

Debian 13 / trixie のセキュリティ修正パッケージ 1.26.3-3+deb13u10 を確認し、CVE-2026-93479 のバックポートの関連付けを記録します。

S15 — 脆弱性の追跡: Debian Security Tracker: CVE-2026-15176

Debian 12 / bookworm および Debian 13 / trixie の配布修正ステータスを確認するために使用されます。このステータスは、将来のセキュリティ更新により変更される可能性があります。

S16 — 脆弱性の追跡: Debian Security Tracker: CVE-2026-95101

別の Debian ブランチにおける HTTP/3 脆弱性のセキュリティ状況の補足的な確認。

S17 — セキュリティ勧告: Red Hat: CVE-2026-93479

10 月の回帰脆弱性と 7 月の CVE-2026-42533 の修正との相関関係についての補足説明。

S18 — NGINX 公式リバース プロキシ モジュール ドキュメント

proxy_request_buffering、client_max_body_size、alias、aio などの構成のセマンティクスとデフォルト値を照会します。

S19 — NGINX Plus 公式リリースノート

Plus CR/LTS ブランチ、バージョン、パッチ、およびアップグレードの互換性リマインダーをリストします。

S20 — NGINX JavaScript / njs 公式セキュリティ情報

2026 年 10 月の njs 1.0.2 および関連する XML 検証、メモリ枯渇の問題が含まれます。

S21 — Kubernetes: コミュニティ ingress-nginx の公式引退手順

プロジェクトは 2026 年 3 月に新しいリリースとセキュリティ修正を停止したため、維持されているコントローラーまたは Gateway API を移行することをお勧めします。

S22 — NGINX 公式サービス コントロールおよびオンライン バイナリ アップグレード手順

プロセス切り替えを受け入れるための構成のリロード、再起動、およびオンライン実行可能ファイルのアップグレード方法を区別します。

S23 - 政府セキュリティ通知: 2026 年 5 月 NGINX 書き換えの脆弱性

CVE-2026-42945 に関する過去のリスク背景とセキュリティ更新プログラムの提案を提供します。自然環境での搾取に関する判断は、当時の当局の発表とさらなる事件証拠に基づいて行われるべきです。

S24 — F5: CVE-2026-95101 および CVE-2026-97629 ベンダー発表

HTTP/3 リクエスト本文の挿入と TLS チケット キーの自動ローテーションのリスクをそれぞれカバーします。

S25 — F5: CVE-2026-97205 ベンダーの発表

説明 SSI/AIO のトリガー条件と潜在的なメモリ破損のリスク。

NGINX セキュリティ アップデート: 構成チェック、アップグレード、検証