【緊急】nginxに18年潜伏した重大脆弱性CVE-2026-42945｜世界Webサイト約3割でRCE可能性、管理者がいま確認すべきこと

「うちのWebサイトはnginxで動いている。今回の18年バグ、本当に影響あるのか」 — 2026年5月13日にF5とdepthfirstが調整公表したNGINX Rift（CVE-2026-42945）は、まさにこの一言で問い合わせが殺到している脆弱性です。

nginxは世界Webサーバーシェアで約3割を占めるソフトウェア。今回の問題は2008年から18年間、書き換え（rewrite）モジュールに潜伏していたヒープバッファオーバーフローで、CVSS v4.0は9.2（Critical）。条件次第で未認証のリモートコード実行に至る可能性が報告されました。

この記事では、CVE-2026-42945について以下を整理します。
・一次情報の正確な範囲（影響バージョン・CVSS・パッチ）
・自分のサーバーが脆弱な構成かを判定するコマンド手順
・パッチ即適用が難しい場合の暫定回避策
・情シス・インフラ担当が今日中に着手すべきアクション

不安を煽る記事ではありません。「正しく知って、正しく備える」ための実務ガイドとして読んでください。

CVE-2026-42945（NGINX Rift）の全体像

まず一次情報を整理します。本記事の数値は2026年5月16日時点でNVD・F5・nginx.org・depthfirstの公式情報を突合して確認したものです。

注目すべきはCVSSが評価機関で割れている点です。F5・NVDの9.2はv4.0スコアリングで「攻撃前提条件あり（AC:H）でも影響が深刻」と評価していますが、nginx公式アドバイザリはmedium表記。本記事はNVD/F5の評価を採用しつつ、「悪用には特定の設定パターンが必要」という事実を分けて扱います。

18年潜伏した理由 — AI解析が掘り当てた構造

この脆弱性は2008年（nginx 0.6.27）から書き換えモジュールに存在していました。発見したdepthfirstは、自律型の脆弱性解析システムをnginxソースコードに適用。約6時間で本件を含む4件のメモリ破壊系欠陥（CVE-2026-42945 / 42946 / 40701 / 42934）を一気にフラグした、と公式発表しています。

人手のコードレビューでは捕まらなかった理由は、後述する「3条件のすべてが揃ったときに初めて発火する」発動パターンの組み合わせ爆発にあります。攻撃面の網羅性を求める静的解析と、AIによるパス追跡型の解析を組み合わせた成果と言えます。

攻撃の仕組み — 何が起きると危ないのか

「nginxを使っている＝全員RCE可能」ではありません。発動条件は厳密です。攻撃者目線で何が成立すれば刺さるのかを、防御目的で正確に押さえておきます。

発動する3条件

以下の3つが同一スコープ内で揃ったときだけ、ヒープオーバーフローが成立します。

・条件1: rewriteディレクティブで名前なしPCREキャプチャを使用（$1、$2など）
・条件2: 置換文字列に疑問符（?）が含まれる
・条件3: 同じスコープ内で後続するrewrite / if / setディレクティブが存在

たとえば次のような書き換えルールが典型的に該当します。

# 脆弱なパターン例（説明目的・実環境投入禁止）
location /old/ {
    rewrite ^/old/(.*)$ /new/$1?archived=1 last;
    set $debug "on";
}

$1（名前なしキャプチャ）+ ? を含む置換 + 後続set、の3点が揃っています。実際の本番環境でも、レガシーURL救済・サードパーティCMS設定・キャッシュサーバー前段の設定例などで頻出する書き方です。

メカニズム — サイズ計算と書き込みのズレ

技術的には、nginxの内部処理で「バッファサイズを計算するパス」と「実際に書き込むパス」が同じ文字列に対して別々のエンコード長を使っていた、という不整合が原因です。

・サイズ計算時: エスケープ前のURI長で必要サイズを算出
・書き込み時: エスケープ後（+ や & などを含む）の大きいデータを実際に書き込み

このとき is_args フラグが残り続けることで、確保バッファより大きい文字列がヒープに溢れ出します。攻撃者がURIのエスケープ要素をコントロールできれば、隣接ヒープ領域に悪意あるデータを書ける可能性があり、ASLRが無効な環境ではコード実行までつながると報告されています。

実害シナリオ

悪用が成立した場合の現実的な被害イメージは次のとおりです。

・worker プロセスのクラッシュ: 一番起きやすい。nginxはmaster + 複数workerで動く構造のため、攻撃が繰り返されるとworkerが落ち続けてサービスが断続的に止まる
・DoSの常態化: 同じリクエストを送り続けるだけでサイト不可用に追い込める
・RCE: ASLR無効・特定のメモリレイアウト条件下で、ヒープ操作からのコード実行に成功する可能性。depthfirstはPoCとパッチ解析を公開済み

自分のサーバーが該当するか — 5分で判定する手順

ここからは現場の作業手順です。順番に実行すれば「自分のサーバーが脆弱な構成かどうか」をその場で切り分けられます。

