NGINX Rift（CVE-2026-42945）の影響判定とPoCの中身｜1.30.6までの対応

CVE-2026-42945（NGINX Rift）は、nginxのrewrite処理に2008年の0.6.27から残っていたヒープバッファオーバーフローです。2026年5月13日に修正版1.30.1と1.31.0が出て、同じ日に発見者のdepthfirstが技術解説とPoCを公開しました。攻撃が成り立つのは特定のrewrite設定を持つサーバーだけで、CVEレコードはコード実行の条件を「ASLRが無効、または攻撃者がASLRを回避できる場合」としています。本記事では、自社のnginxが該当するかを設定・ASLR・パッケージの3方向から確認する手順を、2026年10月18日に公式コンテナイメージで実行した結果とあわせて示します。あわせて、公開PoCの中身と悪用状況、10月14日の1.30.6までに出た後続修正を整理します。

まとめ：CVE-2026-42945は設定判定のうえ1.30.6へ更新

• 影響を受けるのはNGINX Open Source 0.6.27〜1.30.0と、NGINX Plus R32（P6未満）・R36（P4未満）です。修正版は1.30.1と1.31.0です
• 成立条件は、置換先に「?」を含むrewriteのあとに、無名キャプチャ（$1など）を参照するrewrite・if・setが続く設定です。「?」と$1が同じ行にある必要はありません
• ASLRが有効なら、主な影響はワーカープロセスの異常終了（DoS）です。ただしCVEレコードはASLRを回避された場合のコード実行も含めています。公開PoCのコード実行デモは、nginxをsetarch -RでASLR無効にして起動する環境で動きます
• 1.30.1で止めると後続の修正が抜けます。2026年10月18日時点の到達点は安定版1.30.6、mainline 1.31.7です（10月14日公開・rewriteとaliasの組み合わせによるCVE-2026-15176ほか計5件）
• RHEL系・Debian系の同梱版は版番号が上がらないまま修正されるため、nginx -vではなく、配布元アドバイザリの修正版とパッケージの完全な版番号を照合します。更新後はreloadではなく再起動でバイナリを入れ替えます

この半年のnginxは、CVE単位ではなくマイナーリリース単位で追うほうが安全です。版ごとの変更点と更新手順はnginxの最新バージョンと確認方法・更新手順にまとめています。

CVE-2026-42945の評価が9.2とmediumに割れる理由

同じ脆弱性に「Critical 9.2」「High 8.1」「medium」の3つの評価が並んでいます。使っている尺度の違いです。

CVSS v4.0の9.2とv3.1の8.1の読み方

CNAであるF5が登録したCVE-2026-42945のレコードは、CVSS v4.0の9.2（AV:N/AC:H/AT:N/PR:N/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N）と、v3.1の8.1（AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H）を併記しています。ネットワーク経由・認証不要・利用者の操作不要という骨格は共通で、攻撃条件の複雑さ（AC）はどちらもHighです。9.2と8.1の差はリスクの差ではなく、計算式の世代の差として読みます。Red Hatは自社のCVEページで深刻度をCriticalとしつつ、スコアはv3.1の8.1を載せています。v3.1の各指標の意味はCVSSv3の計算式とスコアの目安で扱っています。

nginx公式のmedium評価と既定設定では踏まない前提

nginx.orgのセキュリティアドバイザリは、本件を「Buffer overflow in the ngx_http_rewrite_module」として深刻度mediumに分類しています。同じ一覧で、HTTP/3のuse-after-free（CVE-2026-42530）とmapと正規表現のオーバーフロー（CVE-2026-42533）はmajorです。この一覧には、本件をmediumとした具体的な理由は書かれていません。一方、Red Hatは同じCVEのページで、悪用には無名キャプチャと置換先の「?」を含む既定ではないrewrite設定が必要だと説明しています。mediumの表記だけで後回しにすると、条件に合う設定が残ったままになります。

is_argsフラグが2段階処理で食い違う発生原因

原因はスクリプトエンジンの2段階処理です。発見者のリポジトリの説明では、必要なバッファ長を数える段階では置換文字列に「?」があることを示すis_argsフラグが立っておらず、書き込む段階ではURIエスケープで1バイトが3バイトに膨らむため、確保した領域を超えて書き込みます。depthfirstの技術解説のタイムラインでは、4月18日に自社の解析システムがnginxのソースから5件のメモリ破壊を検出し、4月21日に報告、5月5日にRCEのPoCを共有、5月13日にF5がアドバイザリ（K000161019）を公開しています。CHANGES-1.30の1.30.1には報告者として「Thanks to Leo Lin」とあります。1.30.1ではscgi・uwsgiのオーバーリード（CVE-2026-42946）や、ssl_ocsp使用時のDNS応答処理のuse-after-free（CVE-2026-40701）など、本件を含む計6件が直っています。

