CVE-2026-42926 NGINX HTTP/2 フレームインジェクションラボ

CVE-2026-42926 に関連する挙動を検証・比較するための、管理されたサイバーセキュリティラボです。この問題は、脆弱なプロキシ構成が使用されている場合に特定の NGINX バージョンへ影響する HTTP/2 フレームインジェクション です。

このリポジトリは、防御的研究、パッチ検証、構成監査、および管理されたラボ環境での再現のみ を目的としています。

分類: HTTP/2 フレームインジェクション 影響を受けるバージョン: NGINX 1.29.4 〜 1.30.0 修正済みバージョン: NGINX 1.30.1+ / 1.31.0+

安全上の注意

このプロジェクトは、自分が所有している、またはテストを明示的に許可されている隔離されたラボ環境でのみ使用してください。

書面による許可なしに、第三者システム、公共インフラ、共有環境、または本番サービスに対して実行しないでください。

推奨される隔離環境:

• ローカル VM
• 使い捨てコンテナ
• プライベートテストホスト
• ルーティング不可のラボネットワーク

このラボの機能

このラボは、対象の NGINX バイナリと構成が問題を再現するために必要な条件を満たしているかを確認し、テスト用ロケーションに細工したリクエストを送信し、管理されたアップストリームロガーを調べて、インジェクションされた HTTP/2 フレーム状のバイトがアップストリーム側に到達したエビデンスを確認します。

標準的な検証パターンは次のとおりです:

1. 脆弱な NGINX ビルドで同じ脆弱なプロキシ構成を実行する。
2. パッチ済み NGINX ビルドで同じ脆弱なプロキシ構成を実行する。
3. アップストリームのエビデンスとスクリプトの判定結果を比較する。

期待される結果:

• 脆弱なビルド: インジェクションのエビデンスが観測される可能性があります。
• パッチ済みビルド: インジェクションのエビデンスは観測されないはずです。

リポジトリの内容

要件

• Linux または macOS のシェル環境
• bash
• python3
• php
• PHP cURL 拡張機能
• 比較したいバージョンの NGINX テストバイナリ
• 設定された NGINX のリッスンポートをバインドする権限

コンテナ化ワークフローの場合:

• Docker
• Docker Compose v2

サンプル構成はポート 80 でリッスンしますが、これには通常 root 権限が必要です。非特権のローカルラボでは、nginx_vulnerable.conf の listen 80; を 8080 などの利用可能なハイポートに変更し、PHP コマンドで対応するターゲット URL を使用してください。

セットアップ

シェルスクリプトを実行可能にします:

chmod +x nginx_config_verify.sh run_lab_comparison.sh

PHP に cURL サポートがあることを確認します:

php -m | grep -i curl

各 NGINX バイナリがバージョンを出力できることを確認します:

/path/to/nginx -V

ラボ構成

提供されている nginx_vulnerable.conf には、必要なテストパターンが含まれています:

location /exploit {
    proxy_pass http://127.0.0.1:8081;
    proxy_http_version 2;
    proxy_set_body $request_body;
    proxy_set_header Host $host;
    proxy_set_header Content-Length $content_length;
}

重要な詳細:

• proxy_http_version 2 は、アップストリームロガーへの HTTP/2 プロキシを有効にします。
• proxy_set_body $request_body は、クライアントが制御するリクエストボディを使用します。
• client_max_body_size 20m は、検証スクリプトが使用する細工された 16 MiB のリクエストボディを許可します。
• アップストリームロガーはデフォルトで 127.0.0.1:8081 でリッスンします。

docker/nginx_vulnerable.docker.conf の Docker 専用構成は、同じ脆弱なプロキシパターンを維持しつつ、コンテナポート 8080 でリッスンし、Compose サービス名 upstream:8081 にプロキシします。

Docker クイックスタート: NGINX 1.29.4 ラボ

Dockerfile は NGINX 1.29.4 をソースからビルドし、ラボに必要な PHP/Python ツールをインストールします。次に Compose は同じイメージから 3 つのサービスを実行します:

• upstream: 生の HTTP/2 フレームロガー
• nginx: docker/nginx_vulnerable.docker.conf を使用する脆弱な NGINX 1.29.4
• runner: ワンショットの PHP 検証コマンド

ラボイメージをビルドします:

docker compose build

アップストリームロガーと脆弱な NGINX を起動します:

docker compose up -d upstream nginx

バンドルされている NGINX のバージョンを確認します:

docker compose exec nginx nginx -V

Compose ネットワーク内で検証スクリプトを実行します:

docker compose --profile run run --rm runner

ランナーはコンテナ内で次の引数を使用します:

