CVE-2025-1974 — IngressNightmare (ingress-nginx)

はじめに

本書では、Kubernetes の ingress-nginx コンポーネント（validating admission controller）に影響を及ぼす脆弱性 CVE-2025-1974 に関する調査を紹介します。
CVE-2025-1974 は CVSS 3.1 9.8 の重大な脆弱性であり、ingress-nginx プロセスのコンテキストでの未認証の Remote Code Execution (RCE) です。攻撃を実行すると、pod ネットワークへのアクセス（または AdmissionReview を validating webhook に届ける手段）を持つ攻撃者が、コントローラーの Pod 内で任意のコードを実行できる可能性があり、その結果、Secrets の漏えいやクラスターの乗っ取りにつながる可能性があります。

Ingress-nginx は Kubernetes で最も広く使用されている Ingress コントローラーの 1 つであり（数割のクラスターで使用されているとの推定もあります）、この脆弱性の実際の影響は非常に大きいものです。詳細、技術的分析、および公式の修正推奨事項は、Kubernetes、Wiz の研究者、および多数のベンダーブログによって公開されています。

レポートの目的

CVE-2025-1974 を段階的に分析し、write-up に必要な資料を準備します。

資料の収集と整理。 公式 advisories、研究用 write-ups、ベンダー分析を収集し、主要な技術的詳細と PoC の方向性を明確にします。
脆弱性の本質とその影響を理解する。 root cause、攻撃チェーン、および考えられる影響（RCE → Secrets の漏えい → クラスター乗っ取り）を説明します。
CPE と設定条件を特定する。 脆弱性が該当する Kubernetes/ingress-nginx のバージョン/パッケージと設定を列挙します。
ラボでの安全なテストに関する推奨事項を示し、大規模な検証時のリスクを最小化します。

⚠️ 免責事項

本調査は教育および倫理的な目的のみで実施され、テスト/管理された環境を対象としています。
いかなる状況でも、所有者の書面による許可なしに、他人のクラスターや公開されたインスタンスに対してエクスプロイト/PoC を実行しないでください。完全に動作する「weaponized」PoC を公開すると、悪用のリスクが大幅に高まります。公開部分では、safe-PoC と方法論を示すのが適切です。（公式 advisories やベンダーも、エクスプロイトの拡散における注意を強調しています。）

CPE と設定条件

cpe:2.3:a:kubernetes:ingress-nginx_controller:<version> — 影響を受ける ingress-nginx のバージョン（advisories に具体的なバージョンが記載されています。最終公開時に値を更新してください）。
影響を受けるコントローラーを含むベンダー/ディストリビューション:
- 指定されたパッチバージョンより前の ingress-nginx を使用する RKE2 / Rancher ディストリビューション。
- 影響を受ける ingress-nginx を使用する Harvester のバージョン（ベンダー KB に具体的な affected builds が記載されています）。
- ingress-nginx を個別にインストールしているカスタムクラスター（Helm chart/manifest）— chart/image のバージョンを確認してください。

脆弱性が該当する設定条件:

影響を受ける ingress-nginx のバージョン（advisories に記載されたリリース/パッチより前のもの）。正確なバージョン番号は NVD およびベンダーの advisories を参照してください。
Validating admission webhook が pod ネットワークの外部からアクセス可能 — webhook が外部からアクセスできる場合（例: 公開エンドポイント、プロバイダーが誤ってサービスを公開した場合）、エクスプロイトはリモートで実行される可能性があります。Wiz や他の研究者は、公開にさらされた事例が多数あると指摘しています。
NetworkPolicy / pod ネットワーク分離の欠如: 攻撃者が何らかの Pod（compromised pod）からクラスターネットワークへリクエストを送信できる場合、それだけで悪用が可能です。
admission controller の前段に追加の検証/ACL がないこと: 追加のフィルター/ingress-proxy 認証はリスクを軽減できる可能性があります。
ingress-nginx コンテナー内に広い権限と Secrets へのアクセスを持つサービスアカウントが存在すること — デフォルトでは、コントローラーは広い権限を持つ serviceAccount をマウントすることがよくあります。これにより、悪用が成功した場合の影響が増大します。

脆弱性の詳細

概要。
この脆弱性は Ingress-NGINX コントローラーの Validating Admission Controller コンポーネントで発見され、このコンポーネントが受信した Ingress / AdmissionReview に基づいて NGINX の一時設定を生成・検証する方法に関連しています。処理の過程で、コントローラーは nginx.conf を生成し、設定検証（nginx -t）を実行します。Ingress/AdmissionReview フィールドのサニタイズが不十分な場合、攻撃者は特別に細工した断片を挿入でき、それが生成された設定に含まれて、結果としてコントローラープロセス内でのコマンド実行、すなわち ingress-nginx の Pod 内でのリモートコード実行（RCE）につながる可能性があります。

主要な技術的ポイント