自社のnginxが影響を受けるかの判定手順

影響を受けるOSS版・NGINX Plus・F5派生製品の対応表

CVEレコードは、技術サポート終了（EoTS）の版を評価対象外としています。発見者のREADMEはR35 P2も修正版に挙げていますが、NGINX Plusのリリース履歴ではR35 P2の公開は2026年3月24日で、開示より前です。R35系を使っている場合は、修正版と読まずにR36 P4かR37へ移ってください。nginxを組み込んだF5製品も対象で、depthfirstはNGINX Ingress Controller 3.5.0〜3.7.2・4.0.0〜4.0.1・5.0.0〜5.4.1、NGINX Gateway Fabric 1.3.0〜1.6.2と2.0.0〜2.5.1、NGINX Instance Manager 2.16.0〜2.21.1などを挙げています。Ingress Controllerの影響範囲は連続していないため、版番号の大小だけで判定しないでください。これらの修正版はF5のK000161019で確認します。

nginx -Tによるrewrite・set・ifの候補抽出と目視確認

CVEレコードが示す成立条件は、置換先に「?」を含むrewriteのあとに、無名キャプチャ（$1や$2）を参照するrewrite・if・setが続くことです。発見者の解説にある例でも、置換先は「?」を含む固定の文字列で、$1を参照しているのは次の行のsetでした。「?」と$1が同じrewriteの中にそろっていなくても該当します。

includeで分割された設定まで漏れなく見るため、ファイルを個別に開かずnginx -Tの展開結果を検索します。設定に構文エラーがあると、nginx -Tは標準エラー出力に診断を出すだけで、標準出力には設定本文を出しません。nginx:1.30.6のコンテナに構文エラーのある設定を読ませると、nginx -tは終了コード1、nginx -Tの標準出力は0行でした。そこで次の内容をシェルスクリプトとして保存して実行し、nginx -tが失敗したらその場で止めます。

#!/bin/sh
# nginx -t が失敗したら終了コード1で止める（-T の出力が空になり、検索結果を信用できないため）
nginx -t || { echo "nginx -t が失敗。設定エラーを直してから再実行" >&2; exit 1; }

echo "--- [A] 置換先（第2引数）に ? を含む rewrite"
nginx -T 2>/dev/null | grep -nE 'rewrite[[:space:]]+[^[:space:]]+[[:space:]]+"?[^[:space:];"]*\?'

echo '--- [B] 無名キャプチャ $1〜$9 を参照する rewrite・if・set'
nginx -T 2>/dev/null | grep -nE '(rewrite|if|set)[[:space:]][^;]*\$[1-9]'

echo "--- [C] 同じ行で ; が閉じない rewrite（複数行に分かれた設定）"
nginx -T 2>/dev/null | grep -nE 'rewrite[[:space:]][^;]*$'

出力は候補の一覧で、該当の判定ではありません。[A]に出た行と同じlocation（またはserver）の中で、その後ろに[B]の行が続いていれば要確認です。rewriteモジュールの仕様では、rewriteにlastやbreakが付いていると、そのあとのrewriteモジュールのディレクティブは処理されません。フラグの有無と実際の処理順を読み、後続の行まで処理が進む構成なら、設定を直すか更新を急ぎます。[C]に出た行は引数が複数行に分かれているため、[A]では拾えません。前後を目で読んでください。

nginx:1.30.6と1.30.6-alpineのコンテナで、4種類のlocationを含む設定に通して試しました。[A]は置換先に「?」を含む2行を出し、[B]は$1を参照する3行を出しました。[A]と[B]の両方に出たのはrewrite ^/a/(.*)$ /index.php?from=a; set $orig $1;の1行です。名前付きキャプチャ（$p）だけを使う行は[B]に出ず、正規表現側にだけ「?」があるrewrite ^/d/(.*)?$ /plain/$1;は[A]に出ません。置換先を改行で次の行に送った設定は[A]から漏れ、[C]で拾えました。正規表現を引用符で囲み、その中に空白を含む設定も[A]から漏れます。検索結果が0行でも安全とは判定できないため、最終的にはrewriteを含むlocationを1つずつ読んでください。同じ1.30.1で直った5件や後続のCVEは別の条件で発火するため、設定が該当しなくても更新は必要です。

RHEL・Debian・Ubuntu・Amazon Linuxのパッケージ版による修正確認

