CVE-2026-9256とは：nginx rewriteで落ちる設定の条件と修正版、Ubuntu・RHELの対応【2026年11月】

CVE-2026-9256は、nginxのURL書き換えを担うngx_http_rewrite_moduleで、重なり合う正規表現キャプチャを複数参照したときに起きるヒープバッファオーバーフローです。2026年5月22日の1.30.2・1.31.1で修正されました。前の週の1.30.1で直ったCVE-2026-42945（NGINX Rift）と同じモジュールの欠陥で、42945対応の版も影響を受けます。本記事では、公式Dockerイメージの1.30.0〜1.30.6を同じ設定で動かし、落ちる書き方と落ちない書き方を切り分けた結果と、配布元ごとの修正版、更新できない間の書き換えの注意点を2026年11月13日時点の情報でまとめます。nginx全体の最新版と更新手順はnginxの最新バージョンと確認・更新手順で追っています。

まとめ：CVE-2026-9256の条件・修正版・今すぐ上げる版

• 公式の成立条件は、rewriteの正規表現に別個で重なり合うキャプチャがあり、置換文字列がそれらを複数参照し、redirectか引数の文脈で使うことです。代表例の入れ子^/((.*))$＋$1$2を1.30.1で実測すると、redirect・?付きのlast・?なしのredirectの3通りでワーカーがsignal 11で終了しました
• キャプチャが重ならない$1$2、入れ子でも1つだけの参照、同じ$1の2回参照では落ちません。1.30.2・1.30.6では同じ設定でもredirectは302、lastは200を返し、クラッシュしませんでした
• nginx.orgの影響範囲は0.1.17〜1.31.0。CVSS v4.0は9.2、nginx公式の深刻度はmedium、Red HatはImportantです
• 上流の更新先は2026年11月13日時点で安定版1.30.6かmainline 1.31.7以降です。1.30.2で9256は直りますが、10月14日の5件（CVE-2026-15176など）が残ります
• Ubuntu 24.04は1.24.0-2ubuntu7.9で9256、7.19で10月の5件まで修正済み。RHELは6月に9256、11月11日に10月分のRHSAが出ました。Debian bookwormは10月分のCVE-2026-15176が未修正です
• Red Hatの緩和策（名前付きキャプチャへの置き換え）はクラッシュを止めますが、値がエスケープされなくなります。[^/]+のような式ではLocationの後ろに任意のヘッダーを差し込めたため、外側の括弧を(?:...)にする書き換えを勧めます

CVE-2026-9256の成立条件と1.30.1・1.30.2の実測比較

重なり合うキャプチャを複数参照すると起きるヒープオーバーフロー

NVDに登録されたCVE-2026-9256の説明では、rewriteの正規表現に別個で重なり合うPCREキャプチャがあり、置換文字列がそれらを複数参照し、redirectか引数（arguments）の文脈で使われるときに、ワーカープロセスでヒープバッファオーバーフローが起きます。認証は不要で、結果はワーカーの再起動、ASLRが無効か回避された環境では任意コード実行です。nginxのCHANGES-1.30は1.30.2の項に「overlapping captures in ngx_http_rewrite_module」と書き、報告者としてWinfunc ResearchのMufeed VH氏を挙げています。F5の告知はナレッジ記事K000161377です。

rewriteは置換先にキャプチャを埋め込むとき、URLとして必要なエスケープを加えた長さを先に数えてからバッファを確保し、そのあとで書き込みます。重なったキャプチャを続けて参照すると、この2つの処理が数える長さと書き込む長さが食い違います。エスケープが要る文字（空白や"など）が多いURLほど書き込みが確保量を超える幅が大きくなる、というのが実測で見えた傾向です。

公式Dockerイメージ1.30.0〜1.30.6で落ちる書き方・落ちない書き方

