発見の経緯と背景

KubernetesのIngress NGINX Controllerで、CVE-2025-1974に指定された重大な脆弱性が2025年3月に公表されました。この脆弱性はクラウドセキュリティ企業のWizによって2024年末に発見・報告され、関連する他の脆弱性群と合わせて「IngressNightmare」と呼ばれています (Remote Code Execution Vulnerabilities in Ingress NGINX | Wiz Blog)。Ingress NGINX ControllerはKubernetes公式のオープンソースIngressコントローラであり、その汎用性から全Kubernetesクラスタの約40%で導入される非常に一般的なコンポーネントです (Ingress-nginx CVE-2025-1974: What You Need to Know | Kubernetes)。Ingressは内部のサービスを外部に公開するための機能であり、Ingress Controllerはその設定にもとづいてNGINXなどのロードバランサ/プロキシを構成します (Ingress-nginx CVE-2025-1974: What You Need to Know | Kubernetes) (Ingress-nginx CVE-2025-1974: What You Need to Know | Kubernetes)。

Wizの調査によれば、Ingress NGINX Controllerに存在する複数の脆弱性によりクラスタ内の任意の攻撃者がリモートコード実行（RCE）を達成し、クラスタ全体を乗っ取る恐れがあることが判明しました (Remote Code Execution Vulnerabilities in Ingress NGINX | Wiz Blog) (Remote Code Execution Vulnerabilities in Ingress NGINX | Wiz Blog)。特にCVE-2025-1974はそれらの中で最も深刻で、CVSSスコアは9.8（Critical）に評価されています (Ingress-nginx CVE-2025-1974: What You Need to Know | Kubernetes) (CVE-2025-1974: ingress-nginx admission controller RCE escalation · Issue #131009 · kubernetes/kubernetes · GitHub)。この脆弱性により、認証されていない攻撃者でもPodネットワーク経由でIngress Controllerに対し悪意あるリクエストを送信するだけで、Ingress NGINX Controllerの権限で任意コード実行が可能となります (Critical Ingress NGINX Controller Vulnerability Allows RCE Without Authentication)。Ingress Controllerはデフォルトでクラスタ内全NamespaceのSecretを読み取れる強力な権限を持つため（TLS証明書の参照のため等）、侵入に成功するとクラスタ内のあらゆる機密情報（Secret）を窃取でき、ひいてはクラスタ管理権限の奪取につながります (NVD - CVE-2025-1974) (Critical Ingress NGINX Controller Vulnerability Allows RCE Without Authentication)。このように、IngressNightmare（特にCVE-2025-1974）はKubernetes利用者にとって非常に危険なセキュリティ上の緊急事態と言えます (Ingress-nginx CVE-2025-1974: What You Need to Know | Kubernetes) (Ingress-nginx CVE-2025-1974: What You Need to Know | Kubernetes)。

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

技術的な概要と原理

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)。本来、このAdmission ControllerはKubernetes APIサーバが呼び出すことを想定したコンポーネントですが、クラスター内の任意のPodや（設定によっては）外部ネットワークからも認証なしでアクセス可能な状態にありました (Critical Ingress NGINX Controller Vulnerability Allows RCE Without Authentication)。また、生成するNGINX設定中にユーザ入力由来の値が適切にエスケープ・サニタイズされない箇所が存在したため、攻撃者はNGINX設定断片を**任意に注入（インジェクション）**できることが判明しました (Remote Code Execution Vulnerabilities in Ingress NGINX | Wiz Blog)。

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

こうした脆弱性（IngressNightmareには他にも複数の注釈ベースの設定注入バグが含まれる）は「任意のNGINX設定ディレクティブを注入できる」ことを意味します (Remote Code Execution Vulnerabilities in Ingress NGINX | Wiz Blog)。注入された設定は前述の通りAdmission Controller内でnginx -tによって検証目的で実行されます。そのため直ちにコード実行が起きるわけではありませんが、nginx -t実行時に悪用可能なNGINX設定ディレクティブがあれば、それを注入することでコマンド実行を発生させられます (Remote Code Execution Vulnerabilities in Ingress NGINX | Wiz Blog)。Wizの研究者らはさまざまなディレクティブを検証し、NGINXが持つ動的モジュール読み込み機能に着目しました (Remote Code Execution Vulnerabilities in Ingress NGINX | Wiz Blog) (Remote Code Execution Vulnerabilities in Ingress NGINX | Wiz Blog)。標準のload_moduleディレクティブは設定ファイルの先頭でしか使えず今回は利用できなかったものの、ssl_engineディレクティブという普段はドキュメント化されていない機能を発見しています。ssl_engineはOpenSSL用モジュールの一部で、本来ハードウェアSSLエンジンを指定するための設定ですが、任意の共有ライブラリ（.soファイル）をロードする用途にも使えることが分かりました (Remote Code Execution Vulnerabilities in Ingress NGINX | Wiz Blog)。さらに重要な点として、ssl_engineは設定ファイル内のどの位置に書いても機能するため、Admission Controllerが生成する途中の設定に注入しても有効に働きます (Remote Code Execution Vulnerabilities in Ingress NGINX | Wiz Blog)。

