On March 24, 2025, Wiz Research disclosed five critical vulnerabilities in the Ingress NGINX Controller for Kubernetes, grouped under the name IngressNightmare. The most severe, CVE-2025-1974 with a CVSS score of 9.8, allows unauthenticated remote code execution by exploiting an architectural error: the admission controller, a component that should only be reachable from the Kubernetes API Server, is instead network-accessible without authentication. Over 6,500 publicly exposed clusters are at immediate risk, with approximately 43% of cloud environments vulnerable to the IngressNightmare group.
- CVE-2025-1974 (CVSS 9.8) enables unauthenticated RCE for an attacker with access to the pod network, requiring no credentials
- The attack exploits the admission controller exposed by design, violating the Kubernetes threat model that assumes exclusive API Server access
- Over 6,500 clusters are publicly exposed; roughly 43% of cloud environments are vulnerable to the IngressNightmare group
- Patched versions are 1.12.1, 1.11.5, and 1.10.7; the vulnerability does not affect the distinct product NGINX Ingress Controller
The Mechanism: When the Admission Controller Becomes a Service Door
The malicious ingress passes through a component that, by its nature, holds elevated privileges. The Ingress NGINX admission controller validates ingress objects before deployment to ensure the resulting NGINX configuration is correct. According to the Kubernetes threat model, this component should receive requests exclusively from the API Server. Instead, by design, the admission controller is network-accessible without authentication.
An attacker with a presence in the pod network — a condition that arises in compromised multi-tenant environments or breached containers — can send malicious ingress objects, specifically AdmissionReview requests, directly to the admission controller. These objects inject arbitrary NGINX configuration, which in turn loads compromised shared libraries to achieve code execution with the privileges of the ingress controller's service account.
"Exploitation of these vulnerabilities leads to unauthorized access to all secrets stored across all namespaces in the Kubernetes cluster by attackers, which can result in cluster takeover"
— Wiz, report shared with The Hacker News
From a Single Pod to Full Cluster Control
The attack chain does not stop at code execution in the controller context. CVE-2025-1974 can be chained with the other four vulnerabilities in the IngressNightmare group to complete the cluster takeover. The other four — CVE-2025-24513 (CVSS 4.8), CVE-2025-24514 (CVSS 8.8), CVE-2025-1097 (CVSS 8.8), and CVE-2025-1098 (CVSS 8.8) — involve configuration injection via specific annotations in ingress objects.
The Kubernetes Security Response Committee confirmed that CVE-2025-1974 is the specific piece that enables cluster takeover when chained with the others, without requiring credentials or administrative access. The pivot from controller compromise to access to all secrets across all namespaces is made possible by the inherent privileges of the service account, normally required for its function but here converted into an escalation vehicle.
The dossier does not specify whether CVE-2025-1974 is exploitable standalone for full cluster takeover, or whether chaining is always required. It also does not indicate whether attacks in the wild were observed at the time of disclosure.
The Attack Surface: Nightmare Numbers
Wiz Research identified over 6,500 clusters with the admission controller directly exposed to the Internet, a configuration that turns every compromised pod into a potential entry point for full takeover. The figure of roughly 43% of vulnerable cloud environments indicates mass proliferation that exceeds the perimeter of isolated misconfigured deployments.
The severity lies in the combination of three factors: network exposure of a highly privileged component, absence of authentication, and an architectural position that makes it implicitly trusted by the rest of the control plane. It is this interplay that explains why a single design flaw — not an implementation bug in the NGINX code — produces structural impact across thousands of clusters.
The Distinction That Saves: NGINX Ingress Controller Is Untouched
A point the dossier documents clearly: the vulnerabilities do not affect the distinct product NGINX Ingress Controller, a different implementation managed by another vendor. Confusion between the two names — Ingress NGINX Controller and NGINX Ingress Controller — is common in operational practice, but here it has concrete consequences for patching. Teams that verify their version of the correct implementation avoid superfluous actions; those managing the vulnerable product without recognizing it remain exposed.
Why It Matters
The dossier does not specify detailed remediation measures beyond the patched versions. The source indicates two directives: restrict access to the admission controller exclusively to the Kubernetes API Server, and disable the admission controller if not required for cluster operations. The brief does not document procedures for verifying current configuration, detection tools, or suggested rollout timelines.
The dossier also does not detail whether versions prior to the 1.10.x line are vulnerable or simply out of support, nor does it provide the exact responsible disclosure date. It remains unclear how many clusters were actually compromised at the time of publication.
What the document makes evident is the gap between the security model Kubernetes presupposes — an isolated, trusted admission controller — and the reality of deployments where this component is exposed as a generic network service. It is a case of architectural security versus implementation security: the code works as documented, but the design violates the platform's threat model.
Questions and Answers
Are Ingress NGINX Controller and NGINX Ingress Controller the same thing?
No. They are different implementations. The dossier explicitly states that the IngressNightmare vulnerabilities do not affect the distinct product NGINX Ingress Controller.
Why is the CVSS score 9.8 for the vulnerability group as well?
According to the source, the CVSS 9.8 score applies both to CVE-2025-1974 individually and to the IngressNightmare group as a whole, reflecting the maximum severity of the attack chain.
Does the attack require prior pod compromise?
Yes. The documented prerequisite is access to the pod network, which can derive from an already compromised container or other presence in the cluster environment.
Information is based on the cited advisory and current as of publication.
Sources
Information is based on the cited source and current as of publication.