IngressNightmare was a chain of vulnerabilities in the Kubernetes Ingress NGINX Controller, not a defect in Kubernetes as a whole. At disclosure in March 2025, Kubernetes said more than 40% of clusters used the controller; Wiz separately estimated that about 43% of cloud environments were vulnerable. Those figures describe adoption and potential exposure—not confirmed compromises. Ingress NGINX has since been retired, with upstream maintenance ending in March 2026, so affected operators need to consider both the original patches and a move to a maintained alternative.
What IngressNightmare affected
Ingress NGINX is a software component that implements Kubernetes Ingress rules. Ingress resources describe how applications should be exposed to network traffic; the controller translates those rules into NGINX configuration and routes requests to services and pods. The vulnerability chain was in this controller’s admission and configuration-handling path, not in every Kubernetes cluster automatically.
Wiz Research described four IngressNightmare vulnerabilities: CVE-2025-1097, CVE-2025-1098, CVE-2025-24514 and CVE-2025-1974. The Kubernetes advisory announced fixes for five vulnerabilities on March 24, 2025, adding CVE-2025-24513 to the release set. Wiz specifically noted that CVE-2025-24513 is different and does not lead to remote code execution (RCE). Kubernetes’ March 24 advisory and Wiz’s IngressNightmare analysis describe the chain and its impact.
How the vulnerabilities could be exploited
The core risk involved unsafe handling of configuration by the validating admission controller. Wiz explained that configuration injection combined with the ability to load a shared library while NGINX tested configuration could enable RCE. The Kubernetes advisory said CVE-2025-1974 could let an attacker on the pod network exploit configuration-injection vulnerabilities through the Validating Admission Controller feature. Combined with the other flaws, exploitation could potentially lead to cluster takeover without credentials or administrative access.
#1 Best Overall
Ingress NGINX has access to cluster-wide secrets by default, which helps explain the possible severity. Wiz rated the attack vector for CVE-2025-1974 at 9.8 on CVSS v3.1. The advisory notes that pod-network reachability can include workloads in a cloud VPC or people connected to a corporate network. Wiz also identified publicly exposed vulnerable admission controllers as a particularly serious condition. This does not mean every Kubernetes cluster was exposed to the public internet, nor does potential impact establish that a cluster was compromised.
What the “40%” figure means
The headline’s percentage refers to reported scale, not a tally of successful attacks. In its March 24, 2025 advisory, the Kubernetes Security Response Committee said over 40% of Kubernetes clusters used Ingress NGINX. Wiz’s 2025 research estimated that about 43% of cloud environments were vulnerable and reported finding more than 6,500 clusters, including clusters with publicly exposed vulnerable admission controllers.
These are differently framed measures: Kubernetes reported controller use among clusters, while Wiz estimated vulnerability across cloud environments and described clusters it found. Neither figure means that 40% or 43% of environments were compromised. CyberScoop’s headline used “more than 40% of cloud environments,” but the Kubernetes advisory and Wiz’s account make the underlying attribution and distinction clearer: CyberScoop’s report.
What administrators were told to do in March 2025
At disclosure, Kubernetes advised administrators to identify Ingress NGINX deployments and upgrade promptly. Its March 24, 2025 advisory named v1.12.1 and v1.11.5 as fixed releases for all five announced vulnerabilities. The inventory command it provided was:
Free tools Windows power users keep installed
One-click scans. No signup required.
Rank #3
kubectl get pods --all-namespaces --selector app.kubernetes.io/name=ingress-nginx
If an immediate upgrade was not possible, the advisory described disabling the Validating Admission Controller as a temporary mitigation for CVE-2025-1974. This was emergency guidance for the March 2025 vulnerability response, not a long-term security plan.
Helm installations
For Helm installations, the advisory’s temporary setting was:
controller.admissionWebhooks.enabled=false
Manual installations
For manual installations, Kubernetes advised deleting the ingress-nginx-admission ValidatingWebhookConfiguration and removing --validating-webhook from the controller deployment or daemonset arguments. The advisory said to restore the feature after upgrading. Because the project is now retired, operators should not treat this temporary workaround as a substitute for moving to a maintained controller.
Ingress NGINX is now retired
On November 11, 2025, Kubernetes SIG Network and the Security Response Committee announced that best-effort maintenance would continue until March 2026. After that, the project would receive no further releases, bug fixes or security updates. Existing deployments would continue to function and installation artifacts would remain available, but availability is not ongoing security support.
The project recommends migrating to Gateway API, described as the modern replacement for Ingress, or to another ingress controller if continuing to use the Ingress API. The retirement notice says, “We recommend migrating to one of the many alternatives.” Read the Kubernetes retirement announcement for the project’s lifecycle guidance.
How to plan a migration
There is no universally preferred replacement established by the project notice. Choose based on your requirements and operating environment, and plan for testing rather than assuming a drop-in change.
Quick Recap
- Support and security: Confirm that the candidate controller has an active maintenance and security-update commitment.
- Manifest compatibility: Check existing Ingress resources and controller-specific annotations; annotations may need changes when switching controllers.
- Traffic requirements: Verify support for the protocols and traffic-management features your workloads actually use.
- Platform fit: Evaluate how the controller fits your cloud or platform operations, deployment model and ownership responsibilities.
- Migration effort: Test representative routes and application behavior, then migrate in stages so problems can be found before broad rollout.
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