しかし、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)。デフォルトでは8KBを超えるリクエストボディを受信するとファイルに書き出すため、攻撃者は8KB超のペイロード（悪意ある.soのバイナリデータ）を含むHTTPリクエストをIngress経由で送信し、NGINXにその内容を一時ファイルとして保存させました (Remote Code Execution Vulnerabilities in Ingress NGINX | Wiz Blog)。NGINXは書き出し後すぐそのファイルを削除しますが、プロセスによっては削除後もファイルディスクリプタが開いたまま保持されます (Remote Code Execution Vulnerabilities in Ingress NGINX | Wiz Blog)。Wizの研究ではContent-Lengthヘッダで実際のサイズより大きな値を指定して通信を意図的に保留状態にすることで、削除後もしばらくファイルディスクリプタが残る状況を作り出しています (Remote Code Execution Vulnerabilities in Ingress NGINX | Wiz Blog)。攻撃者はIngress Controllerのコンテナ内で動くNGINXのプロセスIDとオープンファイルディスクリプタ番号を推測し（コンテナ内のプロセス数は少なく絞り込み可能）、/proc/<PID>/fd/<FD>というカーネルの擬似ファイルパスを導き出しました (Remote Code Execution Vulnerabilities in Ingress NGINX | Wiz Blog)。このパスを用いれば、一度削除済みでも開かれている一時ファイルの内容（＝アップロードした.soライブラリ）にアクセスできます。

以上を踏まえ、CVE-2025-1974の原理は**「Ingress Admission Controllerへの不正リクエストによりNGINX設定をインジェクションし、NGINXの設定テスト処理中に攻撃用共有ライブラリをロードさせてコード実行させる」というものです (Critical Ingress NGINX Controller Vulnerability Allows RCE Without Authentication) (Critical Ingress NGINX Controller Vulnerability Allows RCE Without Authentication)。言い換えれば、本来Ingressリソースの検証というセキュリティ境界内部の処理**に、外部から細工したIngress定義を送り込むことで境界を突破し、Ingress Controllerプロセス内で任意コードを実行する攻撃です。この攻撃はKubernetesの設計上、「Admission Webhookは信頼できるAPIサーバからのみ呼ばれる」という前提を突いたもので、ネットワーク的隔離や認証が欠如した機能に対する攻撃と言えます (Critical Ingress NGINX Controller Vulnerability Allows RCE Without Authentication)。結果として、Ingress Controllerが持つ高い権限（全Secrets閲覧権限など）を乗っ取られてしまうため、極めて危険です。

影響範囲

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

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)。2025年3月24日に修正パッチを適用したv1.11.5およびv1.12.1がリリースされ、これらで本脆弱性は修正されています (Ingress-nginx CVE-2025-1974: What You Need to Know | Kubernetes)。したがって、パッチ未適用の全ての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)。

この脆弱性の悪用にはIngress NGINX ControllerのAdmission Controller機能が有効であることが前提です（デフォルトでは有効）。無効化している場合は直接の影響を受けませんが、そのようなケースは稀でしょう。また攻撃者側の前提条件として、Ingress Controller（通常はingress-nginxという名前のPodやService）にネットワーク経由で到達できる必要があります (Critical Ingress NGINX Controller Vulnerability Allows RCE Without Authentication)。多くの場合、Kubernetes内のPod同士は互いに通信可能なため、クラスタ内に入り込んだ攻撃者（悪意あるコンテナなど）は誰でもIngressのAdmission Portにアクセスできると考えられます (Ingress-nginx CVE-2025-1974: What You Need to Know | Kubernetes)。さらにWizの調査では、約6500のクラスタでIngress ControllerのAdmission Controllerが誤ってインターネットに直接公開されている例も見つかっています (Remote Code Execution Vulnerabilities in Ingress NGINX | Wiz Blog)。その場合、外部から直接攻撃が可能となり被害リスクは一層深刻です。

