Kubernetes Ingress NGINX Controllerの重大な脆弱性 CVE-2025-1974 詳説 #IngressNightmare #Ingressの悪夢


## 発見の経緯と背景

KubernetesのIngress NGINX Controllerで、**CVE-2025-1974**に指定された重大な脆弱性が2025年3月に公表されました。この脆弱性はクラウドセキュリティ企業のWizによって2024年末に発見・報告され、関連する他の脆弱性群と合わせて「**IngressNightmare**」と呼ばれています ([Remote Code Execution Vulnerabilities in Ingress NGINX  | Wiz Blog](https://www.wiz.io/blog/ingress-nginx-kubernetes-vulnerabilities#:~:text=Wiz%20Research%20discovered%20CVE,can%20result%20in%20cluster%20takeover))。Ingress NGINX ControllerはKubernetes公式のオープンソースIngressコントローラであり、その汎用性から**全Kubernetesクラスタの約40%で導入**される非常に一般的なコンポーネントです ([Ingress-nginx CVE-2025-1974: What You Need to Know | Kubernetes](https://kubernetes.io/blog/2025/03/24/ingress-nginx-cve-2025-1974/#:~:text=Many%20different%20ingress%20controllers%20are,of%20Kubernetes%20clusters))。Ingressは内部のサービスを外部に公開するための機能であり、Ingress Controllerはその設定にもとづいてNGINXなどのロードバランサ/プロキシを構成します ([Ingress-nginx CVE-2025-1974: What You Need to Know | Kubernetes](https://kubernetes.io/blog/2025/03/24/ingress-nginx-cve-2025-1974/#:~:text=Ingress%20%20is%20the%20traditional,user%E2%80%99s%20particular%20situation%20and%20needs)) ([Ingress-nginx CVE-2025-1974: What You Need to Know | Kubernetes](https://kubernetes.io/blog/2025/03/24/ingress-nginx-cve-2025-1974/#:~:text=Ingress,into%20doing%20things%20it%20shouldn%E2%80%99t))。  

Wizの調査によれば、Ingress NGINX Controllerに存在する複数の脆弱性により**クラスタ内の任意の攻撃者がリモートコード実行（RCE）を達成し、クラスタ全体を乗っ取る恐れ**があることが判明しました ([Remote Code Execution Vulnerabilities in Ingress NGINX  | Wiz Blog](https://www.wiz.io/blog/ingress-nginx-kubernetes-vulnerabilities#:~:text=Wiz%20Research%20discovered%20CVE,can%20result%20in%20cluster%20takeover)) ([Remote Code Execution Vulnerabilities in Ingress NGINX  | Wiz Blog](https://www.wiz.io/blog/ingress-nginx-kubernetes-vulnerabilities#:~:text=IngressNightmare%2C%20affecting%20the%20admission%20controller,them%20at%20immediate%20critical%20risk))。特にCVE-2025-1974はそれらの中で最も深刻で、**CVSSスコアは9.8（Critical）**に評価されています ([Ingress-nginx CVE-2025-1974: What You Need to Know | Kubernetes](https://kubernetes.io/blog/2025/03/24/ingress-nginx-cve-2025-1974/#:~:text=The%20most%20serious%20of%20today%E2%80%99s,cluster%2C%20with%20no%20credentials%20or)) ([CVE-2025-1974: ingress-nginx admission controller RCE escalation · Issue #131009 · kubernetes/kubernetes · GitHub](https://github.com/kubernetes/kubernetes/issues/131009#:~:text=Loading))。この脆弱性により、**認証されていない攻撃者でもPodネットワーク経由でIngress Controllerに対し悪意あるリクエストを送信するだけで、Ingress NGINX Controllerの権限で任意コード実行が可能**となります ([Critical Ingress NGINX Controller Vulnerability Allows RCE Without Authentication](https://thehackernews.com/2025/03/critical-ingress-nginx-controller.html#:~:text=nginx%20controller%20and%20disclosure%20of,nginx%20controller%20under%20certain%20conditions))。Ingress Controllerはデフォルトでクラスタ内全NamespaceのSecretを読み取れる強力な権限を持つため（TLS証明書の参照のため等）、侵入に成功するとクラスタ内のあらゆる機密情報（Secret）を窃取でき、ひいては**クラスタ管理権限の奪取**につながります ([NVD - CVE-2025-1974](https://nvd.nist.gov/vuln/detail/CVE-2025-1974#:~:text=A%20security%20issue%20was%20discovered,wide)) ([Critical Ingress NGINX Controller Vulnerability Allows RCE Without Authentication](https://thehackernews.com/2025/03/critical-ingress-nginx-controller.html#:~:text=,lead%20to%20complete%20cluster%20takeover))。このように、IngressNightmare（特にCVE-2025-1974）はKubernetes利用者にとって非常に危険なセキュリティ上の緊急事態と言えます ([Ingress-nginx CVE-2025-1974: What You Need to Know | Kubernetes](https://kubernetes.io/blog/2025/03/24/ingress-nginx-cve-2025-1974/#:~:text=The%20most%20serious%20of%20today%E2%80%99s,scenarios%2C%20the%20Pod%20network%20is)) ([Ingress-nginx CVE-2025-1974: What You Need to Know | Kubernetes](https://kubernetes.io/blog/2025/03/24/ingress-nginx-cve-2025-1974/#:~:text=other%20vulnerabilities%2C%20CVE,even%20anyone%20connected%20to%20your))。

本報告では、CVE-2025-1974の発見経緯と背景、技術的詳細、影響範囲、悪用シナリオ、公式対策および回避策について詳しく説明します。

<div class="relative overflow-hidden md:rounded-lg md:shadow-2xl md:shadow-gray-black/30"><div style="aspect-ratio: 1.775 / 1; width: 100%; height: 100%;"><div data-vimeo-initialized="true" style="width: 100%; height: 100%; overflow: hidden;"><iframe src="https://player.vimeo.com/video/1068225709?title=0&amp;byline=0&amp;portrait=0&amp;playsinline=0&amp;muted=1&amp;autoplay=1&amp;autopause=0&amp;loop=1&amp;app_id=122963" width="426" height="240" frameborder="0" allow="autoplay; fullscreen; picture-in-picture; clipboard-write; encrypted-media" title="NGINX_Weakness_v1" data-ready="true" style="width: 100%; height: 100%;"></iframe></div></div></div>

## 技術的な概要と原理

**CVE-2025-1974の本質**は、Ingress NGINX Controllerに内蔵された**Validating Admission Controller（バリデーション用アドミッションコントローラ）**の設計上の欠陥と入力処理の不備により生じたものです。Ingress NGINX Controllerは、新規Ingressリソースの作成や更新時にその内容を検証するためのAdmission Webhookを提供しており、受け取ったIngressオブジェクトを元に一時的なNGINX設定ファイルを生成して`nginx -t`コマンドでテスト（検証）します ([Remote Code Execution Vulnerabilities in Ingress NGINX  | Wiz Blog](https://www.wiz.io/blog/ingress-nginx-kubernetes-vulnerabilities#:~:text=The%20vulnerabilities%20above%20allow%20an,ab%29use))。本来、このAdmission ControllerはKubernetes APIサーバが呼び出すことを想定したコンポーネントですが、**クラスター内の任意のPodや（設定によっては）外部ネットワークからも認証なしでアクセス可能**な状態にありました ([Critical Ingress NGINX Controller Vulnerability Allows RCE Without Authentication](https://thehackernews.com/2025/03/critical-ingress-nginx-controller.html#:~:text=The%20vulnerability%20takes%20advantage%20of,over%20the%20network%20without%20authentication))。また、生成するNGINX設定中に**ユーザ入力由来の値が適切にエスケープ・サニタイズされない箇所**が存在したため、攻撃者はNGINX設定断片を**任意に注入（インジェクション）**できることが判明しました ([Remote Code Execution Vulnerabilities in Ingress NGINX  | Wiz Blog](https://www.wiz.io/blog/ingress-nginx-kubernetes-vulnerabilities#:~:text=In%20the%20,for%20a%20new%20injection%20point))。

具体的には、Wizの報告によればIngressの**`mirror`機能に関連する処理**で脆弱性が確認されています。Ingressリソースにはトラフィックを複製する「ミラー」先を指定する注釈（annotations）が存在しますが、そのパーサー実装中でIngressオブジェクトの**UID（固有ID）**値をNGINX設定に挿入するコードがありました ([Remote Code Execution Vulnerabilities in Ingress NGINX  | Wiz Blog](https://www.wiz.io/blog/ingress-nginx-kubernetes-vulnerabilities#:~:text=CVE))。IngressのUIDは通常Kubernetesが自動付与するものですが、Admission Controllerが受け取るIngressオブジェクトの内容次第で攻撃者が**このUIDフィールドの値を巧妙に制御できる**ことが判明しました（本来APIサーバから渡されるUIDですが、AdmissionReviewリクエストを直接送ることで細工可能）。当該コードではUID値に対するエスケープや形式検証がなく、**攻撃者提供のUID文字列がそのままNGINX設定に埋め込まれる**ため、改行や特殊文字を仕込んで**意図しないNGINXディレクティブを注入**できました ([Remote Code Execution Vulnerabilities in Ingress NGINX  | Wiz Blog](https://www.wiz.io/blog/ingress-nginx-kubernetes-vulnerabilities#:~:text=In%20the%20,for%20a%20new%20injection%20point))。この問題により、Ingressのアノテーション値以外のフィールドを悪用した**想定外の設定インジェクション**が可能となっています。

こうした脆弱性（IngressNightmareには他にも複数の注釈ベースの設定注入バグが含まれる）は「任意のNGINX設定ディレクティブを注入できる」ことを意味します ([Remote Code Execution Vulnerabilities in Ingress NGINX  | Wiz Blog](https://www.wiz.io/blog/ingress-nginx-kubernetes-vulnerabilities#:~:text=The%20vulnerabilities%20above%20allow%20an,ab%29use))。注入された設定は前述の通りAdmission Controller内で`nginx -t`によって**検証目的で実行**されます。そのため直ちにコード実行が起きるわけではありませんが、**`nginx -t`実行時に悪用可能なNGINX設定ディレクティブ**があれば、それを注入することでコマンド実行を発生させられます ([Remote Code Execution Vulnerabilities in Ingress NGINX  | Wiz Blog](https://www.wiz.io/blog/ingress-nginx-kubernetes-vulnerabilities#:~:text=The%20vulnerabilities%20above%20allow%20an,ab%29use))。Wizの研究者らはさまざまなディレクティブを検証し、NGINXが持つ**動的モジュール読み込み機能**に着目しました ([Remote Code Execution Vulnerabilities in Ingress NGINX  | Wiz Blog](https://www.wiz.io/blog/ingress-nginx-kubernetes-vulnerabilities#:~:text=Initially%20we%20tried%20to%20use,with%20the%20following%20error%20message)) ([Remote Code Execution Vulnerabilities in Ingress NGINX  | Wiz Blog](https://www.wiz.io/blog/ingress-nginx-kubernetes-vulnerabilities#:~:text=There%20are%20many%20usable%20directives,suitable%20for%20our%20injection%E2%80%99s%20constraints))。標準の`load_module`ディレクティブは設定ファイルの先頭でしか使えず今回は利用できなかったものの、**`ssl_engine`ディレクティブ**という普段はドキュメント化されていない機能を発見しています。`ssl_engine`はOpenSSL用モジュールの一部で、本来ハードウェアSSLエンジンを指定するための設定ですが、**任意の共有ライブラリ（.soファイル）をロードする**用途にも使えることが分かりました ([Remote Code Execution Vulnerabilities in Ingress NGINX  | Wiz Blog](https://www.wiz.io/blog/ingress-nginx-kubernetes-vulnerabilities#:~:text=There%20are%20many%20usable%20directives,suitable%20for%20our%20injection%E2%80%99s%20constraints))。さらに重要な点として、`ssl_engine`は設定ファイル内の**どの位置に書いても機能する**ため、Admission Controllerが生成する途中の設定に注入しても有効に働きます ([Remote Code Execution Vulnerabilities in Ingress NGINX  | Wiz Blog](https://www.wiz.io/blog/ingress-nginx-kubernetes-vulnerabilities#:~:text=There%20are%20many%20usable%20directives,suitable%20for%20our%20injection%E2%80%99s%20constraints))。

しかし、`ssl_engine`で任意コード実行を行うには**攻撃用の共有ライブラリ（悪意ある.soファイル）をあらかじめIngress Controllerのコンテナ内に配置する必要**があります。研究者らはこれもNGINXの機能を悪用して達成しました。Ingress NGINX Controllerは内部でNGINX本体を実行しており、Ingress経由の通常のHTTPリクエストを受け付けています。このNGINXは大きなリクエストボディを処理する際、一時ファイルとしてディスクに書き出す動作（**client body buffering**）を持ちます ([Remote Code Execution Vulnerabilities in Ingress NGINX  | Wiz Blog](https://www.wiz.io/blog/ingress-nginx-kubernetes-vulnerabilities#:~:text=When%20processing%20requests%2C%20NGINX%20sometimes,file%20on%20the%20pod%E2%80%99s%20filesystem))。デフォルトでは**8KBを超えるリクエストボディ**を受信するとファイルに書き出すため、攻撃者は**8KB超のペイロード（悪意ある.soのバイナリデータ）を含むHTTPリクエスト**をIngress経由で送信し、NGINXにその内容を一時ファイルとして保存させました ([Remote Code Execution Vulnerabilities in Ingress NGINX  | Wiz Blog](https://www.wiz.io/blog/ingress-nginx-kubernetes-vulnerabilities#:~:text=When%20processing%20requests%2C%20NGINX%20sometimes,file%20on%20the%20pod%E2%80%99s%20filesystem))。NGINXは書き出し後すぐそのファイルを削除しますが、プロセスによっては削除後もファイルディスクリプタが開いたまま保持されます ([Remote Code Execution Vulnerabilities in Ingress NGINX  | Wiz Blog](https://www.wiz.io/blog/ingress-nginx-kubernetes-vulnerabilities#:~:text=Unfortunately%2C%20NGINX%20also%20removes%20the,which%20is%20accessible%20from%20ProcFS))。Wizの研究では**Content-Lengthヘッダで実際のサイズより大きな値を指定して通信を意図的に保留状態にする**ことで、削除後もしばらくファイルディスクリプタが残る状況を作り出しています ([Remote Code Execution Vulnerabilities in Ingress NGINX  | Wiz Blog](https://www.wiz.io/blog/ingress-nginx-kubernetes-vulnerabilities#:~:text=To%20keep%20the%20file%20descriptor,descriptor%20open%20for%20longer))。攻撃者はIngress Controllerのコンテナ内で動くNGINXのプロセスIDとオープンファイルディスクリプタ番号を推測し（コンテナ内のプロセス数は少なく絞り込み可能）、`/proc/<PID>/fd/<FD>`というカーネルの擬似ファイルパスを導き出しました ([Remote Code Execution Vulnerabilities in Ingress NGINX  | Wiz Blog](https://www.wiz.io/blog/ingress-nginx-kubernetes-vulnerabilities#:~:text=Unfortunately%2C%20NGINX%20also%20removes%20the,which%20is%20accessible%20from%20ProcFS))。このパスを用いれば、一度削除済みでも開かれている一時ファイルの内容（＝アップロードした.soライブラリ）にアクセスできます。

以上を踏まえ、CVE-2025-1974の原理は**「Ingress Admission Controllerへの不正リクエストによりNGINX設定をインジェクションし、NGINXの設定テスト処理中に攻撃用共有ライブラリをロードさせてコード実行させる」**というものです ([Critical Ingress NGINX Controller Vulnerability Allows RCE Without Authentication](https://thehackernews.com/2025/03/critical-ingress-nginx-controller.html#:~:text=The%20vulnerability%20takes%20advantage%20of,over%20the%20network%20without%20authentication)) ([Critical Ingress NGINX Controller Vulnerability Allows RCE Without Authentication](https://thehackernews.com/2025/03/critical-ingress-nginx-controller.html#:~:text=Specifically%2C%20it%20involves%20injecting%20an,the%20Ingress%20NGINX%20Controller%27s%20pod))。言い換えれば、本来Ingressリソースの検証という**セキュリティ境界内部の処理**に、外部から細工したIngress定義を送り込むことで境界を突破し、Ingress Controllerプロセス内で任意コードを実行する攻撃です。この攻撃はKubernetesの設計上、「Admission Webhookは信頼できるAPIサーバからのみ呼ばれる」という前提を突いたもので、**ネットワーク的隔離や認証が欠如した機能**に対する攻撃と言えます ([Critical Ingress NGINX Controller Vulnerability Allows RCE Without Authentication](https://thehackernews.com/2025/03/critical-ingress-nginx-controller.html#:~:text=The%20vulnerability%20takes%20advantage%20of,over%20the%20network%20without%20authentication))。結果として、Ingress Controllerが持つ高い権限（全Secrets閲覧権限など）を乗っ取られてしまうため、**極めて危険**です。

## 影響範囲

今回の脆弱性は**Kubernetes Ingress NGINX Controllerの特定バージョンに存在**します。影響を受けるのはおおよそ以下のバージョン範囲です ([CVE-2025-1974: ingress-nginx admission controller RCE escalation · Issue #131009 · kubernetes/kubernetes · GitHub](https://github.com/kubernetes/kubernetes/issues/131009#:~:text=))：

- **ingress-nginx v1.12.0 およびそれ以前**（※v1.12.1で修正）  
- **ingress-nginx v1.11.4 およびそれ以前**（v1.11系列はv1.11.5で修正）  

具体的には、**v1.11.0〜v1.11.4**および**v1.12.0**が該当し、さらにそれ未満の古い全バージョンも影響下にあります ([CVE-2025-1974: ingress-nginx admission controller RCE escalation · Issue #131009 · kubernetes/kubernetes · GitHub](https://github.com/kubernetes/kubernetes/issues/131009#:~:text=))。2025年3月24日に**修正パッチを適用したv1.11.5およびv1.12.1**がリリースされ、これらで本脆弱性は修正されています ([Ingress-nginx CVE-2025-1974: What You Need to Know | Kubernetes](https://kubernetes.io/blog/2025/03/24/ingress-nginx-cve-2025-1974/#:~:text=corporate%20network%21%20This%20is%20a,very%20serious%20situation))。したがって、**パッチ未適用の全てのIngress NGINX Controllerデプロイ**が潜在的に攻撃対象となります。自分のクラスタでIngress NGINX Controllerを使っているかどうかは、名前空間全体を対象に`kubectl get pods --all-namespaces --selector app.kubernetes.io/name=ingress-nginx`などと実行して確認できます ([CVE-2025-1974: ingress-nginx admission controller RCE escalation · Issue #131009 · kubernetes/kubernetes · GitHub](https://github.com/kubernetes/kubernetes/issues/131009#:~:text=Am%20I%20vulnerable%3F))。

この脆弱性の悪用には**Ingress NGINX ControllerのAdmission Controller機能が有効**であることが前提です（デフォルトでは有効）。無効化している場合は直接の影響を受けませんが、そのようなケースは稀でしょう。また攻撃者側の前提条件として、Ingress Controller（通常は`ingress-nginx`という名前のPodやService）にネットワーク経由で到達できる必要があります ([Critical Ingress NGINX Controller Vulnerability Allows RCE Without Authentication](https://thehackernews.com/2025/03/critical-ingress-nginx-controller.html#:~:text=The%20vulnerability%20takes%20advantage%20of,over%20the%20network%20without%20authentication))。多くの場合、Kubernetes内のPod同士は互いに通信可能なため、**クラスタ内に入り込んだ攻撃者（悪意あるコンテナなど）は誰でもIngressのAdmission Portにアクセスできる**と考えられます ([Ingress-nginx CVE-2025-1974: What You Need to Know | Kubernetes](https://kubernetes.io/blog/2025/03/24/ingress-nginx-cve-2025-1974/#:~:text=other%20vulnerabilities%2C%20CVE,even%20anyone%20connected%20to%20your))。さらにWizの調査では、約6500のクラスタでIngress ControllerのAdmission Controllerが誤ってインターネットに直接公開されている例も見つかっています ([Remote Code Execution Vulnerabilities in Ingress NGINX  | Wiz Blog](https://www.wiz.io/blog/ingress-nginx-kubernetes-vulnerabilities#:~:text=IngressNightmare%2C%20affecting%20the%20admission%20controller,them%20at%20immediate%20critical%20risk))。その場合、**外部から直接攻撃が可能**となり被害リスクは一層深刻です。

影響としては、攻撃が成功するとIngress Controllerの権限で任意コードが実行されます。Ingress Controllerはデフォルトで**クラスタ内全てのSecretsに読み取り可能**なRoleを持つため、攻撃者は**全Namespaceの機密情報（認証トークンやTLS秘密鍵など）を取得可能**です ([NVD - CVE-2025-1974](https://nvd.nist.gov/vuln/detail/CVE-2025-1974#:~:text=A%20security%20issue%20was%20discovered,wide))。Wizはデフォルトで存在し得る重要なSecretの例として、クラウド連携機能や他のコントローラのWebhook証明書など複数挙げています（例：`kube-system/konnectivity-certs`や`cert-manager/cert-manager-webhook-ca`等） ([Remote Code Execution Vulnerabilities in Ingress NGINX  | Wiz Blog](https://www.wiz.io/blog/ingress-nginx-kubernetes-vulnerabilities#:~:text=For%20the%20%60auth,in%20this%20type%20of%20attack)) ([Remote Code Execution Vulnerabilities in Ingress NGINX  | Wiz Blog](https://www.wiz.io/blog/ingress-nginx-kubernetes-vulnerabilities#:~:text=kube,tls))。これらを入手された場合、サービスアカウントの資格情報を用いたさらなる権限昇格や、クラスタ構成情報の窃取・改ざんが懸念されます ([Critical Ingress NGINX Controller Vulnerability Allows RCE Without Authentication](https://thehackernews.com/2025/03/critical-ingress-nginx-controller.html#:~:text=Controller%27s%20pod)) ([Critical Ingress NGINX Controller Vulnerability Allows RCE Without Authentication](https://thehackernews.com/2025/03/critical-ingress-nginx-controller.html#:~:text=Hillai%20Ben,and%20ultimately%20facilitate%20cluster%20takeover))。加えてIngress Controller自体の動作を乗っ取られるため、外部からのトラフィックを改ざん・盗聴されたり、サービス停止（DoS）させられる可能性もあります。

まとめると、本脆弱性の影響範囲は**Ingress NGINX Controllerを利用する多くのKubernetes環境に及び、攻撃成功時の影響はクラスタ全体の機密と可用性にまで波及し得る**非常に深刻なものです。適切な対策を行わない限り、マルチテナント環境やゼロトラストネットワーク下にないクラスタでは特にリスクが高いでしょう。

## 悪用のシナリオ

**CVE-2025-1974を悪用した攻撃シナリオの一例**を、手順を追って説明します。これはWizが提示した概念実証的な攻撃チェーンに基づくものです ([Remote Code Execution Vulnerabilities in Ingress NGINX  | Wiz Blog](https://www.wiz.io/blog/ingress-nginx-kubernetes-vulnerabilities#:~:text=The%20exploit%20works%20as%20follows%3A)) ([Remote Code Execution Vulnerabilities in Ingress NGINX  | Wiz Blog](https://www.wiz.io/blog/ingress-nginx-kubernetes-vulnerabilities#:~:text=NGINX%20to%20load%20the%20specified,file%20as%20a%20shared%20library))。

1. **攻撃用共有ライブラリのアップロード:** 攻撃者はまずIngress NGINX Controller上で動作しているNGINXに対して、**大きなサイズのHTTPリクエスト**を送信します。例えばIngress経由で公開されている任意のパスに、8KBを超えるペイロード（攻撃者が用意した悪意ある.so形式のバイナリデータ）を送りつけます。NGINXはリクエストボディを一時ファイルに書き出し、ファイルディスクリプタを保持したまま削除します ([Remote Code Execution Vulnerabilities in Ingress NGINX  | Wiz Blog](https://www.wiz.io/blog/ingress-nginx-kubernetes-vulnerabilities#:~:text=When%20processing%20requests%2C%20NGINX%20sometimes,file%20on%20the%20pod%E2%80%99s%20filesystem)) ([Remote Code Execution Vulnerabilities in Ingress NGINX  | Wiz Blog](https://www.wiz.io/blog/ingress-nginx-kubernetes-vulnerabilities#:~:text=Unfortunately%2C%20NGINX%20also%20removes%20the,which%20is%20accessible%20from%20ProcFS))。こうして、**Ingress ControllerのPod内ファイルシステム上に攻撃用ライブラリが実質的に配置**されます。  

2. **悪意あるIngressオブジェクトの準備:** 次に攻撃者は、細工したIngressリソースを模したAdmissionReviewリクエストを用意します。そのIngressオブジェクト内には、脆弱性を突く**不正な設定ディレクティブ**が含まれています。具体的には、前段でアップロードした.soファイルをロードするための`ssl_engine`ディレクティブをNGINX設定に注入するよう細工します ([Remote Code Execution Vulnerabilities in Ingress NGINX  | Wiz Blog](https://www.wiz.io/blog/ingress-nginx-kubernetes-vulnerabilities#:~:text=There%20are%20many%20usable%20directives,suitable%20for%20our%20injection%E2%80%99s%20constraints))。`ssl_engine <パス>`のパス部分には、先程特定した一時ファイルの場所（`/proc`経由でのファイルディスクリプタ参照パス）を指定します ([Remote Code Execution Vulnerabilities in Ingress NGINX  | Wiz Blog](https://www.wiz.io/blog/ingress-nginx-kubernetes-vulnerabilities#:~:text=3,file%20as%20a%20shared%20library))。  

3. **Admission Controllerへのリクエスト送信:** 準備したAdmissionReviewリクエストを、Ingress NGINX ControllerのAdmission Webhookサービス宛てに直接送信します。これはKubernetes APIサーバを経由せず、クラスタ内ネットワーク上でAdmission Controllerがリッスンしているエンドポイント（通常はHTTPSのサービス）に対してHTTPリクエストを送る形になります。Ingress Controller側では、このリクエストを受け取るとIngressオブジェクトの内容を検証すべく内部でNGINX設定を生成します。  

4. **悪意ある設定の注入と実行:** Admission Controllerが生成したNGINX設定には、攻撃者の仕込んだ`ssl_engine`ディレクティブが含まれています。Ingress Controllerは通常どおり`nginx -t`コマンドを起動し、この設定を**検証モードで適用**しようとします ([Remote Code Execution Vulnerabilities in Ingress NGINX  | Wiz Blog](https://www.wiz.io/blog/ingress-nginx-kubernetes-vulnerabilities#:~:text=The%20vulnerabilities%20above%20allow%20an,ab%29use))。すると、設定中の`ssl_engine`命令が実行され、指定されたパスにある共有ライブラリ（攻撃者がアップロードした.soファイル）がロードされます ([Critical Ingress NGINX Controller Vulnerability Allows RCE Without Authentication](https://thehackernews.com/2025/03/critical-ingress-nginx-controller.html#:~:text=In%20an%20experimental%20attack%20scenario%2C,request%20to%20the%20admission%20controller))。共有ライブラリの`init`処理として用意された任意の悪意あるコードがここで**Ingress Controllerのプロセス内で実行**されます。  

5. **Ingress Controller乗っ取り:** 攻撃者のコードがIngress Controller内で実行されたことで、攻撃者はそのコンテナ上で自由に動けるようになります。例えば、Ingress Controllerのサービスアカウントに付与された権限を用いてKubernetes APIにアクセスし、Secretリソースを読み取ることが可能です ([Critical Ingress NGINX Controller Vulnerability Allows RCE Without Authentication](https://thehackernews.com/2025/03/critical-ingress-nginx-controller.html#:~:text=Controller%27s%20pod))。あるいは直接ファイルシステム上のSecretトークンや設定ファイルを読み出すこともできます。最終的に攻撃者は取得した資格情報や秘密鍵を使ってさらに踏み込み、**クラスタ管理者権限の奪取や他のコンポーネントへの横展開**を行います ([Critical Ingress NGINX Controller Vulnerability Allows RCE Without Authentication](https://thehackernews.com/2025/03/critical-ingress-nginx-controller.html#:~:text=Hillai%20Ben,and%20ultimately%20facilitate%20cluster%20takeover))。場合によってはIngress Controller経由でサービスへの外部トラフィックを妨害・傍受したり、不要なIngressを作成して他サービスを影響下に置くことも可能です。

以上のシナリオは、専門的な手順を踏む必要があるものの、**自動化やスクリプト化も十分可能**な攻撃です。実際、Wizのチームはこのチェーンを実証するデモを内部で作成しています（ただし2025年3月時点では公開されたPoCはありません ([CVE-2025-1097, CVE-2025-1098, CVE-2025-1974, CVE-2025-24513, CVE-2025-24514: Frequently Asked Questions About IngressNightmare - Blog | Tenable®](https://www.tenable.com/blog/cve-2025-1974-frequently-asked-questions-about-ingressnightmare-kubernetes#:~:text=Was%20this%20exploited%20as%20a,day))）。重要なのは、攻撃者がクラスタ内で低い権限（たとえば1つのコンテナを乗っ取った程度）しか持っていなくても、この脆弱性を組み合わせることで一気にクラスタ全体を支配し得る点です ([Critical Ingress NGINX Controller Vulnerability Allows RCE Without Authentication](https://thehackernews.com/2025/03/critical-ingress-nginx-controller.html#:~:text=Specifically%2C%20it%20involves%20injecting%20an,the%20Ingress%20NGINX%20Controller%27s%20pod)) ([Critical Ingress NGINX Controller Vulnerability Allows RCE Without Authentication](https://thehackernews.com/2025/03/critical-ingress-nginx-controller.html#:~:text=,lead%20to%20complete%20cluster%20takeover))。また、前述のようにIngressのAdmissionサービスが誤ってインターネットに露出している場合は、**攻撃者はクラスタ内に侵入する必要すらなく**直接この脆弱性を突いてRCEを発生させられるため、被害の可能性はさらに高まります ([Remote Code Execution Vulnerabilities in Ingress NGINX  | Wiz Blog](https://www.wiz.io/blog/ingress-nginx-kubernetes-vulnerabilities#:~:text=IngressNightmare%2C%20affecting%20the%20admission%20controller,them%20at%20immediate%20critical%20risk))。

## 修正済みバージョンと公式対策

Kubernetesプロジェクトは本脆弱性の報告を受け、**2025年3月24日付けでIngress NGINX Controllerのアップデート版(v1.11.5およびv1.12.1)をリリース**しました ([Ingress-nginx CVE-2025-1974: What You Need to Know | Kubernetes](https://kubernetes.io/blog/2025/03/24/ingress-nginx-cve-2025-1974/#:~:text=corporate%20network%21%20This%20is%20a,very%20serious%20situation))。これらのバージョンでは、Wizが指摘した5件の脆弱性すべてに対処済みであり、利用者は速やかにアップグレードすることが推奨されています ([Ingress-nginx CVE-2025-1974: What You Need to Know | Kubernetes](https://kubernetes.io/blog/2025/03/24/ingress-nginx-cve-2025-1974/#:~:text=The%20best%20and%20easiest%20remedy,fixed%20by%20installing%20today%E2%80%99s%20patches))。特にCVE-2025-1974に関しては、問題のAdmission Controller部分に大きな改修が加えられました。具体的には、**Ingressの設定検証時に実行していた`nginx -t`による設定テストを一時的に無効化**し、将来的に安全なサンドボックス環境下でのみ実行できるよう対応する旨がソースコード上でコメントされています ([Controller: Several security fixes. by Gacko · Pull Request #13068 · kubernetes/ingress-nginx · GitHub](https://github.com/kubernetes/ingress-nginx/pull/13068/commits/0ccf4caaadec919680c455d221e53d97970d527d#:~:text=%2F%2A%20Deactivated%20to%20mitigate%20CVE,func%28%29))。この修正により、攻撃者が不正な設定を注入してもコード実行に至る経路が遮断され、CVE-2025-1974の直接的な悪用は困難になりました。加えて、他のInjection系脆弱性（CVE-2025-1097, 1098, 24514）についても**注釈値の正規表現チェック強化や不正文字をエスケープする処理**が追加され、任意のNGINX設定を埋め込めないよう改善されています ([Critical Ingress NGINX Controller Vulnerability Allows RCE Without Authentication](https://thehackernews.com/2025/03/critical-ingress-nginx-controller.html#:~:text=arbitrary%20code%20execution%20in%20the,secrets%20accessible%20to%20the%20controller)) ([Critical Ingress NGINX Controller Vulnerability Allows RCE Without Authentication](https://thehackernews.com/2025/03/critical-ingress-nginx-controller.html#:~:text=%2A%20CVE,secrets%20accessible%20to%20the%20controller))。パストラバーサルの脆弱性（CVE-2025-24513）についても、Secretファイルパスの扱いを見直すことで修正されています ([Critical Ingress NGINX Controller Vulnerability Allows RCE Without Authentication](https://thehackernews.com/2025/03/critical-ingress-nginx-controller.html#:~:text=%2A%20CVE,cn))。

修正パッチはKubernetesのIngress-NGINXプロジェクトのGitHubで公開されており、各種マニフェスト（YAML）やHelmチャート経由で最新バージョンに更新できます ([CVE-2025-1974: ingress-nginx admission controller RCE escalation · Issue #131009 · kubernetes/kubernetes · GitHub](https://github.com/kubernetes/kubernetes/issues/131009#:~:text=How%20do%20I%20mitigate%20this,vulnerability))。主要クラウドベンダ（AWS, GCPなど）もそれぞれ自社のマネージドKubernetes向けにアドバイザリを出し、マネージドIngressアドオンのアップデートを提供しています ([Remote Code Execution Vulnerabilities in Ingress NGINX  | Wiz Blog](https://www.wiz.io/blog/ingress-nginx-kubernetes-vulnerabilities#:~:text=We%20would%20like%20to%20thank,also%20published%20their%20own%20advisories))。なお、**脆弱性公開時点では悪用の事例は確認されておらず、IOC（侵害の兆候）も特定されていない**と報告されています ([CVE-2025-1974: ingress-nginx admission controller RCE escalation · Issue #131009 · kubernetes/kubernetes · GitHub](https://github.com/kubernetes/kubernetes/issues/131009#:~:text=Detection))。しかし、攻撃コードの公開や類似手法による攻撃が行われる可能性もあるため、**「自分は大丈夫」と油断せず早急にアップデートする**ことが重要です。

公式の発表によると、この脆弱性はKubernetes Security Response CommitteeとIngress-NGINXメンテナ（Marco Ebert氏、James Strong氏ら）が中心となって対応が行われました ([CVE-2025-1974: ingress-nginx admission controller RCE escalation · Issue #131009 · kubernetes/kubernetes · GitHub](https://github.com/kubernetes/kubernetes/issues/131009#:~:text=This%20vulnerability%20was%20reported%20by,Ohfeld%20et%20al%2C%20from%20Wiz))。脆弱性報告者であるWizの研究者（Nir Ohfeld氏ら）との協力のもと、報告から約3ヶ月の調整期間を経て公開・修正に至っています ([Remote Code Execution Vulnerabilities in Ingress NGINX  | Wiz Blog](https://www.wiz.io/blog/ingress-nginx-kubernetes-vulnerabilities#:~:text=Responsible%20Disclosure%20Timeline)) ([Remote Code Execution Vulnerabilities in Ingress NGINX  | Wiz Blog](https://www.wiz.io/blog/ingress-nginx-kubernetes-vulnerabilities#:~:text=February%2020%2C%202025%20%E2%80%93%20Kubernetes,1974))。Kubernetes公式ブログでも本件に関する詳細な説明とアップグレードの呼びかけが行われており、利用者に対し**「直ちに対策を講じるように」**と強調しています ([Ingress-nginx CVE-2025-1974: What You Need to Know | Kubernetes](https://kubernetes.io/blog/2025/03/24/ingress-nginx-cve-2025-1974/#:~:text=The%20ingress,immediately%20to%20keep%20yourself%20safe))。

## 一時的な回避策やベストプラクティス

**最も確実な対策は前述の通りIngress NGINX Controllerを修正済みバージョンへアップグレードすること**ですが、環境によっては即時対応が難しい場合もあります。そうした場合に備え、Kubernetesプロジェクトおよび専門家から以下のような回避策や防御的設定が推奨されています。

- **Admission Controller機能の一時無効化:** 影響部分であるValidating Admission Controllerをオフにすることで、脆弱性の悪用経路を遮断できます ([Ingress-nginx CVE-2025-1974: What You Need to Know | Kubernetes](https://kubernetes.io/blog/2025/03/24/ingress-nginx-cve-2025-1974/#:~:text=If%20you%20can%E2%80%99t%20upgrade%20right,nginx))。HelmでIngress NGINX Controllerを導入している場合は、`controller.admissionWebhooks.enabled=false`という値を設定して再デプロイします ([Ingress-nginx CVE-2025-1974: What You Need to Know | Kubernetes](https://kubernetes.io/blog/2025/03/24/ingress-nginx-cve-2025-1974/#:~:text=,the%20controller%20container%E2%80%99s%20argument%20list))。マニフェストを直接適用している場合は、リソースからValidatingWebhookConfiguration(`ingress-nginx-admission`)を削除し、Ingress ControllerのDeployment/DaemonSetの起動引数から`--validating-webhook`オプションを取り除きます ([Ingress-nginx CVE-2025-1974: What You Need to Know | Kubernetes](https://kubernetes.io/blog/2025/03/24/ingress-nginx-cve-2025-1974/#:~:text=%60controller.admissionWebhooks.enabled%3Dfalse%20%60%20,the%20controller%20container%E2%80%99s%20argument%20list))。これによりAdmission Webhookサーバが停止し、本脆弱性を突く経路は事実上なくなります（ただしIngressの正当性チェックも無効化されるため、アップグレード後に再度有効化することが望まれます ([Ingress-nginx CVE-2025-1974: What You Need to Know | Kubernetes](https://kubernetes.io/blog/2025/03/24/ingress-nginx-cve-2025-1974/#:~:text=If%20you%20turn%20off%20the,before%20they%20can%20take%20effect))）。  

- **ネットワークアクセスの制限:** 本来、IngressのAdmission WebhookはKubernetes APIサーバから呼ばれるものなので、クラスター内の任意Podや外部から直接アクセスできる必要はありません。可能であればNetworkPolicyを設定し、**Ingress NGINXのAdmissionポート（一般に443）への通信をKubernetesコントロールプレーンからのみに制限**してください。Wizの指摘にもあるように、「Admission Controllerへのアクセスをクラスター内Podから遮断し、決して公開しない」ことが理想です ([Remote Code Execution Vulnerabilities in Ingress NGINX  | Wiz Blog](https://www.wiz.io/blog/ingress-nginx-kubernetes-vulnerabilities#:~:text=We%20are%20only%20scratching%20the,more%20in%20other%20admission%20controllers))。現状Ingress NGINXは特に制限なくServiceを公開していたためこのような攻撃が成立しましたが、ネットワークレベルで遮断しておくと仮に脆弱性が残っていても悪用難度が大きく上がります。  

- **権限と設定の見直し:** Ingress NGINX Controllerに限らず、クラスタ内で動作するコンポーネントには**最小権限の原則（least privilege）**を適用すべきです ([Remote Code Execution Vulnerabilities in Ingress NGINX  | Wiz Blog](https://www.wiz.io/blog/ingress-nginx-kubernetes-vulnerabilities#:~:text=We%20are%20only%20scratching%20the,more%20in%20other%20admission%20controllers))。デフォルトのIngress Controllerは利便性のため広範な権限（全Secrets閲覧等）を持っていますが、運用上可能であれば閲覧を必要とするNamespaceやリソース種別を限定するようRoles/RoleBindingsを調整することが望ましいでしょう。また、Ingress Controllerのポッドに対してPod Security PoliciesやSeccomp, AppArmor等で権限を絞ることも有効です。例えばコンテナを非特権モードで実行しファイルシステムへの完全な書き込みを防ぐ、あるいは`/proc`経由の攻撃を検知するホスト側ルールを設ける、といった対策が考えられます。今回のケースではIngress Controllerが**過剰な権限と大きな攻撃対象（NGINXの複雑な設定機構）**を抱えていたことが被害拡大の一因でした ([Remote Code Execution Vulnerabilities in Ingress NGINX  | Wiz Blog](https://www.wiz.io/blog/ingress-nginx-kubernetes-vulnerabilities#:~:text=We%20are%20only%20scratching%20the,more%20in%20other%20admission%20controllers))。今後同様の脆弱性に備え、各種コントローラの権限や公開インターフェースについて監査・見直しを行うことが重要です。

- **監視と検知:** 現時点で既知の侵害指標(IOC)は無いものの、クラスタのログ中に不審な`AdmissionReview`リクエストやIngress Controllerコンテナ内の予期しないプロセス実行痕跡がないかをモニタリングすることも有用です。不正なIngress作成を試みた形跡（失敗したWebhook呼び出し等）や、Ingress Controllerの挙動異常（再起動ループや想定外のネットワーク接続）が見られた場合、念のため調査を行ってください。

最後に、Kubernetes公式も「**Ingress NGINX利用者は直ちに行動を起こすべき**」と注意喚起しています ([Ingress-nginx CVE-2025-1974: What You Need to Know | Kubernetes](https://kubernetes.io/blog/2025/03/24/ingress-nginx-cve-2025-1974/#:~:text=The%20ingress,immediately%20to%20keep%20yourself%20safe))。アップグレードが最優先ですが、上記のような回避策やベストプラクティスも組み合わせ、できるだけ早くクラスタを防御することが必要です。Admission Controllerは本来便利な機能であり、適切に保護された環境下で再度安心して利用できるよう、コミュニティでも今後の改善（例：安全なサンドボックス実行や認証の追加）について議論が進められるでしょう ([Controller: Several security fixes. by Gacko · Pull Request #13068 · kubernetes/ingress-nginx · GitHub](https://github.com/kubernetes/ingress-nginx/pull/13068/commits/0ccf4caaadec919680c455d221e53d97970d527d#:~:text=%2F%2A%20Deactivated%20to%20mitigate%20CVE,if%20err%20%21%3D%20nil)) ([Controller: Several security fixes. by Gacko · Pull Request #13068 · kubernetes/ingress-nginx · GitHub](https://github.com/kubernetes/ingress-nginx/pull/13068/commits/0ccf4caaadec919680c455d221e53d97970d527d#:~:text=%2F%2A%20Deactivated%20to%20mitigate%20CVE,func%28%29))。私たち利用者も、日頃から環境の設定を見直しつつ情報をアップデートし、脆弱性への迅速な対応に努めることが求められます。

**出典:**

- Kubernetes公式ブログ: “Ingress-nginx CVE-2025-1974: What You Need to Know” ([Ingress-nginx CVE-2025-1974: What You Need to Know | Kubernetes](https://kubernetes.io/blog/2025/03/24/ingress-nginx-cve-2025-1974/#:~:text=The%20most%20serious%20of%20today%E2%80%99s,cluster%2C%20with%20no%20credentials%20or)) ([Ingress-nginx CVE-2025-1974: What You Need to Know | Kubernetes](https://kubernetes.io/blog/2025/03/24/ingress-nginx-cve-2025-1974/#:~:text=The%20most%20serious%20of%20today%E2%80%99s,scenarios%2C%20the%20Pod%20network%20is)) ([Ingress-nginx CVE-2025-1974: What You Need to Know | Kubernetes](https://kubernetes.io/blog/2025/03/24/ingress-nginx-cve-2025-1974/#:~:text=The%20best%20and%20easiest%20remedy,fixed%20by%20installing%20today%E2%80%99s%20patches)) ([Ingress-nginx CVE-2025-1974: What You Need to Know | Kubernetes](https://kubernetes.io/blog/2025/03/24/ingress-nginx-cve-2025-1974/#:~:text=If%20you%20can%E2%80%99t%20upgrade%20right,nginx))  
- Wiz Researchブログ: “IngressNightmare: 9.8 Critical Unauthenticated Remote Code Execution Vulnerabilities in Ingress NGINX” ([Remote Code Execution Vulnerabilities in Ingress NGINX  | Wiz Blog](https://www.wiz.io/blog/ingress-nginx-kubernetes-vulnerabilities#:~:text=CVE)) ([Remote Code Execution Vulnerabilities in Ingress NGINX  | Wiz Blog](https://www.wiz.io/blog/ingress-nginx-kubernetes-vulnerabilities#:~:text=In%20the%20,for%20a%20new%20injection%20point)) ([Remote Code Execution Vulnerabilities in Ingress NGINX  | Wiz Blog](https://www.wiz.io/blog/ingress-nginx-kubernetes-vulnerabilities#:~:text=There%20are%20many%20usable%20directives,suitable%20for%20our%20injection%E2%80%99s%20constraints)) ([Remote Code Execution Vulnerabilities in Ingress NGINX  | Wiz Blog](https://www.wiz.io/blog/ingress-nginx-kubernetes-vulnerabilities#:~:text=When%20processing%20requests%2C%20NGINX%20sometimes,file%20on%20the%20pod%E2%80%99s%20filesystem)) ([Remote Code Execution Vulnerabilities in Ingress NGINX  | Wiz Blog](https://www.wiz.io/blog/ingress-nginx-kubernetes-vulnerabilities#:~:text=The%20exploit%20works%20as%20follows%3A)) ([Remote Code Execution Vulnerabilities in Ingress NGINX  | Wiz Blog](https://www.wiz.io/blog/ingress-nginx-kubernetes-vulnerabilities#:~:text=We%20are%20only%20scratching%20the,more%20in%20other%20admission%20controllers))  
- GitHub Kubernetes Issue: “CVE-2025-1974: ingress-nginx admission controller RCE escalation” ([CVE-2025-1974: ingress-nginx admission controller RCE escalation · Issue #131009 · kubernetes/kubernetes · GitHub](https://github.com/kubernetes/kubernetes/issues/131009#:~:text=)) ([CVE-2025-1974: ingress-nginx admission controller RCE escalation · Issue #131009 · kubernetes/kubernetes · GitHub](https://github.com/kubernetes/kubernetes/issues/131009#:~:text=How%20do%20I%20mitigate%20this,vulnerability)) ([CVE-2025-1974: ingress-nginx admission controller RCE escalation · Issue #131009 · kubernetes/kubernetes · GitHub](https://github.com/kubernetes/kubernetes/issues/131009#:~:text=This%20vulnerability%20was%20reported%20by,Ohfeld%20et%20al%2C%20from%20Wiz))  
- The Hacker News: “Critical Ingress NGINX Controller Vulnerability Allows RCE Without Authentication” ([Critical Ingress NGINX Controller Vulnerability Allows RCE Without Authentication](https://thehackernews.com/2025/03/critical-ingress-nginx-controller.html#:~:text=The%20vulnerability%20takes%20advantage%20of,over%20the%20network%20without%20authentication)) ([Critical Ingress NGINX Controller Vulnerability Allows RCE Without Authentication](https://thehackernews.com/2025/03/critical-ingress-nginx-controller.html#:~:text=nginx%20controller%20and%20disclosure%20of,nginx%20controller%20under%20certain%20conditions)) ([Critical Ingress NGINX Controller Vulnerability Allows RCE Without Authentication](https://thehackernews.com/2025/03/critical-ingress-nginx-controller.html#:~:text=In%20an%20experimental%20attack%20scenario%2C,request%20to%20the%20admission%20controller)) ([Critical Ingress NGINX Controller Vulnerability Allows RCE Without Authentication](https://thehackernews.com/2025/03/critical-ingress-nginx-controller.html#:~:text=Hillai%20Ben,and%20ultimately%20facilitate%20cluster%20takeover))  
- Tenable ブログ: “FAQ: Five vulnerabilities called IngressNightmare (CVE-2025-1097,...1974,...)” ([CVE-2025-1097, CVE-2025-1098, CVE-2025-1974, CVE-2025-24513, CVE-2025-24514: Frequently Asked Questions About IngressNightmare - Blog | Tenable®](https://www.tenable.com/blog/cve-2025-1974-frequently-asked-questions-about-ingressnightmare-kubernetes#:~:text=CVE%20Description%20CVSSv3%20CVE,8)) ([CVE-2025-1097, CVE-2025-1098, CVE-2025-1974, CVE-2025-24513, CVE-2025-24514: Frequently Asked Questions About IngressNightmare - Blog | Tenable®](https://www.tenable.com/blog/cve-2025-1974-frequently-asked-questions-about-ingressnightmare-kubernetes#:~:text=critical%20severity)) ([CVE-2025-1097, CVE-2025-1098, CVE-2025-1974, CVE-2025-24513, CVE-2025-24514: Frequently Asked Questions About IngressNightmare - Blog | Tenable®](https://www.tenable.com/blog/cve-2025-1974-frequently-asked-questions-about-ingressnightmare-kubernetes#:~:text=The%20most%20severe%20flaw%2C%20CVE,access%20within%20a%20Kubernetes%20cluster))  
- NVD (MITRE) CVEエントリ: **CVE-2025-1974** ([NVD - CVE-2025-1974](https://nvd.nist.gov/vuln/detail/CVE-2025-1974#:~:text=A%20security%20issue%20was%20discovered,wide))