php /lab/cve_2026_42926_lab.php \
  http://nginx:8080/exploit \
  /lab/upstream_logs \
  /lab/nginx_config_verify.sh \
  /usr/local/nginx/sbin/nginx \
  /lab/docker/nginx_vulnerable.docker.conf \
  /exploit

生成されたアップストリームログは、ホスト上の次のディレクトリに書き込まれます:

./upstream_logs/

NGINX サービスは、次の場所でホストにも公開されます:

http://localhost:8080/version

ラボのコンテナを停止して削除します:

docker compose down

クイックスタート: 単一の検証実行

管理されたアップストリームロガーを起動します:

python3 upstream_frame_logger.py 8081 ./upstream_logs

別のターミナルで、サンプル構成を使用して NGINX を起動します:

/path/to/nginx -c "$PWD/nginx_vulnerable.conf"

検証スクリプトを実行します:

php cve_2026_42926_lab.php \
  http://localhost/exploit \
  ./upstream_logs \
  ./nginx_config_verify.sh \
  /path/to/nginx \
  "$PWD/nginx_vulnerable.conf" \
  /exploit

実行後に NGINX を停止します:

/path/to/nginx -s stop

NGINX を別のポートでリッスンするように変更した場合は、最初の引数を更新してください。例:

php cve_2026_42926_lab.php http://localhost:8080/exploit ./upstream_logs ./nginx_config_verify.sh /path/to/nginx "$PWD/nginx_vulnerable.conf" /exploit

クイックスタート: 脆弱版とパッチ版の比較

2 つの NGINX バイナリへのパスを設定し、比較ハーネスを実行します:

VULNERABLE_NGINX=/usr/local/nginx_1.29.4/sbin/nginx \
PATCHED_NGINX=/usr/local/nginx_1.30.1/sbin/nginx \
bash run_lab_comparison.sh

オプションの構成オーバーライド:

VULNERABLE_NGINX=/path/to/vulnerable/nginx \
PATCHED_NGINX=/path/to/patched/nginx \
VULNERABLE_CONFIG="$PWD/nginx_vulnerable.conf" \
PATCHED_CONFIG="$PWD/nginx_vulnerable.conf" \
bash run_lab_comparison.sh

比較スクリプトは次のものを書き込みます:

• vulnerable_result.txt
• patched_result.txt
• upstream_logs_vulnerable/
• upstream_logs_patched/

手動構成チェック

構成に脆弱なパターンが含まれているかどうかだけを確認したい場合は、nginx_config_verify.sh を直接使用します:

./nginx_config_verify.sh /path/to/nginx "$PWD/nginx_vulnerable.conf" /exploit

ヘルパーは次の項目をチェックします:

• proxy_http_version 2
• 変数を使用した proxy_set_body
• 少なくとも 16 MiB の client_max_body_size

スクリプトの引数

cve_2026_42926_lab.php は位置引数を受け入れます:

php cve_2026_42926_lab.php <target_url> <upstream_log_dir> <config_script> <nginx_binary> <nginx_config> <location> [version_url]

デフォルト値:

判定結果と終了コード

cve_2026_42926_lab.php は次の 3 つのいずれかの判定結果を返します:

陽性エビデンスには、スクリプトが実行マーカー、観測されたアップストリームフレームヘッダー、注入フレームフラグ、および影響を受ける NGINX バージョンを関連付けることが必要です。

出力アーティファクト

アップストリームロガーは、次のような名前の JSON ファイルを書き込みます:

frames_<timestamp>.json

各ログには、解析された HTTP/2 フレームのメタデータ、ペイロードの抜粋、バイトオフセット、インジェクション検出フラグ、および実行相関フィールドが含まれます。

比較ハーネスは、脆弱な実行とパッチ済みの実行で別々のログディレクトリを保存するため、2 つの実行からのエビデンスが混在しません。

トラブルシューティング

PHP スクリプトが構成ヘルパーが実行可能でないと報告した場合は、次のコマンドを実行します:

chmod +x nginx_config_verify.sh

リクエストが 413 Request Entity Too Large を返す場合は、client_max_body_size を少なくとも 16m に増やしてください。サンプル構成では 20m を使用しています。

アップストリームログが作成されない場合は、次のことを確認してください:

• upstream_frame_logger.py が実行されていること。
• NGINX が 127.0.0.1:8081 にプロキシしていること。
• ターゲット URL が設定された NGINX リスナーを指していること。
• リクエストが /exploit ロケーションに到達したこと。

NGINX がポート 80 にバインドできない場合は、ラボ環境で適切な権限で実行するか、構成を 8080 などのハイポートに変更してください。

比較結果が inconclusive の場合は、vulnerable_result.txt、patched_result.txt、および対応するアップストリームログディレクトリを調べて、失敗した前提条件を確認してください。

ライセンス

このプロジェクトは MIT ライセンスの下でライセンスされています。詳細は LICENSE を参照してください。