ディストリビューションは修正を上流の1.30系へ追随させず、既存の1.18・1.20・1.22・1.24系へバックポートしています。修正済みでもnginx -vは古い版番号のままなので、上流の版番号では判定できません。主な判定は、配布元のアドバイザリが示す修正版と、インストール済みパッケージの完全な版番号の照合です。changelogのCVE番号は、どの修正が入ったかを確かめる補助に使います。

# RHEL・AlmaLinux・Rocky Linux（RPM系）
rpm -q nginx
rpm -q --changelog nginx | grep -oE 'CVE-2026-[0-9]+' | sort -u

# Debian・Ubuntu
dpkg-query -W nginx
zgrep -ohE 'CVE-2026-[0-9]+' /usr/share/doc/nginx/changelog.Debian.gz | sort -u

2026年10月18日に各ディストリの公式コンテナへnginxを入れて実行した結果です。

3つのディストリとも、changelogにCVE-2026-42945・9256・42055・42533・60005が並んでいました。一方で、10月14日に上流で直った5件（CVE-2026-15176など）は、この時点ではどのchangelogにもありません。Amazon Linux 2023も1.30.5のままです。Ubuntuの修正版はUbuntuのCVEページで、22.04が1.18.0-6ubuntu14.11、26.04が1.28.3-2ubuntu1.1です。20.04以前はUSN-8375-1のESM版で直っています。Debian 11はDebianのセキュリティトラッカーでDLA-4589-1（1.18.0-6.1+deb11u6）、Debian 13はDSA-6278-1（1.26.3-3+deb13u5）です。RHEL 9.8系はRHSA-2026:19374（1.20.1-28.el9_8.2）で本件が直り、その後CVE-2026-9256（RHSA-2026:28973）とCVE-2026-42055（RHSA-2026:36331）が同じ1.20.1系に入りました。Amazon LinuxはALASのCVEページで対応するアドバイザリを確認します。パッケージを更新したらsystemctl restart nginxで再起動します。nginx -s reload（HUP）では設定は読み直されてもバイナリは入れ替わりません。

ASLRの状態で分かれるRCEとDoSの判定

randomize_va_spaceとプロセス単位のpersonalityの確認

CVEレコードは、本件の結果をワーカープロセスの再起動と定義し、コード実行はASLRが無効か攻撃者がASLRを回避できる場合に限るとしています。まずカーネル全体の設定を読みます。

# 2 が完全なランダム化、1 が部分的、0 が無効
cat /proc/sys/kernel/randomize_va_space

# nginx の master の ADDR_NO_RANDOMIZE（0x0040000）ビットを確認（このビットが立っていれば無効・root 権限が必要）
sudo cat /proc/$(cat /run/nginx.pid)/personality

カーネル全体の値が2でも、プロセス単位でASLRを切ることはできます。personalityファイルは所有者がrootで読み取りにも権限が要り、既定設定のDockerコンテナ内ではrootでも「Operation not permitted」になりました。特権を付けて起動したnginx:1.30.6のコンテナで確かめると、randomize_va_spaceはどちらも2を返しましたが、通常起動のmasterプロセスのpersonalityは00000000、setarch -R経由で起動すると00040000（ADDR_NO_RANDOMIZE）で、ワーカーにも引き継がれました。後者のmasterプロセスでは、この環境でヒープの開始アドレスが0x5555557be000と記録されました。ASLRが効かない状態の典型的な配置です。起動スクリプトやデバッグ用のラッパーにsetarchが紛れていないかは、sysctlではなくこの値で確かめます。コンテナ内で読むrandomize_va_spaceはホストのカーネル設定がそのまま返るため、ノード側の値も見てください。なお既定のseccompプロファイルのDockerコンテナではsetarch -R自体が「Operation not permitted」で失敗しました。

ASLR有効でも残るワーカー異常終了の実害と検知

RCEが成立しなくても、サービスへの影響は残ります。ワーカープロセスが異常終了するとmasterプロセスが新しいワーカーを起動しますが、そのワーカーが抱えていた接続はすべて切れます。攻撃が自動化されれば異常終了が繰り返され、リクエストの失敗とレイテンシの悪化が続きます。error.logにはworker process 1234 exited on signal 11の形でmasterの記録が残るので、grep 'exited on signal' /var/log/nginx/error.logを監視に入れておくと、更新前の異常終了を調べる手掛かりになります。ただし、このログだけで本CVEによる被害の有無は確定できません。ASLRが有効でも更新は必要です。

公開PoCの中身と悪用状況

DepthFirstDisclosures/Nginx-Riftのリポジトリ構成とASLR無効の再現環境

