--- title: "nginx 脆弱性：1.30.3〜1.30.6で直ったCVSS v4.0 9.2の読み方と更新先" url: "https://www.issoh.co.jp/tech/details/12647/" published: 2026-06-19 updated: 2026-10-24 categories: ["脆弱性・インシデント"] publisher: "株式会社一創" --- # nginx 脆弱性：1.30.3〜1.30.6で直ったCVSS v4.0 9.2の読み方と更新先 2026年6月17日、nginxの安定版1.30.3とmainline 1.31.2が公開され、HTTP/2・gRPCプロキシのヒープバッファオーバーフローCVE-2026-42055と、文字コード変換のオーバーリードCVE-2026-48142が修正されました。さらに10月14日には、F5がnginx本体と関連製品をあわせた11件を定例外で公表し、そのうち3件がCVSS v4.0で9.2です。検索でよく見る「nginx v1.30.3 CVSS 4.0」は、スコアの値4.0ではなく評価体系CVSS v4.0を指します。本記事では、修正された各件の条件と、F5の9.2とnginx公式の「medium」が食い違う理由をベクトル単位で読み解き、2026年10月24日時点でどの版へ上げるかまでを実務の順に整理します。 ## まとめ：9.2の各件は非既定設定が前提、更新先は1.30.6 CVE-2026-42055は、HTTP/2またはgRPCでアップストリームへプロキシし、`ignore_invalid_headers off`と2MB超の`large_client_header_buffers`を組み合わせた構成でだけ発火します。F5はCVSS v4.0で9.2、v3.1で8.1を付け、nginx公式はmediumに分類しました。CVE-2026-48142は`source_charset utf-8`と`charset`で文字コード変換を行う構成が前提で、v4.0は6.3、公式はlowです。どちらも既定の設定では踏みません。 ただし、1.30.3で止めてよい状況ではありません。7月の1.30.4でmapと正規表現のオーバーフロー（CVE-2026-42533、公式major）など3件、9月15日の1.30.5でHTTP/3のCVE-2026-90439、10月14日の1.30.6でaliasとrewriteの組み合わせによるCVE-2026-15176など5件が直りました。10月の5件のうち3件はv4.0で9.2ですが、nginx公式の区分は5件すべてmediumです。2026年10月24日時点の更新先は安定版1.30.6、mainlineなら1.31.7以降（最新は10月21日の1.31.8）。Ingress ControllerやGateway Fabric、njsを使っている場合は、それぞれの製品側の更新も別に要ります。更新後は`reload`で済ませず、新しいバイナリが動いていることを確かめます。 ## nginx 1.30.3と1.31.2が修正したCVEと影響範囲の全体像 ### 2026年6月17日の安定版・mainline同時公開で直った3件 [nginxのCHANGES-1.30](https://nginx.org/en/CHANGES-1.30)によると、1.30.3が直したのはCVE-2026-42055とCVE-2026-48142の2件です。同日のmainline 1.31.2はこの2件に加えて、HTTP/3のuse-after-free（CVE-2026-42530）も直しました。CVE-2026-42530は1.31.0〜1.31.1にしか存在しないため、安定版の1.30系は最初から対象外です。報告者はCVE-2026-42055がWinfunc ResearchのMufeed VH氏、CVE-2026-48142がXiaomiのHan Yan氏とCYBERONEのp4p3r氏です。 ### CVE-2026-42055・48142・42530の評価と影響版の比較表 | CVE | CVE-2026-42055 | CVE-2026-48142 | CVE-2026-42530 | | ------------- | -------------- | -------------- | -------------- | | 対象モジュール | proxy\_v2・grpc | charset | v3（HTTP/3） | | nginx公式の深刻度 | medium | low | major | | CVSS v4.0（F5） | 9.2（AT:P） | 6.3 | 9.2（AT:N） | | CVSS v3.1（F5） | 8.1 | 4.8 | 8.1 | | 影響を受ける版 | 1.13.10〜1.31.1 | 0.3.50〜1.31.1 | 1.31.0〜1.31.1 | | 修正版 | 1.30.3・1.31.2 | 1.30.3・1.31.2 | 1.31.2 | 影響範囲と深刻度は[nginx.orgのアドバイザリ一覧](https://nginx.org/en/security%5Fadvisories.html)、スコアは[NVDのCVE-2026-42055](https://nvd.nist.gov/vuln/detail/CVE-2026-42055)と[CVE-2026-48142](https://nvd.nist.gov/vuln/detail/CVE-2026-48142)の記載です。CVE-2026-42055はNGINX Plusでも37.0（37.0.2.1未満）とR36（P6未満）が影響を受けます。CVE-2026-42055はワーカーの再起動に加え、ASLRが無効か回避された環境ではコード実行にも至る脆弱性です。CVE-2026-48142は限定的なメモリの読み出しかワーカーの再起動にとどまります。 ### NGINX Riftから1.30.6まで続いた脆弱性修正の流れ 1.30.3は2026年に続いた修正の4本目にあたります。5月13日の1.30.1でrewriteのCVE-2026-42945（NGINX Rift）ほか6件、5月22日の1.30.2で同じrewriteのCVE-2026-9256、そして1.30.3、7月15日の1.30.4、9月15日の1.30.5、10月14日の1.30.6と続きました。半年で6回の安定版更新があり、CVEを1件ずつ追うより、マイナーリリース単位で追いつくほうが抜けは出にくくなります。rewrite設定が攻撃条件に当たるかの判定は[NGINX Rift（CVE-2026-42945）の影響判定とPoCの中身](https://www.issoh.co.jp/tech/details/12209/)で、年間の経緯と影響範囲の全体像は[nginxで再発した脆弱性CVE-2026-9256の概要と影響範囲](https://www.issoh.co.jp/tech/details/12251/)で扱っています。 ## 2026年10月14日にF5が公表したnginx関連11件の内訳と修正版 F5は現地時間2026年10月14日、定例外のセキュリティアドバイザリでnginx関連の11件を公表しました。内訳はnginx本体5件、NGINX JavaScript（njs）2件、NGINX Gateway Fabric 2件、NGINX Ingress Controller 2件です。国内では[Security NEXTの10月20日の記事](https://www.security-next.com/191645)が、nginx公式は本体5件をすべてmediumとし、F5は3件をv4.0で9.2（Critical）と評価したと報じています。以下の数値は、F5がCNAとしてNVDへ登録したベクトルと、nginx.orgの一覧を突き合わせたものです。 ### nginx本体5件・njs2件・Ingress Controller等4件の一覧表 | CVE | 製品と発火する箇所 | v4.0（F5） | 修正版 | | --------------- | -------------------- | -------- | ------------- | | CVE-2026-15176 | 本体：aliasとrewrite | 9.2 | 1.30.6・1.31.7 | | CVE-2026-93479 | 本体：文字列式とmap | 9.2 | 1.30.6・1.31.7 | | CVE-2026-97205 | 本体：AIOとSSI | 9.2 | 1.30.6・1.31.7 | | CVE-2026-97629 | 本体：TLSチケット鍵 | 8.3 | 1.30.6・1.31.7 | | CVE-2026-95101 | 本体：HTTP/3 | 6.9 | 1.30.6・1.31.7 | | CVE-2026-101019 | njs：XML署名検証 | 8.3 | njs 1.0.2 | | CVE-2026-101025 | njs：XML解析の漏れ | 6.9 | njs 1.0.2 | | CVE-2026-91184 | Gateway Fabric：認証 | 8.7 | F5の記事で確認 | | CVE-2026-96615 | Gateway Fabric：Agent | 7.1 | F5の記事で確認 | | CVE-2026-94197 | Ingress：外部認証 | 8.7 | F5の記事で確認 | | CVE-2026-104939 | Ingress：外部認証 | 8.7 | F5の記事で確認 | 本体5件の影響範囲は[nginx.orgのアドバイザリ一覧](https://nginx.org/en/security%5Fadvisories.html)で、CVE-2026-15176が0.1.29〜1.31.6、CVE-2026-97205が0.8.11〜1.31.6と古い版まで広く及びます。CVE-2026-93479だけは安定版1.30.0〜1.30.5とmainline 1.31.2〜1.31.6に限られます。njsの2件は[njsの変更履歴](https://nginx.org/en/docs/njs/changes.html)にある1.0.2（10月14日）で直りました。CVE-2026-101019はXML署名の検証を飛ばされうる不具合、CVE-2026-101025は不正なXMLの解析失敗でメモリが解放されず、長く動くワーカーのメモリが増え続ける不具合です。 ### 本体5件を直した1.30.6と1.31.7・最新1.31.8の位置づけ [mainlineのCHANGES](https://nginx.org/en/CHANGES)では、1.31.7が10月14日に本体5件を直し、1.31.8が10月21日に出ています。1.31.8の変更はworking\_directoryの扱いやHTTP/3の不具合修正などで、セキュリティ修正は含みません。安定版の1.30.6はセキュリティ5件のほか、HTTP/2クライアントへの応答送信中のuse-after-freeなどの不具合修正も取り込みました。1.30.4でscriptコードを使うサードパーティモジュールとのバイナリ互換が崩れた不具合も、1.30.6で直っています。モジュールの互換問題で1.30.3に留まっていた環境は、1.30.6で追いつけるかを先に確かめる価値があります。 ### Ingress ControllerとGateway Fabricの4件は別製品の更新 Kubernetesで使う2製品の4件は、nginx本体を1.30.6へ上げても解消しません。CVE-2026-94197は、ExternalAuthポリシーを使う構成で、利用者が送ったX-Forwarded-URIなどのヘッダーが認証サブリクエストへそのまま渡り、認証を回避されうる問題です（[F5のK000162611](https://my.f5.com/manage/s/article/K000162611)）。CVE-2026-91184は、共有GatewayでAuthenticationFilterのrealm値がnginx.confへエスケープなしに書き込まれ、名前空間の権限を持つ利用者が任意のディレクティブを注入できる問題です（[F5のK000162609](https://my.f5.com/manage/s/article/K000162609)）。同じ10月14日には[Ingress Controller 5.7.0](https://github.com/nginx/kubernetes-ingress/releases/tag/v5.7.0)（LTS系は2026-lts-r9）と[Gateway Fabric 2.8.0](https://github.com/nginx/nginx-gateway-fabric/releases/tag/v2.8.0)が公開されました。ただしリリースノートにCVE番号の記載はないため、自社の版が対象かどうかはF5のK記事の修正版欄で確かめます。退役したコミュニティ版ingress-nginxとF5版の見分け方は[NGINX Ingressとは？退役したingress-nginxとF5版の違い](https://www.issoh.co.jp/tech/details/15773/)で整理しています。 ## CVSS v4.0スコア9.2とnginx公式mediumをベクトルで読む方法 ### 「CVSS 4.0」がスコア値ではなく評価体系のv4.0を指す理由 CVSSは脆弱性の深刻度を0.0〜10.0で表す指標です。[FIRSTのCVSS v4.0仕様](https://www.first.org/cvss/v4.0/specification-document)では、4.0〜6.9がMedium、7.0〜8.9がHigh、9.0以上がCriticalにあたります。一方、v4.0はFIRSTが2023年11月に公開した評価体系の版を指します。F5のアドバイザリやNVDはv3.1とv4.0を併記しており、「CVSS 4.0」という表記は、ほぼすべてがv4.0体系で算出した値（CVE-2026-42055なら9.2）の意味です。スコアの値が4.0なら深刻度はMediumの下限で、9.2とは扱いがまったく異なります。CVEとCVSSの関係は[CVEの仕組みとCVSS・NVDとの違い](https://www.issoh.co.jp/tech/details/5092/)、v3.1の計算式とスコアの目安は[CVSSv3.1の計算式と3つの評価基準](https://www.issoh.co.jp/tech/details/5094/)が参考になります。 ### 同じ9.2でもAT:PとAT:Nで前提が違うCVE-2026-42055の読み方 CVE-2026-42055のv4.0ベクトルはAV:N/AC:H/AT:P/PR:N/UI:N/VC:H/VI:H/VA:Hです。ネットワーク経由（AV:N）・認証不要（PR:N）・利用者の操作不要（UI:N）で、成功すれば機密性・完全性・可用性のすべてが高い（VC/VI/VA:H）という評価が9.2を押し上げています。注目すべきはAT:P（Attack Requirements: Present）で、攻撃者の制御外にある前提条件が必要だという意味です。同じ9.2でも、HTTP/3のCVE-2026-42530やrewriteのCVE-2026-42945はAT:Nです。v4.0では、AT:PとAC:Hが同時に付いても基本値が9点台に残ることがあり、数値だけで並べると条件の重さの違いが見えなくなります。 ### 10月の9.2の3件はAT:NでもAC:Hが付く点を読み分ける 10月14日に9.2が付いたCVE-2026-15176・93479・97205の3件は、ベクトルがそろってAV:N/AC:H/AT:N/PR:N/UI:N/VC:H/VI:H/VA:Hです。CVE-2026-42055と違ってAT:Nで、v3.1はいずれも8.1でした。ところがNVDに載ったF5の説明文には、3件とも「攻撃者の制御外にある条件のもとで」とあり、コード実行はASLRが無効か回避された場合に限ると書かれています。前提条件はAT:Pではなく、攻撃の難しさを表すAC:Hの側で織り込まれた形です。 つまり、AT:PかAT:Nかだけで「前提の有無」を判定すると読み違えます。条件はベクトルより説明文と設定の側に出るので、9.2の件は次の3点を確かめるのが実務の順序です。 - CVE-2026-15176：aliasを使うlocationでrewriteがURIを書き換え、setやreturn、log\_formatが`$request_filename`を参照しているか（[NVDのCVE-2026-15176](https://nvd.nist.gov/vuln/detail/CVE-2026-15176)） - CVE-2026-93479：mapの正規表現キャプチャを、rootやlog\_formatでmapの出力変数より先に参照しているか（[F5のK000162607](https://my.f5.com/manage/s/article/K000162607)） - CVE-2026-97205：AIOを有効にしたlocationで、SSIの`include virtual`を含むページを返しているか（[F5のK000162608](https://my.f5.com/manage/s/article/K000162608)） 同じ日のCVE-2026-97629（v4.0で8.3）は反対にAT:Pで、明示的な`ssl_session_ticket_key`を置かずに`ssl_session_cache shared`でチケット鍵を自動ローテーションさせている構成が前提です。偽造できるセッションは攻撃者が狙って選べないとされる一方、クライアント証明書の検証を回避されうるため、相互TLSで利用者を認証している環境では9.2の3件より優先度が上がることもあります。 ### nginx公式のmediumとRed HatのImportantが示す実運用の重み nginx公式がmediumとしたのは、発火に3つの非既定設定がそろう必要があるためです。[Red HatのCVEページ](https://access.redhat.com/security/cve/CVE-2026-42055)も深刻度をImportantとし、HTTP/2プロキシを明示的に設定した場合に限られること、ワーカーの再起動は確実に起きる一方でコード実行にはASLRの回避が必要なことを理由に挙げています。CVSSのベーススコアは「最悪の場合の影響と難しさ」、公式の区分は「既定設定で踏むか」を表しており、どちらも誤りではありません。10月の本体5件がすべてmediumなのも、同じ考え方によるものです。優先順位は、スコア、自社の設定が条件に当たるか、インターネットへの公開有無の3つを掛け合わせて決めます。 悪用の兆候を見る指標も2つ確かめておきます。[CISA KEV](https://www.cisa.gov/known-exploited-vulnerabilities-catalog)の2026年10月23日版には、本記事で扱うnginxのCVEは1件も載っていません。EPSSは2026年10月23日時点でCVE-2026-42055が0.065（10月1日時点は0.024）と上がり、10月の9.2の3件は0.005前後です。KEVの掲載を是正期限へどう結びつけるかは[BOD 26-04とKEVの是正期限を決める仕組み](https://www.issoh.co.jp/tech/details/18233/)で解説しています。 ## 非既定設定の発火条件と自社環境をnginx -Tで確かめる手順 ### CVE-2026-42055が発火する3つの設定がそろう構成 - `proxy_http_version 2`または`grpc_pass`で、HTTP/2のアップストリームへプロキシしている - `ignore_invalid_headers`を`off`にしている（既定はon） - `large_client_header_buffers`のサイズを2MB超にしている（既定は4 8k） 3つすべてがそろわなければ発火しません。gRPCバックエンドを使い、かつ巨大なヘッダーを通すためにバッファを広げた構成が典型的な該当例です。CVE-2026-48142は、同じlocationで`source_charset utf-8;`と`charset koi8-r;`のような変換先を指定し、[charsetモジュール](https://nginx.org/en/docs/http/ngx%5Fhttp%5Fcharset%5Fmodule.html)で文字コード変換を行う構成が前提です。 ### nginx -tの成否を確かめてからnginx -Tで該当設定を洗い出す ``` # 設定が読めることを先に確かめる（失敗すると nginx -T は何も出さない） nginx -t || echo "設定エラーを直してから検索する" # CVE-2026-42055・48142 に関わるディレクティブを洗い出す nginx -T 2>/dev/null | grep -nE 'ignore_invalid_headers[[:space:]]+off|large_client_header_buffers|proxy_http_version[[:space:]]+2|grpc_pass|source_charset|charset[[:space:]]' ``` nginx:1.30.5の公式コンテナに、3条件をそろえた設定と`location /g/ { grpc_pass ... }`のような1行書きの設定を読ませて試しました。行頭を`^`で固定した検索では1行書きの`grpc_pass`と`source_charset`を取り逃したため、上の例はアンカーを付けていません。charset\_mapが無い状態で`charset koi8-r`を書くと`nginx -t`が失敗し、`nginx -T`の出力が空になることも確認しています。ヒットしたら、3条件が同じserverまたはlocationで同時に効いているかを確かめます。 ### 10月公表分のalias・AIO・TLSチケット設定をnginx -Tで洗い出す 10月14日の本体5件も、同じ`nginx -T`の出力から当たりを付けられます。下の例は、5件の説明文に出てくるディレクティブと変数をまとめて拾うものです。SSIの`include virtual`は設定ファイルではなく配信するHTML側に書かれるため、ドキュメントルートを別に検索します。 ``` # CVE-2026-15176・93479・97205・97629・95101 に関わる設定を拾う nginx -T 2>/dev/null | grep -nE 'alias[[:space:]]|request_filename|map[[:space:]]|aio[[:space:]]|ssi[[:space:]]+on|ssl_session_cache|ssl_session_ticket|http3[[:space:]]+on|quic|proxy_request_buffering' # SSI の include virtual を含むページを探す（ドキュメントルートは環境に合わせる） grep -rl 'include virtual' /usr/share/nginx/html /var/www 2>/dev/null ``` ヒットした行は、そのまま該当を意味しません。aliasがあっても同じlocationにrewriteと`$request_filename`の参照がなければCVE-2026-15176の条件から外れますし、aioがあってもSSIを返していなければCVE-2026-97205の条件はそろいません。`ssl_session_cache shared`がある一方で`ssl_session_ticket_key`が1行も出てこない構成は、CVE-2026-97629の前提（チケット鍵の自動ローテーション）に当たります。[sslモジュールの文書](https://nginx.org/en/docs/http/ngx%5Fhttp%5Fssl%5Fmodule.html)によると、この自動ローテーションは1.23.2で入った動作で、CVE-2026-97629の影響範囲が1.23.2からになっているのと符合します。 ## 2026年10月時点の更新先として1.30.6と1.31.8を選ぶ基準 ### 安定版1.30系とmainline 1.31系の選び方とHTTP/3の扱い 本番のWebサーバーは安定版1.30.6が基本です。安定版は機能追加を抑えて修正を取り込む系列で、2026年5月以降の修正はすべて1.30系にも入っています。mainlineを選ぶのは、1.31系の新機能を使う場合です。その場合は1.31.7以降、10月24日時点なら最新の1.31.8まで上げます。1.31.0〜1.31.1にはHTTP/3のCVE-2026-42530があり、1.31.2より前で止めると安定版より穴が多くなります。HTTP/3を使う場合は、1.29.2〜1.31.5に影響するCVE-2026-90439（HTTP/3とOpenSSL 3.5.0以前の組み合わせ）と、1.25.0〜1.31.6に影響するCVE-2026-95101（HTTP/3でのリクエストボディ注入）の両方を踏まえ、1.30.6か1.31.7以降が必要です。系列の位置づけと版ごとの変更点は[nginxの最新バージョンと確認方法・更新手順](https://www.issoh.co.jp/tech/details/11585/)でも扱っています。 ### legacy 1.28系とディストリビューション同梱版での判断 [nginx.orgのダウンロードページ](https://nginx.org/en/download.html)では、2026年10月24日時点でもlegacyの1.28系は3月の1.28.3で止まっており、1.30.1以降の修正を含みません。上流ビルドで1.28系以前を使っているなら1.30.6へ移行します。RHEL系やDebian系の同梱版は、版番号を据え置いたまま修正をバックポートしています。Red HatはCVE-2026-42055について、RHEL 9の1.20.1系にRHSA-2026:36331（nginx-2:1.20.1-28.el9\_8.4）を出しました。同梱版は`rpm -q --changelog nginx | grep CVE-2026-42055`のように、パッケージのchangelogで修正の有無を確かめます。10月の5件も同じ要領で、CVE番号ごとにchangelogを検索します。 ## nginxの更新と再起動の手順と即時更新が難しい場合の暫定緩和策 ### reloadでは新バイナリに替わらない点を踏まえた実行ファイルの更新手順 1. `nginx -V`でビルド構成を控え、設定一式を退避する 2. 公式リポジトリかディストリビューションのパッケージで1.30.6（または1.31.7以降）へ更新する 3. `nginx -t`で設定を検査する 4. サービスを再起動するか、masterプロセスへUSR2を送って実行ファイルを入れ替える 5. `ps`で旧masterが残っていないこと、`nginx -v`で目的の版であることを確かめる [nginxの制御に関する公式ドキュメント](https://nginx.org/en/docs/control.html)では、HUP（`nginx -s reload`や`systemctl reload`）は設定ファイルの再読み込みで、実行ファイルの入れ替えはUSR2と定めています。パッケージを入れ替えたあとreloadだけで終えると、ワーカーは作り直されても、それを起動するmasterは古いバイナリのままです。停止を避けたい場合はUSR2による入れ替えを使い、新旧のmasterの切り替わりを確認してから旧プロセスへQUITを送ります。njsを動的モジュールで読み込んでいる場合は、njsのパッケージも1.0.2へそろえてから再起動します。 ### ignore\_invalid\_headersを既定へ戻すなど設定で条件を崩す緩和策 すぐに更新できない場合、CVE-2026-42055はRed Hatが示すとおり、`ignore_invalid_headers on`へ戻すか、`large_client_header_buffers`を2MB以下に抑えれば条件が崩れます。不要な`proxy_http_version 2`や`grpc_pass`を外すことも、条件を崩す方法の一つです。CVE-2026-48142は、使っていない`source_charset`と`charset`の組み合わせを外します。設定変更は`nginx -t`のあとreloadで反映できます。いずれも条件を崩すだけで、1.30.4以降の修正分は未対応のままです。 ### 10月公表のTLSチケット・AIO・aliasを更新まで条件から外す設定 10月の本体5件も、説明文の条件を1つ崩せば成立しなくなる構成が多くあります。次の例は、更新までのつなぎとして入れる設定の形です。いずれもF5やnginx.orgが緩和策として明示したものではなく、説明文にある前提を外す考え方で組んだものなので、検証環境で応答とログの変化を確かめてから入れます。 ``` # CVE-2026-97629：チケット鍵の自動ローテーションを使わない # どちらか一方を選ぶ（チケット自体を止める／鍵ファイルを明示する） ssl_session_tickets off; # ssl_session_ticket_key /etc/nginx/ticket/current.key; # CVE-2026-97205：SSI の include virtual を返す location では AIO を止める location /ssi/ { ssi on; aio off; } # CVE-2026-15176：alias を使う location では $request_filename を # set・return・log_format から参照しない（rewrite と同居させない） ``` `ssl_session_tickets off`にするとTLSの再接続でチケットを使わなくなり、セッションの再開はサーバー側のセッションキャッシュだけになります。複数台で鍵を共有したいなら、鍵ファイルを明示して自分でローテーションする形が向いています。CVE-2026-93479は、mapの出力変数を先に参照してからキャプチャ変数を使う順序へ書き換えれば説明文の条件から外れますが、書き換えの影響範囲が広いため、更新を急ぐほうが現実的です。複数台のnginxやIngress Controllerを横断して設定とバージョンを棚卸ししたい場合は、[一創の脆弱性診断・セキュリティ診断](https://www.issoh.co.jp/service/system/vulnerability/)でも対応しています。 ## よくある質問 nginxの脆弱性とCVSS v4.0の読み方について、よく寄せられる質問に答えます。 ### nginx 1.30.3はどのCVEを修正したバージョンですか？ 2026年6月17日公開の安定版で、ngx\_http\_proxy\_v2\_module・ngx\_http\_grpc\_moduleのヒープバッファオーバーフロー（CVE-2026-42055）と、ngx\_http\_charset\_moduleのオーバーリード（CVE-2026-48142）の2件を修正しました。HTTP/3のCVE-2026-42530は同日のmainline 1.31.2で直り、1.30系はもともと対象外です。 ### CVSS v4.0で9.2なのにnginx公式がmediumなのはなぜですか？ 評価の前提が違うためです。v4.0の9.2は、ネットワーク経由・認証不要で成功すれば影響が大きいことを数値化したもので、CVE-2026-42055はAT:Pで前提条件の存在も示しています。10月14日に9.2が付いた3件はAT:Nですが、説明文には攻撃者の制御外の条件が必要と書かれ、AC:Hに織り込まれています。nginx公式のmediumは、非既定の設定がそろわないと発火しない点を加味した区分です。 ### 2026年10月14日に公表されたnginxの脆弱性は何件ですか？ F5の公表はCVE単位で11件です。nginx本体が5件（1.30.6と1.31.7で修正）、njsが2件（1.0.2で修正）、Gateway FabricとIngress Controllerが2件ずつです。nginx本体だけを更新しても、njsやKubernetes向けの2製品の件は残るため、使っている製品ごとに更新が要ります。 ### 今から更新するなら1.30.3と1.31.2のどちらですか？ どちらでもなく、2026年10月24日時点では安定版1.30.6、mainlineなら1.31.7以降（最新は1.31.8）です。1.30.3の後に、1.30.4でCVE-2026-42533など3件、1.30.5でCVE-2026-90439、1.30.6でCVE-2026-15176など5件が修正されています。本番運用で新機能を使わないなら1.30.6を選びます。 ### パッケージを更新したあとreloadだけで脆弱性は解消しますか？ 解消しません。reload（HUP）は設定の再読み込みで、masterプロセスは古いバイナリのまま動き続けます。サービスを再起動するか、USR2で実行ファイルを入れ替え、旧masterが終了したことを`ps`で確かめてください。 ## 関連記事 - [NGINX Rift（CVE-2026-42945）の影響判定とPoCの中身｜1.30.6までの対応](https://www.issoh.co.jp/tech/details/12209/)：rewrite設定・ASLR・changelogによる該当判定 - [nginxで再発した脆弱性CVE-2026-9256：概要と影響範囲・2026年の修正経緯](https://www.issoh.co.jp/tech/details/12251/)：2026年のnginx脆弱性の時系列と影響範囲 - [nginxの最新バージョンは1.31系（安定版1.30）｜確認方法・更新手順と変更点【2026年10月】](https://www.issoh.co.jp/tech/details/11585/)：系列の位置づけと版の確認方法 - [NGINX Ingressとは？退役したingress-nginxとF5版の違い・移行判断](https://www.issoh.co.jp/tech/details/15773/)：Ingress Controllerの見分け方と移行先 - [CVSSv3とは？v3.1の計算式・スコアの目安と3つの評価基準を解説](https://www.issoh.co.jp/tech/details/5094/)：CVSSの評価項目の基礎 - [CVE（共通脆弱性識別子）とは？仕組み・CVSS/CWE/NVDとの違い](https://www.issoh.co.jp/tech/details/5092/)：CVEとCVSSの関係 --- 出典: [nginx 脆弱性：1.30.3〜1.30.6で直ったCVSS v4.0 9.2の読み方と更新先]()（株式会社一創）