影響としては、攻撃が成功するとIngress Controllerの権限で任意コードが実行されます。Ingress Controllerはデフォルトでクラスタ内全てのSecretsに読み取り可能なRoleを持つため、攻撃者は全Namespaceの機密情報（認証トークンやTLS秘密鍵など）を取得可能です (NVD - CVE-2025-1974)。Wizはデフォルトで存在し得る重要なSecretの例として、クラウド連携機能や他のコントローラのWebhook証明書など複数挙げています（例：kube-system/konnectivity-certsやcert-manager/cert-manager-webhook-ca等） (Remote Code Execution Vulnerabilities in Ingress NGINX | Wiz Blog) (Remote Code Execution Vulnerabilities in Ingress NGINX | Wiz Blog)。これらを入手された場合、サービスアカウントの資格情報を用いたさらなる権限昇格や、クラスタ構成情報の窃取・改ざんが懸念されます (Critical Ingress NGINX Controller Vulnerability Allows RCE Without Authentication) (Critical Ingress NGINX Controller Vulnerability Allows RCE Without Authentication)。加えてIngress Controller自体の動作を乗っ取られるため、外部からのトラフィックを改ざん・盗聴されたり、サービス停止（DoS）させられる可能性もあります。

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

悪用のシナリオ

CVE-2025-1974を悪用した攻撃シナリオの一例を、手順を追って説明します。これはWizが提示した概念実証的な攻撃チェーンに基づくものです (Remote Code Execution Vulnerabilities in Ingress NGINX | Wiz Blog) (Remote Code Execution Vulnerabilities in Ingress NGINX | Wiz Blog)。

攻撃用共有ライブラリのアップロード: 攻撃者はまずIngress NGINX Controller上で動作しているNGINXに対して、大きなサイズのHTTPリクエストを送信します。例えばIngress経由で公開されている任意のパスに、8KBを超えるペイロード（攻撃者が用意した悪意ある.so形式のバイナリデータ）を送りつけます。NGINXはリクエストボディを一時ファイルに書き出し、ファイルディスクリプタを保持したまま削除します (Remote Code Execution Vulnerabilities in Ingress NGINX | Wiz Blog) (Remote Code Execution Vulnerabilities in Ingress NGINX | Wiz Blog)。こうして、Ingress ControllerのPod内ファイルシステム上に攻撃用ライブラリが実質的に配置されます。
悪意あるIngressオブジェクトの準備: 次に攻撃者は、細工したIngressリソースを模したAdmissionReviewリクエストを用意します。そのIngressオブジェクト内には、脆弱性を突く不正な設定ディレクティブが含まれています。具体的には、前段でアップロードした.soファイルをロードするためのssl_engineディレクティブをNGINX設定に注入するよう細工します (Remote Code Execution Vulnerabilities in Ingress NGINX | Wiz Blog)。ssl_engine <パス>のパス部分には、先程特定した一時ファイルの場所（/proc経由でのファイルディスクリプタ参照パス）を指定します (Remote Code Execution Vulnerabilities in Ingress NGINX | Wiz Blog)。
Admission Controllerへのリクエスト送信: 準備したAdmissionReviewリクエストを、Ingress NGINX ControllerのAdmission Webhookサービス宛てに直接送信します。これはKubernetes APIサーバを経由せず、クラスタ内ネットワーク上でAdmission Controllerがリッスンしているエンドポイント（通常はHTTPSのサービス）に対してHTTPリクエストを送る形になります。Ingress Controller側では、このリクエストを受け取るとIngressオブジェクトの内容を検証すべく内部でNGINX設定を生成します。
悪意ある設定の注入と実行: Admission Controllerが生成したNGINX設定には、攻撃者の仕込んだssl_engineディレクティブが含まれています。Ingress Controllerは通常どおりnginx -tコマンドを起動し、この設定を検証モードで適用しようとします (Remote Code Execution Vulnerabilities in Ingress NGINX | Wiz Blog)。すると、設定中のssl_engine命令が実行され、指定されたパスにある共有ライブラリ（攻撃者がアップロードした.soファイル）がロードされます (Critical Ingress NGINX Controller Vulnerability Allows RCE Without Authentication)。共有ライブラリのinit処理として用意された任意の悪意あるコードがここでIngress Controllerのプロセス内で実行されます。
Ingress Controller乗っ取り: 攻撃者のコードがIngress Controller内で実行されたことで、攻撃者はそのコンテナ上で自由に動けるようになります。例えば、Ingress Controllerのサービスアカウントに付与された権限を用いてKubernetes APIにアクセスし、Secretリソースを読み取ることが可能です (Critical Ingress NGINX Controller Vulnerability Allows RCE Without Authentication)。あるいは直接ファイルシステム上のSecretトークンや設定ファイルを読み出すこともできます。最終的に攻撃者は取得した資格情報や秘密鍵を使ってさらに踏み込み、クラスタ管理者権限の奪取や他のコンポーネントへの横展開を行います (Critical Ingress NGINX Controller Vulnerability Allows RCE Without Authentication)。場合によっては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®)）。重要なのは、攻撃者がクラスタ内で低い権限（たとえば1つのコンテナを乗っ取った程度）しか持っていなくても、この脆弱性を組み合わせることで一気にクラスタ全体を支配し得る点です (Critical Ingress NGINX Controller Vulnerability Allows RCE Without Authentication) (Critical Ingress NGINX Controller Vulnerability Allows RCE Without Authentication)。また、前述のようにIngressのAdmissionサービスが誤ってインターネットに露出している場合は、攻撃者はクラスタ内に侵入する必要すらなく直接この脆弱性を突いてRCEを発生させられるため、被害の可能性はさらに高まります (Remote Code Execution Vulnerabilities in Ingress NGINX | Wiz Blog)。

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