2026年11月13日に、公式Dockerイメージのnginx 1.30.0・1.30.1・1.30.2・1.30.6を同じ設定ファイルで起動し、書き方を変えた6つのlocationへ、エスケープの要る文字を多く含む約6,000文字のURIを送りました。あわせて「同じ番号の2回参照」「非キャプチャ括弧」の2通りは、落ちる版である1.30.1だけで確かめました。ワーカーの異常終了は、masterプロセスがエラーログに出す「worker process … exited on signal 11」で数えています。

落ちたのは、入れ子のキャプチャを2つとも参照した3通りだけです。置換先に?が無いredirectでも落ちたのは、redirectではキャプチャがURL用にエスケープされるためで、CVEの説明にある「redirectか引数の文脈」と一致します。短い入力（a%20b%22c）でも1.30.0・1.30.1はLocationの末尾が数バイト化けたURLを返し、1.30.2以降はa%20b%22ca%20b%22cと正しく返しました。測定にはDocker Hubの公式イメージ（nginx:1.30.0〜nginx:1.30.6、linux/amd64）をそのまま使い、設定ファイルと測定スクリプトは手元の検証環境の記録として残しています。PoCのコードは使っていません。

CVSS 9.2とnginx公式のmediumの差、被害の下限と上限

CNAのF5はCVSS v4.0で9.2（AV:N/AC:H/AT:P/PR:N/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N）、v3.1で8.1を付けました。一方、nginx.orgのアドバイザリ一覧は同じ件をmediumに分類しています。既定の設定では踏まず、上の表の書き方をしたrewriteが前提になるため、評価主体によって重みが変わります。数字の読み方はnginx 1.30.3〜1.30.6で直ったCVSS v4.0 9.2の読み方で詳しく扱っています。

被害の下限はワーカーの再起動です。実測でも、落ちたワーカーはmasterがすぐ起こし直しましたが、そのワーカーが抱えていた接続はすべて切れます。決済や予約受付の途中で切れると困るサービスでは、繰り返し送られるだけで断続的な障害になります。上限の任意コード実行は、ASLRが無効か回避された場合に限られます。コンテナではホストのカーネル設定が効くので、ノード側の/proc/sys/kernel/randomize_va_spaceが2かを確かめます。

CVE-2026-9256の影響を受ける版と配布元ごとの修正版

nginx.orgとCVEレコードで影響範囲の書き方が違う点

nginx.orgは影響範囲を0.1.17〜1.31.0、非該当を1.30.2以降・1.31.1以降としています。一方、CVEレコードの影響範囲欄は0.1.17〜0.9.7、1.30.0〜1.30.1、1.31.0の3区間だけを挙げ、それ以外を既定で非該当と表記しています。これを機械的に読むと1.0〜1.29系が対象外に見えますが、Red Hatは1.20・1.24・1.26系へ、Ubuntuは1.4系から1.28系まで修正を出しています。脆弱性スキャナーがCVEレコードの範囲だけで判定していないかも確かめてください。

NGINX Plus・Ubuntu・RHEL・Debianの修正版一覧

UbuntuはUbuntuのCVE-2026-9256のページとUSN-8354-1（6月1日）、10月の5件はUSN-8955-1（10月26日）です。20.04・18.04はUbuntu Pro（ESM）の版で9256と10月分の修正が出ています。16.04・14.04はさらに古く、ESMに加えてLegacy Support add-onの契約が要ります。RHELは9256がRHSA-2026:28973（RHEL 9、6月24日）とRHSA-2026:29874（RHEL 10、6月25日）で、11月2日にはRHEL 9.2〜9.6の延長サポート向けにも出ました。10月分は11月11日のRHSA-2026:98529（RHEL 9）・98634（RHEL 10）です。Debianは9256がDSA-6326-1、10月のCVE-2026-15176はtrixieだけDSA-6575-1で直り、Debianのセキュリティトラッカーではbookwormがvulnerableのままです。配布元の版は上流の版番号が上がらないので、nginx -vが1.24.0や1.22.1のままでも修正済みのことがあります。