1. nginxバージョンを確認

まずインストールされているnginxのバージョンを確認します。

# nginxバージョン確認
nginx -v
# 出力例: nginx version: nginx/1.24.0

# rewriteモジュールが含まれているか確認
nginx -V 2>&1 | tr ' ' '\n' | grep -E 'rewrite|pcre'

0.6.27～1.30.0の範囲にあれば、コードベース上は脆弱なバージョンです。1.30.1または1.31.0以上であれば修正済み。NGINX Plus環境はR32 P6 / R36 P4以上か確認します。

2. 脆弱なrewriteパターンを設定ファイル横断で検索

「3条件揃いかどうか」を機械的に洗うgrepコマンドです。条件1（名前なしキャプチャ）と条件2（?を含む置換）を同時に持つ行を一次抽出します。

# 設定ディレクトリを再帰検索（パスは環境に合わせて変更）
grep -RnE 'rewrite\s+.*\$[0-9].*\?' /etc/nginx/

# include先のconf.dも忘れずに
grep -RnE 'rewrite\s+.*\$[0-9].*\?' /etc/nginx/conf.d/ /etc/nginx/sites-enabled/

ヒットした行があれば、同じlocation / serverブロック内に rewrite / if / set が後続していないか目視確認します。3条件すべて揃っていれば「該当構成」確定です。

3. ロードバランサー・WAFの前段確認

nginx本体が脆弱版でも、前段にWAFやリバースプロキシがある場合は、不正リクエストが届く前に弾けるかを確認します。F5公式は「rewrite発動前の段階で問題リクエストを遮断するWAFルール」を関連製品（NGINX App Protect等）向けに提供しています。

4. ログでの攻撃兆候監視

workerプロセスのクラッシュは error.log に明確に残ります。次のパターンを監視してください。

・シグナル系: worker process exited on signal 11（SIGSEGV）
・再起動の連鎖: 短時間に複数回のworker process restart
・異常URL: $1 / ?を含む長大なクエリ文字列が同一IPから連続到着

パッチ適用と暫定回避策 — Before / After

判定で「該当」となった場合の対応を、優先度順に整理します。

最優先: パッチ適用

nginx Open SourceなのかNGINX Plusなのかで適用先が分かれます。主要環境別の修正バージョンは次のとおりです。

Debian / Ubuntu / RHEL / Amazon Linux等もディストロ側の修正パッケージが順次出ています。`apt update && apt upgrade nginx` あるいは `dnf update nginx` で取得し、`systemctl reload nginx` で適用後、`nginx -v` でバージョンを再確認します。

パッチが今すぐ当てられない場合の暫定回避策

商用サービスでメンテナンス窓を取れない状況もあります。その場合、3条件のうち1つを設定変更で外せば、ヒープオーバーフローは発火しなくなります。AlmaLinuxの公式ブログとF5アドバイザリで明示されている回避手段です。

・回避1（推奨）: 名前なしキャプチャを名前付きキャプチャに置換
・回避2: 置換文字列から ? を削除
・回避3: 同スコープ内の後続 rewrite / if / set を別ブロックへ分離

Before / After の典型例を示します。

# Before（脆弱）
location /old/ {
    rewrite ^/old/(.*)$ /new/$1?archived=1 last;
    set $debug "on";
}

# After（回避1: 名前付きキャプチャ化）
location /old/ {
    rewrite ^/old/(?<tail>.*)$ /new/$tail?archived=1 last;
    set $debug "on";
}

正規表現を `(?<name>…)` 形式に変えるだけで、脆弱な内部パスを通らなくなります。書き換え後の動作は同一なので、後方互換性も維持できます。

緊急時の応急処置

「設定改修も今すぐ難しい」緊急ケースでは、次の応急策が現実的です。

・該当locationを一時的にコメントアウト: 影響範囲が限定的なら、脆弱なrewrite行を無効化してサービス継続
・前段のWAF / CDNでURLパターン遮断: ?と$1のような連結を含む異常URLをルールで止める
・nginx workerプロセスの自動再起動監視: 万一クラッシュしてもサービス断時間を最小化する設定（worker_processes と worker_connections の見直し）

情シス・インフラ担当の今週やることチェックリスト

本日中～今週中で動くべきタスクを、優先度順にまとめます。中小企業の情シスで人手が足りない環境を想定しています。

・本日中（Day 0）
　・社内・関連先で稼働中のnginxサーバーをすべて棚卸し（本番・ステージング・社内ツール・コンテナイメージ）
　・各サーバーで `nginx -v` を実行しバージョンを記録
　・該当バージョン（0.6.27～1.30.0）の有無を一覧化
　・error.log の過去24時間分を確認し、worker プロセスのクラッシュ痕跡がないか目視

・2～3日以内（Day 1-3）
　・該当バージョンのサーバーでrewrite設定をgrep検索（前述コマンド）
　・3条件揃いの設定があれば、回避策（名前付きキャプチャ化）を反映
　・パッチ適用スケジュールを調整（メンテ窓・告知・ロールバック手順）

