何が起きたか・対象

Ingress NGINXはKubernetesへの通信を振り分けるコントローラーです。Ingress設定の追加前に内容を確認するAdmission Controllerへ送られた値を、NGINX設定へ埋め込む処理と、その設定の検査中にコードを実行できる問題群が報告されました。識別子はCVE-2025-1974、1097、1098、24514です。

Podは、コンテナをまとめて動かすKubernetesの実行単位です。この研究では、HTTP通信を受けるNGINXとAdmission Controller、検査用のnginx -tが同じコントローラーのPodで動きます。攻撃者はNGINXへのHTTP要求の本文として、実行用コードを含む共有ライブラリを送り、一時ファイルへ保存させます。続いてAdmissionへ、そのファイルを参照するssl_engine命令を含む検査要求を送ります。nginx -tが設定を読むとライブラリをロードし、その初期化処理がPod内で動きます。

Podのプロセスが使うKubernetes APIの認証情報を、動いたコードも読める構成では、その認証情報でAPIへ接続できます。PodのサービスアカウントにSecretの読取権限があり、DBパスワードなどを含むSecretを取得して外部送信できれば、攻撃者が秘密を入手するおそれがあります。Admissionへの到達、一時ファイルの保存・参照、実際のAPI権限が条件です。公開サーバーの発見数を侵害成功数とは扱いません。

報告・修正・公開の時系列

Wizは2024-12-31から報告し、途中の仮修正への迂回も伝えています。2025-03-24に研究が公開され、1.12.1と1.11.5が初回の修正リリースとして案内されました。現在の利用判断ではサポート状況も別途確認します。

正常ならどう動くはずだったか

Admission Controllerは、Kubernetesへ追加するIngress設定を事前に確認します。検査用のリクエストに含まれるアノテーションやUIDは、設定の値として扱う必要があります。NGINXの設定を生成して検査しても、その値で任意の命令を追加したり、検査用プロセスへ任意のライブラリを読み込ませたりしてはいけません。 アノテーションは認証先URLなどIngressの追加設定、UIDはオブジェクトの識別子です。コントローラーがNGINX向け設定を作るために使っても、これらの文字列を新しい命令として解釈させてはいけません。

技術的な原因

検査用リクエストのIngressのアノテーションやUIDをNGINX設定へ埋め込む処理に、区切りを閉じて別の命令を追加できる箇所がありました。生成した設定をnginx -tへ渡すと、検査中にも設定内の機能が動きます。研究ではssl_engineで共有ライブラリを指定し、ライブラリのコードをコントローラーのPod内で実行しています。CVE-2025-1974はこの検証経路に関係します。

auth-urlの例では、認証先URLをset $target URL;という設定へ埋め込みます。正常ならURL一つですが、入力にセミコロンと改行を入れて設定が別の行へ続くと、その行を新しいNGINX命令として読ませられる場合があります。URLの値として受けたものが、生成後には命令の構造になることが注入の境目です。対象版や他のアノテーションによって、使える注入経路は異なります。

攻撃が成立する条件と流れ

攻撃者はHTTP通信を受けるNGINXへ、共有ライブラリの内容を本文に入れた要求を送ります。NGINXが本文を一時ファイルへ保存し、ファイル名を削除した後でも、そのプロセスがファイルを開いている間は内容が保持されます。Linuxの/procはプロセスの情報をファイルの形で参照する仕組みで、PIDと開いたファイルの番号に対応するパスから、その内容に届く場合があります。

研究では、本文を受信し終わるまでNGINXが待つ状態を利用して参照を保ちます。攻撃者はその/proc上のパスをssl_engineの参照先として、別のAdmissionReview要求をAdmission Controllerへ送ります。生成した設定をnginx -tが検査すると、保存済みの内容を共有ライブラリとしてロードし、初期化コードが動きます。要求の宛先二つへ接続でき、同じPodから一時内容を参照できることが必要です。

確認された事実と、想定される影響

コードが動く場所はコントローラーのPodです。そのPodが使うサービスアカウントの認証情報でKubernetes APIへ接続し、許可されたSecretを読み取れるおそれがあります。SecretにDBパスワードなどが入り、その値を攻撃者のサーバーへ送信できれば、攻撃者はクラスター内の秘密を入手します。

他の名前空間のSecretまで読めるかはサービスアカウントの実際の権限に依存します。取得した資格情報を別の接続へ再利用できるかも、その権限と接続条件によります。公開されていたサーバーの発見数は侵害成功数ではなく、研究の到達可能性から実被害件数を推定しません。

実際の修正・対応方針

Wizの時系列では、注入箇所への対応と、AdmissionからNGINX設定検証を除く対応が示されています。一般策の入力検証だけで修正全体を説明せず、これらを含む修正済み構成へ更新する必要があります。

利用者・運用者が確認すること

利用版、Admissionへの接続範囲、サービスアカウントが読めるSecretを確認します。修正済み構成へ更新し、Admissionへの不要な接続を制限して、疑わしい要求やプロセス、資格情報の使用を調べます。

開発者への教訓（教材としての考察）

「検査用だから実害がない」とは限りません。検査器が設定を実際に読み込むなら、その段階で使う機能と権限も、実行処理と同じように評価する必要があります。

出典・確認範囲

  1. [1] IngressNightmare: CVE-2025-1974Wiz Research / 確認日 2026-10-29
未確認事項・限界

参照資料では実悪用や実際の被害件数を確認できません。未記載の実装差分は推測していません。