Kubernetesプロジェクトは本脆弱性の報告を受け、2025年3月24日付けでIngress NGINX Controllerのアップデート版(v1.11.5およびv1.12.1)をリリースしました (Ingress-nginx CVE-2025-1974: What You Need to Know | Kubernetes)。これらのバージョンでは、Wizが指摘した5件の脆弱性すべてに対処済みであり、利用者は速やかにアップグレードすることが推奨されています (Ingress-nginx CVE-2025-1974: What You Need to Know | Kubernetes)。特にCVE-2025-1974に関しては、問題のAdmission Controller部分に大きな改修が加えられました。具体的には、Ingressの設定検証時に実行していたnginx -tによる設定テストを一時的に無効化し、将来的に安全なサンドボックス環境下でのみ実行できるよう対応する旨がソースコード上でコメントされています (Controller: Several security fixes. by Gacko · Pull Request #13068 · kubernetes/ingress-nginx · GitHub)。この修正により、攻撃者が不正な設定を注入してもコード実行に至る経路が遮断され、CVE-2025-1974の直接的な悪用は困難になりました。加えて、他のInjection系脆弱性（CVE-2025-1097, 1098, 24514）についても注釈値の正規表現チェック強化や不正文字をエスケープする処理が追加され、任意のNGINX設定を埋め込めないよう改善されています (Critical Ingress NGINX Controller Vulnerability Allows RCE Without Authentication) (Critical Ingress NGINX Controller Vulnerability Allows RCE Without Authentication)。パストラバーサルの脆弱性（CVE-2025-24513）についても、Secretファイルパスの扱いを見直すことで修正されています (Critical Ingress NGINX Controller Vulnerability Allows RCE Without Authentication)。

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

公式の発表によると、この脆弱性はKubernetes Security Response CommitteeとIngress-NGINXメンテナ（Marco Ebert氏、James Strong氏ら）が中心となって対応が行われました (CVE-2025-1974: ingress-nginx admission controller RCE escalation · Issue #131009 · kubernetes/kubernetes · GitHub)。脆弱性報告者であるWizの研究者（Nir Ohfeld氏ら）との協力のもと、報告から約3ヶ月の調整期間を経て公開・修正に至っています (Remote Code Execution Vulnerabilities in Ingress NGINX | Wiz Blog) (Remote Code Execution Vulnerabilities in Ingress NGINX | Wiz Blog)。Kubernetes公式ブログでも本件に関する詳細な説明とアップグレードの呼びかけが行われており、利用者に対し**「直ちに対策を講じるように」**と強調しています (Ingress-nginx CVE-2025-1974: What You Need to Know | Kubernetes)。

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

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

Admission Controller機能の一時無効化: 影響部分であるValidating Admission Controllerをオフにすることで、脆弱性の悪用経路を遮断できます (Ingress-nginx CVE-2025-1974: What You Need to Know | Kubernetes)。HelmでIngress NGINX Controllerを導入している場合は、controller.admissionWebhooks.enabled=falseという値を設定して再デプロイします (Ingress-nginx CVE-2025-1974: What You Need to Know | Kubernetes)。マニフェストを直接適用している場合は、リソースからValidatingWebhookConfiguration(ingress-nginx-admission)を削除し、Ingress ControllerのDeployment/DaemonSetの起動引数から--validating-webhookオプションを取り除きます (Ingress-nginx CVE-2025-1974: What You Need to Know | Kubernetes)。これによりAdmission Webhookサーバが停止し、本脆弱性を突く経路は事実上なくなります（ただしIngressの正当性チェックも無効化されるため、アップグレード後に再度有効化することが望まれます (Ingress-nginx CVE-2025-1974: What You Need to Know | Kubernetes)）。
ネットワークアクセスの制限: 本来、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)。現状Ingress NGINXは特に制限なくServiceを公開していたためこのような攻撃が成立しましたが、ネットワークレベルで遮断しておくと仮に脆弱性が残っていても悪用難度が大きく上がります。
権限と設定の見直し: Ingress NGINX Controllerに限らず、クラスタ内で動作するコンポーネントには**最小権限の原則（least privilege）を適用すべきです (Remote Code Execution Vulnerabilities in Ingress NGINX | Wiz Blog)。デフォルトの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)。今後同様の脆弱性に備え、各種コントローラの権限や公開インターフェースについて監査・見直しを行うことが重要です。
監視と検知: 現時点で既知の侵害指標(IOC)は無いものの、クラスタのログ中に不審なAdmissionReviewリクエストやIngress Controllerコンテナ内の予期しないプロセス実行痕跡がないかをモニタリングすることも有用です。不正なIngress作成を試みた形跡（失敗したWebhook呼び出し等）や、Ingress Controllerの挙動異常（再起動ループや想定外のネットワーク接続）が見られた場合、念のため調査を行ってください。

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

