【CVE-2026-42945】NGINX の18年物ヒープバッファオーバーフロー（NGINX Rift）を解説と対応方法

この記事の概要

（CVSSスコア 9.2・緊急対応が必要です）

NGINXのリライトモジュールに18年前から存在していたヒープバッファオーバーフロー脆弱性（通称 NGINX Rift）が公開され、すでに実攻撃が確認されています。
認証不要・単一HTTPリクエストによるリモートコード実行（RCE）またはサービス拒否（DoS）が可能なため、NGINX を利用しているすべてのインフラ・クラウド環境で早急なパッチ適用が求められます。

この脆弱性について

影響を受けるソフトウェア・バージョン：

• NGINX Open Source 0.6.27 〜 1.30.0
• NGINX Plus R32 〜 R36
• NGINX Instance Manager 2.16.0 〜 2.21.1
• NGINX Gateway Fabric 1.3.0 〜 1.6.2 / 2.0.0 〜 2.5.1
• NGINX Ingress Controller 3.5.0 〜 3.7.2 / 4.0.0 〜 4.0.1 / 5.0.0 〜 5.4.1
• NGINX App Protect WAF 4.9.0 〜 4.16.0 / 5.1.0 〜 5.8.0
• F5 WAF for NGINX 5.9.0 〜 5.12.1
• F5 DoS for NGINX 4.8.0
• NGINX App Protect DoS 4.3.0 〜 4.7.0

原因

今回の脆弱性は、NGINXのリライトモジュール ngx_http_rewrite_module に存在するヒープバッファオーバーフローです。
2008年に導入されてから18年間、発見されずにいた「潜伏型」の脆弱性です。

技術的な発生メカニズム：

NGINXの設定ファイルにおいて、rewrite、if、または set ディレクティブが特定の組み合わせで使われているとき、PCRE（Perl互換正規表現）の無名キャプチャグループ（$1、$2 など）と、?（クエスチョンマーク）を含むリプレイス文字列が組み合わさると、ワーカープロセスのヒープ領域に不正な書き込みが発生します。

問題を引き起こす典型的な設定パターン（脆弱な例）は以下のとおりです。

# 脆弱な設定例
server {
    location /app {
        rewrite ^/app/(.*)$ /index.php?path=$1 break;
        rewrite ^/(.+)$ /$1? last;
    }
}

攻撃者は細工したURIを含む単一のHTTPリクエストを送信することで、ヒープバッファの範囲外にデータを書き込みます。
書き込まれるバイト列は攻撃者のURIから導かれるため、ランダムではなく制御された破壊が可能です。

影響範囲

影響を受ける条件：

脆弱性が成立するには、対象の NGINX 設定に以下の条件が揃っている必要があります。

1. rewriteディレクティブが rewrite・if・set のいずれかのディレクティブと連続して使用されている
2. 無名PCREキャプチャ（$1、$2 等）が使われている
3. リプレイス文字列に ? が含まれている

攻撃成立時のリスク：

この条件が揃ったサーバーに対して、インターネット経由の攻撃者は次の影響を与えられます。

• DoS（サービス拒否）： NGINX ワーカープロセスが継続的にクラッシュ・再起動するループに陥り、サービス全体が利用不能になります。複数リクエストを連続送信することで持続的なダウンを引き起こせます。
• RCE（リモートコード実行）： ASLR（アドレス空間配置のランダム化）が無効化された環境では、攻撃者がヒープのターゲットを制御して任意コードを実行できます。PoC の最新版はASLR回避チェーンも含んでおり、同一ホスト上のLFI/任意ファイル読み取りプリミティブと組み合わせたRCEが可能になっています。

クラウド・コンテナ環境への影響：

NGINX は Kubernetes の Ingress Controller としても広く使われています。
NGINX Ingress Controller も影響を受けるため、コンテナオーケストレーション基盤でも脆弱な設定が存在すれば同様のリスクがあります。
また、F5 WAF や NGINX App Protect などのセキュリティ製品にも影響があるため、防御レイヤーそのものが突破口になりうる点に注意が必要です。

