We missed the boat on “IngressNightmare” but then, given how poor patch management is in many environments, it’s possible you did too.
Let’s go through it together in case you also missed the memo on this string of critical Kubernetes vulnerabilities that widely expose clusters.
A working exploit is now publicly available and as of March 27, 2025, 4,500 Kubernetes clusters were exposed to potential pre-authentication, remote code execution attacks – with no need to be on a pod network.
Kubernetes vulnerability: “IngressNightmare” in brief.
1) There’s a string of nasty vulnerabilities that under certain circumstances expose Kubernetes clusters to remote takeover. Over 6,500 clusters, including Fortune 500 companies, were initially exposed, claims security firm Wiz, which disclosed the bugs. (It first reported the vulnerabilities in December 2024. They were patched upstream on February 7 by Kubernetes’ maintainers. An embargo lifted on March 24.)
2) Kubernetes maintainers said in a March 24 blog that the worst of the vulnerabilities, CVE-2025-1974, “means that anything on the Pod network [our italics] has a good chance of taking over your Kubernetes cluster, with no credentials or administrative access required. In many common scenarios, the Pod network is accessible to all workloads in your cloud VPC, or even anyone connected to your corporate network!” Yikes.
See also: A NASDAQ-listed firm left its Kubernetes clusters perilously exposed. 1,000+ have fallen into the same trap. Here’s why
3) The vulnerabilities (also allocated CVE-2025-1097, CVE-2025-1098, CVE-2025-24514) affect ingress-nginx. That’s software provided by the Kubernetes project that is deployed in over 40% of Kubernetes clusters. It is a suggested ingress controller in the official Kubernetes documentation, and it helps users map traffic to different application backends. (The service account used by ingress-nginx gets sweeping permissions.)
“Exploitation relies on an attacker's ability to reach the ingress controller's admission webhook endpoint. If the ingress controller's admission webhook is exposed to the internet, any remote attacker can compromise it. [Yes, plenty of people do expose this as Wiz found.] In the more common case where the admission webhook is exposed internally, it still allows for privilege escalation from any pod, because pods can communicate with each other by default.” – The Datadog security team
Cloud exposure?
4) AWS’s EKS does “not provide or install the ingress-nginx controller” and are not affected by default, but as AWS warned, “customers who have installed this controller on their clusters should update to the latest version.” (It has proactively contacted those who are potentially exposed.) Microsoft Azure’s AKS managed Kubernetes service is affected if customers are using the managed NGINX ingress with the application routing add-on and as with AWS, if users have installed the ingress-nginx controller; it is rolling out patches. Google’s GKE again does not use it by default, but ditto: customers may have installed it and will need to patch.
Despite security fixes having landed in early February, there still appear to be over 4,500 Kubernetes clusters exposed to potential pre-auth RCE attacks claims Carlos Vieira, the head of threat research at Brazil-based Hakai Security. Kubernetes users should follow guidance from their security partners or refer to resources from the likes of Wiz, Datadog, Dynatrace et al to check for exposure and swiftly remediate. With an exploit now publicly available weaponisation by cybercriminals and/or APTs is likely to follow.
As The Stack published there was no evidence of exploitation in the wild yet but threat hunters, at bare minimum, should look out for things like requests to get or list all secrets or configmaps of the entire cluster (for example, no namespace is defined in the requests) in K8s audit logs.
