In March 2025, security researchers disclosed one of the most severe Kubernetes vulnerabilities in years. Dubbed IngressNightmare, this group of vulnerabilities could allow an attacker to completely take over a Kubernetes cluster — no credentials, no administrative access required. Just network access. If your business runs containerized workloads in the cloud, this is required reading.
IngressNightmare refers to a group of five vulnerabilities in the Kubernetes Ingress-NGINX Controller — one of the most widely deployed components in Kubernetes environments. Disclosed on March 24, 2025 by researchers from Wiz, Inc., these vulnerabilities affect organizations running Kubernetes on AWS EKS, Azure AKS, Google GKE, and self-managed clusters.
The five CVEs in the group are: CVE-2025-1974, CVE-2025-1097, CVE-2025-1098, CVE-2025-24513, and CVE-2025-24514. The most critical is CVE-2025-1974, which carries a CVSS score of 9.8 out of 10.
CVE-2025-1974 is remotely exploitable, requires no privileges, requires no user interaction, and has high impact on confidentiality, integrity, and availability. This is as serious as vulnerabilities get.
The Ingress-NGINX Controller includes an admission webhook — a component that validates and modifies Kubernetes configuration objects before they are applied to the cluster. CVE-2025-1974 allows an attacker with only network access to this webhook endpoint to achieve Remote Code Execution (RCE) inside the ingress controller pod.
Once inside that pod, combined with the other vulnerabilities in the group, the attacker can read all Kubernetes secrets stored across all namespaces in the cluster. Kubernetes secrets contain database credentials, API keys, TLS certificates, and service account tokens — effectively everything your cluster depends on.
An attacker needs only network access to the admission webhook — a single endpoint — to potentially own your entire cluster. No credentials. No phishing. No insider access. Just network reach and a known exploit.
The Ingress-NGINX Controller handles inbound HTTP/HTTPS traffic routing — the kind of component that gets deployed once and quietly runs for years without updates. That is exactly what makes it so dangerous when a critical vulnerability appears.
| Version | Status | Action Required |
|---|---|---|
| Ingress-NGINX < v1.11.5 | Vulnerable | Upgrade to v1.11.5+ immediately |
| Ingress-NGINX < v1.12.1 | Vulnerable | Upgrade to v1.12.1+ immediately |
| Ingress-NGINX v1.11.5 or later | Patched | No action needed for this CVE |
| Ingress-NGINX v1.12.1 or later | Patched | No action needed for this CVE |
To check your current version, run: kubectl get pods -n ingress-nginx -o yaml | grep image:
If your cluster uses Ingress-NGINX and has not received a maintenance update since February 2025, treat your cluster as vulnerable until confirmed otherwise.
IngressNightmare illustrates a pattern that repeats in cloud-native security: critical infrastructure components get deployed, integrated, and left to run without updates. Ingress controllers are infrastructure plumbing. But plumbing in your Kubernetes cluster needs the same patching discipline as your application code.
Kubernetes security is a shared responsibility. The cluster platform, your deployment configurations, your network policies, and your security team all play a role. Third-party components like ingress controllers must be part of your patch management process — not treated as set-and-forget infrastructure.
SecureCID provides cloud infrastructure security assessments that cover the infrastructure layer below your applications — the layer that is often most overlooked and most dangerous when vulnerabilities emerge.