1.28系以前と退役したingress-nginxに残る修正の空白

上流のlegacyの1.28系は2026年3月の1.28.3が最終で、5月以降の修正を含みません。上流のソースから1.28系以前を自前でビルドしているなら、修正コミットを取り込んで自前でパッチする手もありますが、以後の修正に追随し続ける負担を考えると、保守される1.30系か1.31系へ移るのが現実的です。Kubernetesのingress-nginxはKubernetes公式ブログの告知どおり2026年3月で退役し、以後はセキュリティ修正が出ません。移行先は退役したingress-nginxとF5版の違い・移行判断で整理しています。

自社サーバーがCVE-2026-9256に該当するかを確かめる手順

上流ビルドの版を判定するスクリプト

nginx.orgの公式リポジトリやソースから入れた版は、版番号で判定できます。次のスクリプトは、9256を含む2026年の修正をまとめて満たす1.30.6・1.31.7と比べます。

v=$(nginx -v 2>&1 | sed -n 's|.*nginx/\([0-9.]*\).*|\1|p')
if [ -z "$v" ]; then
  echo "nginxの版番号を取得できませんでした" >&2
  exit 1
fi
case "$v" in
  1.30.*) need=1.30.6 ;;
  1.31.*) need=1.31.7 ;;
  *)      need="" ;;
esac
if [ -z "$need" ]; then
  echo "$v: 1.30/1.31系以外。上流の2026年5月以降の修正は1.30/1.31系にしか出ていない"
elif [ "$(printf '%s\n' "$need" "$v" | sort -V | head -n 1)" = "$need" ]; then
  echo "$v: $need 以上"
else
  echo "$v: $need 未満のため更新が必要"
fi

公式イメージの中で実行すると、nginx:1.29（1.29.8）は「1.30/1.31系以外」、1.30.1と1.30.2は「1.30.6 未満のため更新が必要」、1.30.6は「以上」、latest（1.31.8）は「1.31.7 以上」と出ました。nginx -vは標準エラーへ出力するので2>&1が要ります。sort -Vで比べるため、末尾が2桁の版も正しく並びます。ディストリビューション同梱版には使えません。

Ubuntu・Debian・RHEL同梱版を修正版と照合するコマンド

# Ubuntu・Debian：インストール済みの版を、配布元の修正版と比べる（例はUbuntu 24.04の10月分）
v=$(dpkg-query -W -f='${Version}' nginx-core 2>/dev/null || dpkg-query -W -f='${Version}' nginx)
if dpkg --compare-versions "$v" ge 1.24.0-2ubuntu7.19; then echo "$v: 修正版以上"; else echo "$v: 未満"; fi

# RHEL・AlmaLinux・Rocky Linux：changelogに載ったCVE番号を一覧にする補助確認
rpm -q --changelog nginx | grep -oE 'CVE-2026-[0-9]+' | sort -u

dpkg --compare-versionsはDebian系の版の並び順で比べるので、7.9と7.19のような比較も正しく扱えます（7.9・7.18は「未満」、7.19・7.20は「以上」を実測で確認）。比べる版は上の表から自分のリリースの値に置き換えます。rpmのchangelogは補助で、CVE番号が無くても未修正とは言い切れないため、rpm -q nginxの版をRHSAの修正版と照合して判断します。

設定から重なり合うキャプチャを探す補助検索

nginx -T 2>/dev/null | grep -nE 'rewrite[[:space:]]+[^[:space:]]*\([^)[:space:]]*\(' | grep -E '\$[0-9].*\$[0-9]'