・1週間以内（Day 4-7）
　・修正バージョンへアップグレード（1.30.1 / 1.31.0 / NGINX Plus R32 P6 / R36 P4）
　・パッチ後の `nginx -v` 再確認＋設定の正常性テスト（`nginx -t`）
　・WAF / CDN側のシグネチャ更新確認
　・社内に「対応完了報告」を共有し、再発防止のためrewrite設定レビュー手順を運用に組み込み

よくある誤解と注意点（FAQ）

問い合わせで多い疑問を、現場目線で整理します。

Q1: nginxを使っているサイトはすべてRCE可能なのか？

違います。RCEどころかDoSすら、3条件揃いの脆弱なrewrite構成が必要です。世界Webサーバーシェアの約3割がnginxという統計はそのとおりですが、それが即RCE可能率ではありません。本記事のgrepコマンドで実構成を確認してください。

Q2: ASLRが有効ならRCEは絶対起きない？

ASLR有効環境ではRCEは困難になりますが、DoS（worker プロセスのクラッシュ）はASLR有無に関係なく成立します。worker落ちの連鎖でサービス断は十分発生し得るため、「ASLR有効＝放置可」とは判断しないでください。

Q3: NGINX Plusだから自動でパッチ適用される？

NGINX Plusでも、サポート契約と契約者側のアップグレード作業は別物です。R32 P6 / R36 P4 へのアップグレード手順をF5のサポートポータルで確認し、メンテ窓を取って適用します。

Q4: CVSSがnginx公式はmediumなのに、なぜCriticalと報道されている？

F5・NVDがCVSS v4.0で9.2（Critical）を割り当てている一方、nginx.org公式はmedium表記です。これは「攻撃前提条件（AC:H）を重く見るか、影響の深刻度を重く見るか」のスコアリング解釈の違いに由来します。実務上はNVD/F5の高めの評価を採用しつつ、自社構成が3条件揃いかで具体的な対応優先度を判断するのが妥当です。

Q5: 関連製品（NGINX Ingress Controller等）は別途対応が必要？

必要です。NGINX Instance Manager・NGINX App Protect WAF/DoS・NGINX Gateway Fabric・NGINX Ingress Controllerも影響範囲に含まれます。Kubernetes環境のIngress ControllerはYAMLマニフェストでのバージョン管理になるため、Helmチャート/イメージタグの更新と再デプロイが必要です。

Q6: PoCが公開されているということは、すぐに攻撃が始まる？

depthfirstがGitHubでPoCとパッチ解析を公開しています。スキャナーへの組み込みは早ければ数日で進むため、「公開週内に修正完了」を目標に動くのが安全です。脆弱性情報の公開直後は、攻撃側のスキャン活動が活発化するのが過去事例の通例です。

Q7: ログを見れば攻撃を受けているか分かる？

典型的にはerror.logの「worker process … exited on signal 11」が複数回出ていれば疑い濃厚です。アクセスログ側で `$1` 系のキャプチャ条件にマッチする長大URL+クエリ文字列が同一IPから連続している場合も警戒対象です。

Q8: JPCERTやJVNから注意喚起は出ている？

2026年5月16日時点で、JPCERT/JVNの個別注意喚起は確認できていません。F5公式アドバイザリ（K000161019）とnginx.orgの security_advisories ページ、NVD（nvd.nist.gov）が一次情報源です。日本語報道はSecurity NEXT、gihyo.jp、GIGAZINEなどが先行しています。

本記事のまとめ

CVE-2026-42945（NGINX Rift）は、18年潜伏していた重大バグであることは事実ですが、「nginxを使っているだけで全員RCE」という話ではありません。本記事の判定手順で自社構成が3条件揃いかを切り分け、該当する場合はパッチ適用または名前付きキャプチャ化で確実に発火を止めれば、騒がず収束できる範囲の脆弱性です。

・影響: nginx 0.6.27～1.30.0 / NGINX Plus R32～R36
・修正: 1.30.1 / 1.31.0、Plus R32 P6 / R36 P4
・発動条件: 名前なしキャプチャ + ? + 後続 rewrite/if/set の3点揃い
・対応の本筋: パッチ適用、難しければ名前付きキャプチャに置換
・監視: error.logでworkerクラッシュの兆候を継続観測

「攻撃者の視点から守る」というのが、セキュリティマスターズ.TOKYOで一貫しているスタンスです。脆弱性の構造を理解し、自分のサーバーに照らして判定する力を持っておくと、次に別の重大バグが出てきたときも同じ手順で冷静に対応できます。

クラウド側のWAF・IAM設定に踏み込んだ防御は姉妹サイトCloudMasters.TOKYO、Linuxサーバー側の権限管理・SELinuxの掘り下げはLinuxMaster.JPで詳しく解説しています。

あわせて読みたい本