The vulnerabilities dubbed IngressNightmare can allow unauthenticated users to inject malicious NGINX configurations and execute malicious code into the Ingress NGINX pod, potentially exposing all cluster secrets and leading to cluster takeover.
The Kubernetes project has released patches for five vulnerabilities in a widely used popular component called the Ingress NGINX Controller that’s used to route external traffic to Kubernetes services. If exploited, the flaw could allow attackers to completely take over entire clusters.
“Based on our analysis, about 43% of cloud environments are vulnerable to these vulnerabilities, with our research uncovering over 6,500 clusters, including Fortune 500 companies, that publicly expose vulnerable Kubernetes ingress controllers’ admission controllers to the public internet — putting them at immediate critical risk,” wrote researchers from cloud security firm Wiz who found and reported the flaws.
Collectively dubbed IngressNightmare by the Wiz research team, the vulnerabilities are tracked as CVE-2025-1097, CVE-2025-1098, CVE-2025-24514 and CVE-2025-1974. They were fixed in versions 1.12.1 and 1.11.5 of Ingress NGINX Controller (Ingress-NGINX) released on Monday. A fifth flaw, tracked as CVE-2025-24513, was also identified and patched in these releases.
Unauthenticated ingress configuration injection
Kubernetes is the most popular container orchestration system that’s used to automate the deployment of applications in cloud environments by splitting them into networks of microservices that run independently inside their own secure containers or group of containers called pods.
One of the Kubernetes features that allows exposing workloads to the internet is called ingress and allows admins to route incoming traffic to different backend services based on rules that are defined through the Kubernetes API.
There are multiple ingress controllers available, but Ingress-NGINX which leverages the NGINX web server and reverse proxy, is one of the most popular ones and commonly used as an example in official documentation. According to Wiz, over 41% of internet-facing Kubernetes clusters are running Ingress-NGINX.
The admission controller in Ingress-NGINX is used to process incoming ingress objects, create matching NGINX configurations based on them and then validate them and use them to decide how and where to route requests. The vulnerabilities found by Wiz allow an attacker to inject configuration parameters, which when validated, cause the NGINX validator to execute arbitrary code.
“Proper handling of these NGINX configuration parameters is crucial, because Ingress-NGINX needs to allow users significant flexibility while preventing them from accidentally or intentionally tricking NGINX into doing things it shouldn’t,” the Kubernetes team said in a blog post.
The problem is that the Ingress-NGINX pod has elevated privileges and unrestricted network accessibility by design. More importantly it has access to all Secrets cluster-wide by default, meaning that an attacker with code execution action in this pod can leak those secrets and take over the entire cluster.
The CVE-2025-1974 vulnerability is the most serious and is rated with a severity score of 9.8 on the CVSS scale. It allows anyone with access to the Pod network to exploit the other configuration injection vulnerabilities, which would otherwise require privileged actions to exploit.
“When combined with today’s other vulnerabilities, CVE-2025-1974 means that anything on the Pod network has a good chance of taking over your Kubernetes cluster, with no credentials or administrative access required,” the Kubernetes maintainers warned. “In many common scenarios, the Pod network is accessible to all workloads in your cloud VPC, or even anyone connected to your corporate network! This is a very serious situation.”
Two ways to mitigate the flaws
The best fix is to upgrade the Ingress-NGINX component to one of the patched versions. Admins can determine if it’s being used inside their clusters by typing: kubectl get pods –all-namespaces –selector app.kubernetes.io/name=ingress-nginx
In situations where an immediate version upgrade is not possible, admins can reduce risk by deleting the ValidatingWebhookConfiguration called ingress-nginx-admission and remove the –validating-webhook argument from the ingress-nginx-controller container’s Deployment or DaemonSet. If ingress-nginx was installed using Helm, it can be reinstalled with controller.admissionWebhooks.enabled=false.
This will mitigate CVE-2025-1974 in particular, which makes it much easier to exploit the other vulnerabilities without authentication. However, the Validating Admission Controller should not remain disabled for a long time because it provides safeguards against bad ingress configurations to legitimate users.
Related reading: How to strengthen your Kubernetes defenses