出典:

Kubernetes公式ブログ: “Ingress-nginx CVE-2025-1974: What You Need to Know” (Ingress-nginx CVE-2025-1974: What You Need to Know | Kubernetes) (Ingress-nginx CVE-2025-1974: What You Need to Know | Kubernetes) (Ingress-nginx CVE-2025-1974: What You Need to Know | Kubernetes) (Ingress-nginx CVE-2025-1974: What You Need to Know | Kubernetes)
Wiz Researchブログ: “IngressNightmare: 9.8 Critical Unauthenticated Remote Code Execution Vulnerabilities in Ingress NGINX” (Remote Code Execution Vulnerabilities in Ingress NGINX | Wiz Blog) (Remote Code Execution Vulnerabilities in Ingress NGINX | Wiz Blog) (Remote Code Execution Vulnerabilities in Ingress NGINX | Wiz Blog) (Remote Code Execution Vulnerabilities in Ingress NGINX | Wiz Blog) (Remote Code Execution Vulnerabilities in Ingress NGINX | Wiz Blog) (Remote Code Execution Vulnerabilities in Ingress NGINX | Wiz Blog)
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) (CVE-2025-1974: ingress-nginx admission controller RCE escalation · Issue #131009 · kubernetes/kubernetes · GitHub) (CVE-2025-1974: ingress-nginx admission controller RCE escalation · Issue #131009 · kubernetes/kubernetes · GitHub)
The Hacker News: “Critical Ingress NGINX Controller Vulnerability Allows RCE Without Authentication” (Critical Ingress NGINX Controller Vulnerability Allows RCE Without Authentication) (Critical Ingress NGINX Controller Vulnerability Allows RCE Without Authentication) (Critical Ingress NGINX Controller Vulnerability Allows RCE Without Authentication) (Critical Ingress NGINX Controller Vulnerability Allows RCE Without Authentication)
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®) (CVE-2025-1097, CVE-2025-1098, CVE-2025-1974, CVE-2025-24513, CVE-2025-24514: Frequently Asked Questions About IngressNightmare - Blog | Tenable®) (CVE-2025-1097, CVE-2025-1098, CVE-2025-1974, CVE-2025-24513, CVE-2025-24514: Frequently Asked Questions About IngressNightmare - Blog | Tenable®)
NVD (MITRE) CVEエントリ: CVE-2025-1974 (NVD - CVE-2025-1974)