エントリーポイント。 コントローラーの validating webhook が受け取る AdmissionReview/Ingress オブジェクトは、NGINX 設定の生成（アノテーションフィールド、backend 設定などを含む）の入力データになります。
悪用のメカニズム。 悪意を持って作成された Ingress または直接の AdmissionReview により、設定のテンプレート/断片に攻撃者が制御する文字列を注入できます。このような nginx.conf を検証/ロードする際、検証プロセス（nginx -t）とその後の設定ファイル操作は、コントローラーのコンテキストでの任意のコード実行、ファイルの書き込み/実行、またはコマンド実行につながる可能性があります。
必要な条件。 悪用を成功させるには、影響を受ける ingress-nginx のバージョン、validating webhook に AdmissionReview を届ける能力（pod ネットワークからのアクセスまたは直接のネットワークアクセス）、そして NetworkPolicy、RBAC 制限、追加の webhook 認証などの補完的対策がないことが必要です。一部のシナリオでは、Create/Update 権限を回避して、crafted な AdmissionReview を webhook に直接送信することが可能です。

admission

なぜ危険か — 悪用された場合の影響

悪用に成功すると、ingress-nginx コンテナー内でのコード実行が可能になり、通常は次のことが可能になります:

コントローラーの serviceAccount トークンを取得し、Kubernetes API にアクセスする。
アクセス可能な namespace 内の Secrets やその他の機密情報を読む。
クラスターリソースを作成/変更し、アクセスを拡大する（特権昇格、lateral movement）。
場合によっては、クラスターの完全な乗っ取り。

挙動および検知に関する観察

コントローラーが正常に動作している場合、Admission Controller へのリクエストフローは通常ありません。validating webhook はクラスター内で動作する内部コンポーネントとして機能します。悪用中には異常が観察されます: ネットワークマップ（例: Luntry）上で、ingress-nginx-controller-admission および ingress-nginx-controller サービスへの非標準的な送信元（レポートでは alpine のようなコンテナー）からの着信接続が現れますが、通常の動作ではこれは発生しないはずです。
クラスターネットワークマップの分析により、マイクロサービス間の相互作用を把握できます。namespace 内の ingress-nginx Deployment を選択すると、着信/発信の接続を確認できます。攻撃時に admission-endpoint への着信接続が現れることは、侵害の明確な指標です。
悪用の試みを検出するには、validating webhook への POST リクエスト、非定型の Ingress オブジェクトの作成、nginx -t の呼び出しとコントローラーの突然の再起動、および ingress-nginx プロセスによる予期しないファイル書き込み操作を監視すると有効です。

背景: NGINX Ingress コントローラーとは何か、なぜ重要なのか

Ingress-NGINX は、Kubernetes で最も広く使用されている Ingress コントローラーの 1 つです（サービスへの外部アクセスを構成するために広く使用されています）。このコントローラーはリバースプロキシとして機能し、外部トラフィックを受け取り、Ingress ルールのセットに基づいて対応する Service/Pod にプロキシします。Ingress-NGINX プロジェクトは非常に人気があり、インターネットにアクセス可能なクラスターのかなりの割合で導入されています。

Ingress-NGINX は、Kubernetes ドキュメントで Ingress コントローラーのリファレンス実装として挙げられています。公開されているクラスターのかなりの割合がこれを使用していると推定されています。いくつかの調査では、公開されたクラスターの約 41% が Ingress-NGINX を使用していると示されています。この広範な普及とトラフィックルーティングにおける中心的な役割のため、このコンポーネントの脆弱性は実用的な影響が非常に大きくなります。

validating webhook が攻撃の都合の良いベクトルとなる理由

デフォルトでは、コントローラーの validating webhook は Kubernetes ネットワーク空間内でアクセス可能であり、そのアドレス（例: validate.nginx.ingress.kubernetes.io）へのアクセスには追加の認証を必要としないことがよくあります。これにより、クラスター内部から簡単にアクセスできます。
組み合わせ: コントローラーの広範な普及 + そのネットワークアクセス + 潜在的に広いサービスアカウント権限 = 侵害への効果的な経路を提供する重大な組み合わせです。
実際の運用では、クラスターへの「最初のエントリーポイント」を得るのはそれほど難しくありません。アプリケーションには個々のコンテナーの侵害につながる脆弱性がしばしば含まれており、攻撃者はそのコンテナーから internal webhook にアクセスできます。さらに、Web アプリケーションの SSRF などの悪用可能な脆弱性は、クラスターネットワーク内へのリクエストを開始し、そのような webhook を利用するためによく使用されます。

エクスプロイトチェーンの再説明（要約）

攻撃者は pod ネットワークにリクエストを送信する能力、または validating webhook への直接アクセスを得ます。
特定のフィールドに適切なフィルタリングを通過していない悪意のある文字列を含む、特別に crafted な Ingress / AdmissionReview が作成されます。
コントローラーはこれらの入力に基づいて nginx.conf を生成し、nginx -t / その他の検証操作を実行します。
注入された断片により、コントローラープロセスのコンテキストでのコマンド/スクリプトの実行、またはファイルの書き込み/実行が発生します。
コード実行を獲得すると、攻撃者は serviceAccount token を抽出し、Kubernetes API にアクセスして、クラスター内での横移動と特権昇格を継続します。

他の脆弱性との関連性に関する注意

このような脆弱性は、他の欠陥と組み合わさると特に危険です。侵害された Pod（または公開アプリケーションの SSRF）+ 公開された validating webhook は、完全な侵害の可能性を高めます。したがって、インシデント分析では、ingress-nginx のバージョンだけでなく、依存関係のチェーンと潜在的なベクトルを考慮する必要があります。