PoCはGitHubのDepthFirstDisclosures/Nginx-Riftで公開されています。Nginx-Riftディレクトリにはpoc.pyとDocker Composeの再現環境があり、setup.shの案内には、サーバー側のnginxをsetarch -RでASLR無効にして動かすと明記されています。2026年7月25日（UTC）のコミットで、Ubuntuのベースイメージ・パッケージのスナップショット・nginxのソースリビジョンが固定され、再現性が高められました。つまり公開PoCが示すコード実行は、ASLRが切れた環境での実証です。同じコミットで、mapと正規表現のCVE-2026-42533のPoCも追加されています。こちらはstreamモジュールのssl_prereadを使う構成で、起動スクリプトにsetarch -Rはなく、再現環境に情報漏えい用のエンドポイント（29445番ポート）があります。ASLRだけで守れると考えないでください。CVE-2026-42530のディレクトリはreport.mdの解説だけで、攻撃コードはありません。

GitHubには、発見者のリポジトリとは別に、第三者が作ったスキャナーや検出スクリプトもあります。発見者の公式リポジトリ（DepthFirstDisclosures）かどうかを確かめ、第三者のものは実行する前に対象のCVEと処理内容をソースで確認してください。学習目的なら、TryHackMeがCVE-2026-42945: Nginx Riftという演習ルームを用意しています。いずれも本番や他者のサーバーには向けず、隔離した検証環境で使ってください。

VulnCheckの悪用試行観測とEPSS・KEVの読み方

Help Net Securityの5月18日の記事によれば、VulnCheckのPatrick Garrity氏は、開示とPoC公開から3日後の5月16日に自社のカナリアシステムが悪用の試行を検知し始めたとしています。観測の元記録はVulnCheck側では公開されていないため、日付は同記事の報道として読んでください。VulnCheckはインターネットに公開された潜在的な脆弱版を約570万台と見積もる一方、特定のrewrite設定が必要なため実際に攻撃できる台数はずっと少ないとしています。FIRSTのEPSS（今後30日以内に悪用が観測される確率の推定値）は、FIRSTのAPIの日次データで、9月23日の0.680から9月24日に0.034へ下がり、10月16日時点でも0.034（88.7パーセンタイル）です。値が下がった理由は公表されておらず、修正不要を意味しません。CISA KEVは、公式JSONの10月16日版（catalogVersion 2026.10.16）で、本件を含めnginxのCVEを1件も収載していません。KEVは米国連邦機関に是正を義務付ける一覧で、未掲載は悪用ゼロの証明になりません。優先度は、修正が入っていないこと、インターネットから直接またはリバースプロキシ経由で到達できること、設定の目視確認で条件に合ったこと、の3つで決めます。3つとも当てはまるサーバーが最優先です。

1.30.1以降のnginx脆弱性修正と更新先

1.30.1〜1.30.6の修正CVEと更新先

1.30.2で直ったCVE-2026-9256は、同じrewriteモジュールで重なり合うキャプチャを使う設定のヒープオーバーフローで、nginx.orgは影響範囲を0.1.17〜1.31.0としています。経緯はnginxで再発した脆弱性CVE-2026-9256で詳しく扱っています。1.30.3で直ったCVE-2026-42055もv4.0で9.2で、その読み方はnginx 1.30.3が修正したCVE-2026-42055にまとめました。nginx.orgのダウンロードページでは、legacyの1.28系は2026年3月の1.28.3で止まっており、5月以降の修正を含みません。上流版の1.28系以前を直接使っている場合は1.30.6へ更新します。ディストリビューション版は配布元の修正版へ更新します。mainlineの1.31.0と1.31.1にはHTTP/3のCVE-2026-42530もあるため、mainlineを選ぶなら1.31.7です。

aliasとrewriteの組み合わせで起きるCVE-2026-15176

10月14日の1.30.6と1.31.7は、Riftと同じくrewriteが絡むバッファオーバーフローを直しました。CHANGESの説明は、rewriteディレクティブで書き換えたリクエストURIを、aliasディレクティブでファイルパスへ対応づけたときにワーカープロセスでバッファオーバーフローが起きうる、というものです。nginx.orgの区分はmediumで、影響範囲は0.1.29〜1.31.6と広く、1.30.1〜1.30.5へ更新済みのサーバーも含みます。同時に、変数を含む文字列式の評価でのバッファオーバーフロー（CVE-2026-93479、安定版1.30.0〜1.30.5とmainline 1.31.2〜1.31.6）、HTTP/3のリクエストボディ注入（CVE-2026-95101）、TLSセッションチケット鍵ローテーション時のセッション偽造（CVE-2026-97629）、AIOとSSIのuse-after-free（CVE-2026-97205）も直っています。Riftの点検でnginx -Tを読むときに、rewriteとaliasが同じlocationにある箇所も控えておくと、パッケージの修正を待つ間の優先度付けに使えます。