2026年5月16日にはすでに実際の攻撃がhoneypotシステムで観測されており、研究者もPoC（GitHub上で公開済み）の実在を確認しています。

対応策・回避策

推奨対応：パッチ適用（最優先）

対象製品ごとの修正バージョンへのアップグレードが最も確実な対応策です。

NGINX Open Source：

# 現在のバージョン確認
nginx -v

# Ubuntu / Debian 系（公式パッケージリポジトリより）
sudo apt update
sudo apt install --only-upgrade nginx

# RHEL / CentOS / AlmaLinux 系
sudo dnf update nginx

# 修正バージョン
# 1.30.1（stable）または 1.31.0（mainline）以降

NGINX Plus：
– R32 P6 または R36 P4 以降に更新してください。
– F5 カスタマーポータルから最新バージョンを入手し、F5 の公式手順に従ってアップグレードしてください。

NGINX Ingress Controller（Kubernetes環境）：

# Helm を使用している場合
helm repo update
helm upgrade ingress-nginx ingress-nginx/ingress-nginx \
  --namespace ingress-nginx \
  --set controller.image.tag=<修正済みタグ>

# 修正済みバージョン（例：Ingress Controller 3.7.3 以降）
kubectl describe pod -n ingress-nginx | grep Image

暫定回避策（パッチ適用が困難な場合）

即座にパッチを適用できない場合は、設定ファイルの変更によって脆弱なパターンを回避できます。

無名キャプチャを名前付きキャプチャに置き換える：

# 修正前（脆弱）
rewrite ^/app/(.*)$ /index.php?path=$1 break;

# 修正後（安全）
rewrite ^/app/(?P<subpath>.*)$ /index.php?path=${subpath} break;

すべての rewrite ディレクティブで $1、$2 等の無名キャプチャを使っている箇所を (?P<name>...) の名前付きキャプチャに置き換えてください。
変更後は必ず nginx 設定の構文チェックと再読み込みを行います。

# 設定ファイルの構文チェック
sudo nginx -t

# 設定の再読み込み（ダウンタイムなし）
sudo nginx -s reload

確認方法

NGINXのバージョン確認：

# バージョン確認（ビルドオプション含む）
nginx -V 2>&1 | head -5

# プロセス確認
ps aux | grep nginx

脆弱な設定パターンの検索：

# 設定ファイルの場所を確認
nginx -T 2>/dev/null | grep "configuration file"

# 脆弱なパターン（$1/$2 と ? の組み合わせ）を検索
grep -rn "rewrite" /etc/nginx/ | grep -E '\$[0-9].*\?|\?.*\$[0-9]'

# Kubernetes環境：ConfigMapの確認
kubectl get configmap -n ingress-nginx -o yaml | grep -A5 "rewrite"

パッチ適用後の確認：

# バージョンが修正版になっているか確認
nginx -v
# 期待出力例: nginx version: nginx/1.30.1

まとめ

CVE-2026-42945（NGINX Rift）は、18年間潜伏してきた深刻な脆弱性です。
認証不要・単一リクエストでDoSが成立し、条件次第ではRCEにも発展するため、CVSSスコア9.2の緊急評価は妥当です。
PoC公開直後から実攻撃が観測されており、対応を先延ばしにするほどリスクは増していきます。
まずはNGINXのバージョン確認と設定ファイルのrewriteディレクティブのパターン調査を実施し、修正バージョンへのアップグレードを最優先で進めてください。
パッチ適用まで時間がかかる場合は、名前付きキャプチャへの置き換えで暫定回避してください。

参考リンク

• NVD：
• F5 ベンダーアドバイザリ（CVE-2026-42945）
• depthfirst 解析レポート
• AlmaLinux セキュリティアドバイザリ（NGINX Rift）
• The Hacker News 記事