1段目は正規表現の中で括弧が閉じる前に次の括弧が開く行（入れ子のキャプチャ）、2段目は$1などの番号参照が2つ以上ある行を拾います。実測に使った8パターンの設定にかけると、落ちた3行だけが出ました。(?:の非キャプチャ括弧も1段目に掛かるので、拾った行は目で確かめます。nginx -Tはinclude先も展開した全設定を出力しますが、1つのrewriteが複数行に折り返して書かれていると、この行単位の検索では拾えません。結果が空でも更新は省きません。正規表現の括弧とキャプチャの数え方は正規表現の基本記号と言語ごとの方言が参考になります。コンテナに同梱されたnginxや、ロードバランサーの実体として動くnginxも同じ確認の対象です。

更新手順と、更新できない間の書き換えで避けるべき落とし穴

修正版への更新と旧ワーカーが残っていないかの確認

1. nginx -Vでビルド構成を控え、/etc/nginx以下の設定一式を退避する
2. 上流版は1.30.6（mainlineなら1.31.7以降、11月13日時点の最新は1.31.8）へ、同梱版は配布元の修正パッケージへ更新する
3. nginx -tで設定を検査し、再起動後にps -e -o pid,ppid,lstart,cmd | grep nginxでmasterとワーカーの起動時刻が更新後になったかを見る
4. rewriteを使うURLで、リダイレクト先とクエリ文字列が更新前と同じかを確かめる

パッケージを入れ替えても、稼働中のプロセスが古いバイナリのままでは修正は効きません。nginx -s reloadは設定を読み直すだけでバイナリは替わらないため、masterごと再起動します。

名前付きキャプチャへの置き換えでエスケープが外れヘッダーを差し込まれる問題

Red HatはCVE-2026-9256の緩和策として、rewrite ^/users/([0-9]+)/profile/(.*)$ /profile.php?id=$1&tab=$2 last;の$1・$2を名前付きキャプチャへ置き換える方法を示しています。実測でも名前付きにすると1.30.1は落ちませんでしたが、出力が変わります。番号のキャプチャはURL用にエスケープされてa%20b%22cになるのに対し、名前付きは変数として扱われ、デコード済みのa b"cがそのままLocationに入りました。

さらに1.30.6でrewrite ^/h/(?<x>[^/]+)$ /t?a=$x redirect;に%0D%0ASet-Cookie:%20s=1を含むURLを送ると、応答にSet-Cookie: s=1という独立したヘッダー行ができました。番号キャプチャの$1版では%0D%0Aのまま返ります。.*は改行に一致しないため影響しませんが、[^/]+のような否定の文字クラスは改行にも一致します。緩和策を当てた結果、クラッシュの代わりにレスポンスヘッダーインジェクションを抱えることになります。

更新までのつなぎには、番号のキャプチャのまま重なりを無くす書き換えを選びます。外側の括弧を(?:...)にして参照を1つにする形と、同じ$1を2回書く形は、1.30.1でもエスケープを保ったまま落ちませんでした。ただし前者は値を1回、後者は2回出力するので、元のURLと同じ結果になるよう参照の番号と回数を合わせます。前段のWAFは攻撃の試行を減らせますが、正常なURLと見分けにくい入力でも成立するため補助にとどまります。

2026年のnginx脆弱性の中でのCVE-2026-9256の位置づけ

修正リリースとCVEの時系列

表はnginx.orgのアドバイザリ一覧とCHANGESから作りました。10月21日の1.31.8にSecurityの項は無く、11月13日時点で10月14日より後の修正はありません。42945とは条件が違うため、42945の修正版1.30.1では塞がりません。10月のCVE-2026-15176は、rewriteで書き換えたURIをaliasでファイルパスへ対応付ける経路のオーバーフローで、9256の修正版1.30.2も影響を受けます。10月の5件それぞれが成立する設定は1.30.6までに直ったnginx脆弱性の解説で、42945の条件と判定はNGINX Rift（CVE-2026-42945）の影響判定で扱っています。

悪用状況：KEV未掲載・EPSS・GitHubの公開リポジトリ

CISAのKEVカタログの2026年11月10日版（2026.11.10）に、nginxのCVEは1件も載っていません。CVEレコードに付いたCISAのSSVC評価（公表時の2026年5月22日時点）もCVE-2026-9256は悪用「none」、自動化「no」です。FIRSTのEPSSは11月12日時点で9256が0.109（上位4%）、42945は0.680です。GitHubでCVE-2026-9256を名前や説明に含むリポジトリは6件あり、名前にPoCを含むものが2件（5月28日・6月3日作成）、ほかはスキャナーや調査メモ、脆弱性名だけのものです。悪用コードとPoCの違いはexploitとPoCの違いと悪用状況の確認手順で整理しています。上の実測どおり、条件に当たる設定なら長いURLを1本送るだけでワーカーが落ちるため、KEV未掲載を理由に後回しにはできません。更新の期限を事前に決めておく運用はKEVで優先度を決めるパッチ管理の手順が参考になります。外部公開しているnginxの版と設定の棚卸しを社内で回し切れない場合は、一創の脆弱性診断・セキュリティ診断で設定の確認から更新後の再診断まで引き受けています。

よくある質問

CVE-2026-42945対応の1.30.1や9月の1.30.5を当てていれば安全ですか？

安全ではありません。CVE-2026-9256は1.30.0〜1.30.1と1.31.0に残っており、実測でも1.30.1は落ちました。9月の1.30.5は9256は直っていますが、10月14日のCVE-2026-15176など5件の影響版です。11月13日時点の更新先は1.30.6、mainlineなら1.31.7以降です。

Ubuntu 24.04のnginxはどの版でCVE-2026-9256が直っていますか？

1.24.0-2ubuntu7.9（USN-8354-1）で直りました。10月の5件まで含めるなら1.24.0-2ubuntu7.19（USN-8955-1）以上が必要です。同じ順で22.04は1.18.0-6ubuntu14.12と14.22、26.04は1.28.3-2ubuntu1.2と1.28.3-2ubuntu1.12です。20.04・18.04はUbuntu Pro（ESM）、16.04・14.04はLegacy Support add-onの契約で修正が提供されます。

CVE-2026-9256のPoCは公開されていますか？

GitHubには名前にPoCを含むリポジトリが2件あります（2026年11月13日時点）。本記事ではそれらのコードは使わず、CVEの説明にある条件を設定ファイルで作って挙動を比べました。CISAのSSVC評価（2026年5月22日時点）は悪用「none」ですが、条件に当たる設定なら単純なリクエストでワーカーが落ちることは確認できています。

rewriteを使っていなければ更新しなくてよいですか？

CVE-2026-9256に限れば、重なり合うキャプチャ（((.*))のような入れ子を含む）をredirectか引数の文脈で2つ以上参照するrewriteが無ければ成立しません。ただし2026年の修正にはHTTP/2プロキシ、map、SSI、HTTP/3、TLSセッションチケット、AIOなどrewrite以外の条件で起きるものが多く、すべてに当たらないと言い切るのは困難です。更新を前提に計画してください。

nginx 1.22.1や1.24.0を使っていますが対象外ですか？

対象です。CVEレコードの影響範囲欄は3区間だけですが、nginx.orgは0.1.17〜1.31.0を脆弱としています。ディストリビューションの1.22.1や1.24.0は配布元の修正パッケージで直っていることがあるため、上の表の修正版と照合します。上流からビルドした1.22.1・1.24.0は修正が出ないので、1.30系へ移ります。

関連記事

• nginxの最新バージョンは1.31系（安定版1.30）｜バージョン確認コマンド・更新手順と変更点【2026年10月】
• NGINX Rift（CVE-2026-42945）の影響判定とPoCの中身｜1.30.6までの対応
• nginx 脆弱性：1.30.3〜1.30.6で直ったCVSS v4.0 9.2の読み方と更新先
• NGINX Ingressとは？退役したingress-nginxとF5版の違い・移行判断
• パッチ管理とは：KEVで優先度を決め、Patch Managerとapt・dnfで自動適用する手順