即時更新できない場合の名前付きキャプチャへの書き換え

更新を待つ間の回避策は、成立条件のうち「無名キャプチャの参照」をなくすことです。置換先の「?」のあとに続くset・if・rewriteで使っている$1や$2も、すべて名前付きキャプチャの参照に置き換えます。無名キャプチャを名前付きキャプチャに置き換える方法は、Red HatがCVE-2026-9256の緩和策として例示している書き方と同じです。

# 変更前（置換先に ? があり、後続の set が無名キャプチャ $1 を参照）
rewrite ^/item/(.*)$ /index.php?from=item;
set $orig_path $1;

# 変更後（キャプチャに名前を付け、後続の set もその名前で参照する）
rewrite ^/item/(?<item_path>.*)$ /index.php?from=item;
set $orig_path $item_path;

書き換えたら、前の章のスクリプトで[B]にその行が出なくなったことと、同じlocationに$1〜$9の参照が残っていないことを目で確かめます。書き換えはURLの変換結果を変えうるため、リダイレクト先とクエリ文字列の受け渡しを検証環境で確かめてから適用します。前段のWAFで不審なリクエストを落とす方法も併用できますが、攻撃はrewriteの評価中に成立するため、シグネチャ頼みの遮断は補助と考えてください。WAFの守備範囲はWAFの仕組みとIPS・IDSとの違いで整理しています。緩和策は恒久対応の期限を決めたうえで入れます。nginxを含むWebサーバー群の設定とパッケージを横断して点検したい場合は、一創の脆弱性診断・セキュリティ診断でも承っています。

よくある質問

NGINX Rift（CVE-2026-42945）の判定と対応について、よくある疑問を整理します。

PoCコードはどこで公開されていますか？

発見者のdepthfirstが、GitHubのDepthFirstDisclosures/Nginx-Riftリポジトリで公開しています。同じリポジトリにはCVE-2026-42533のPoCとCVE-2026-42530の解説もあります。再現環境はASLRを切ってnginxを動かす前提なので、更新権限のある隔離環境での確認にとどめてください。

ASLRが有効ならアップデートしなくても安全ですか？

安全ではありません。ASLRで下がるのはコード実行のリスクだけで、条件に合う設定があれば、ASLRの状態にかかわらずワーカープロセスを異常終了させるDoSは起こりえます。ASLRを回避された場合のコード実行も、CVEレコードは否定していません。カーネル全体の値が2でも、プロセス単位でASLRが切られていることがあるため、nginxのmasterプロセスのpersonalityも確かめます。

rewriteディレクティブを使っていなければ影響はありませんか？

CVE-2026-42945に限れば、置換先に「?」を含むrewriteと、その後で無名キャプチャを参照するrewrite・if・setの組み合わせがなければ成立しません。ただし同じ1.30.1ではscgi・uwsgiやssl_ocspなど別経路の5件も直っており、その後も1.30.6まで修正が続いているため、更新自体は必要です。

NGINX Plusはどの版に上げればよいですか？

CVEレコードの修正版はR32 P6とR36 P4で、R37は影響を受けません。R35 P2は開示前の2026年3月24日に出た版なので、R35系を使っている場合はR36 P4以降かR37へ移ります。NGINX Ingress ControllerやNGINX Gateway FabricなどのF5製品は、F5のK000161019で製品ごとの修正版を確認してください。

Kubernetesのingress-nginxにも修正は提供されますか？

Kubernetesプロジェクトからは提供されません。Kubernetes公式ブログは、ingress-nginxを2026年3月で退役させ、以後はリリースもセキュリティ修正も行わないと告知しています。HeroDevsが最終版v1.15.1をもとにした有償の延長サポートを出していますが、移行までのつなぎと考えてください。選択肢は退役したingress-nginxとF5版の違い・移行判断にまとめています。

関連記事

• nginxで再発した脆弱性CVE-2026-9256：概要と影響範囲・2026年の修正経緯
• nginx 1.30.3の脆弱性修正：CVE-2026-42055のCVSS v4.0スコア9.2の読み方と更新先
• nginxの最新バージョンは1.31系（安定版1.30）｜確認方法・更新手順と変更点【2026年10月】
• NGINX Ingressとは？退役したingress-nginxとF5版の違い・移行判断
• CVSSv3とは？v3.1の計算式・スコアの目安と3つの評価基準を解説