In March 2025, Wiz Research disclosed a chain of vulnerabilities in ingress-nginx — the default ingress controller for a large share of production Kubernetes clusters — that let an unauthenticated attacker on the pod network execute arbitrary code inside the controller and pivot to every Secret in the cluster. That flaw, nicknamed IngressNightmare and tracked as CVE-2025-1974 (CVSS 9.8), wasn't an isolated incident. Ingress-nginx alone has carried at least seven notable CVEs since 2021, and competing controllers like Apache APISIX and Traefik have had their own critical bugs. Because ingress controllers sit at the network edge with broad RBAC permissions and terminate TLS for everything behind them, a single misconfigured annotation or unpatched admission webhook can turn an internet-facing HTTP request into full cluster compromise. This roundup walks through the vulnerabilities that mattered most, what made them exploitable, and how to check whether your clusters are still exposed.
What is IngressNightmare and why did it score a 9.8?
IngressNightmare is the name Wiz Research gave to a chain of five CVEs — CVE-2025-1974, CVE-2025-1097, CVE-2025-1098, CVE-2025-24513, and CVE-2025-24514 — disclosed on March 24, 2025, that together allow unauthenticated remote code execution inside the ingress-nginx controller pod. The root cause is that ingress-nginx's validating admission webhook renders untrusted Ingress object fields (including annotations like auth-tls-match-cn and custom configuration snippets) into an actual nginx configuration file and test-loads it via nginx -t inside the controller process. Because the admission webhook endpoint is typically reachable from anywhere on the pod network without authentication — it's designed to accept calls from the Kubernetes API server, not to verify who's calling — an attacker who can reach that port can submit a crafted Ingress resource, trigger SSRF-style config injection, and get their own code to run as the controller's service account. That account commonly has read access to every Secret in the cluster, so the practical impact is total cluster takeover, not just a compromised pod. The fix shipped in ingress-nginx 1.12.1 and 1.11.5.
How many clusters were actually exposed to this?
Wiz's internet-wide scan found that roughly 43% of cloud environments it assessed had the ingress-nginx admission controller reachable in a way that made them vulnerable to IngressNightmare, and thousands of clusters had the webhook port exposed directly to the internet rather than restricted to the API server's IP range. Ingress-nginx is installed by default or by convention in a large fraction of managed Kubernetes deployments across AWS, Azure, and GCP, which is what made this a fleet-wide problem rather than a niche one. The Kubernetes project's own guidance in response was blunt: restrict network access to the ingress-nginx-controller-admission webhook to the API server only, or disable the validating admission controller entirely if you don't rely on it, in addition to patching. Teams that had never audited which pods could reach port 8443 on their ingress controller found out during incident response that the answer was often "most of the cluster."
What made the 2021 ingress-nginx annotation CVEs different?
CVE-2021-25742, CVE-2021-25743, and CVE-2021-25746 showed that ingress-nginx's most flexible feature — free-text annotations — was also its biggest liability, three years before IngressNightmare made the same point at cluster scale. CVE-2021-25742 allowed the nginx.ingress.kubernetes.io/configuration-snippet annotation to inject arbitrary nginx directives, including Lua code via the access_by_lua_block mechanism, letting a user with permission to create Ingress objects in one namespace read Secrets or execute code affecting the whole controller — a serious problem in multi-tenant clusters where namespace isolation is assumed. CVE-2021-25743 let a crafted path field bypass path validation and override other tenants' Ingress rules. CVE-2021-25746 let a user without RBAC access to Secrets in other namespaces still reference and exfiltrate a TLS Secret by name. All three were patched in ingress-nginx 1.0.0 in mid-2021, but snippet-based injection kept resurfacing: CVE-2023-5043 and CVE-2023-5044 hit the same configuration-snippet and permanent-redirect annotations again in 2023, which is why the project eventually shipped a global allow-snippet-annotations=false default in ingress-nginx 1.9, effectively removing the feature rather than continuing to patch around it.
Did the January 2023 path sanitization bug bypass authentication?
Yes — CVE-2022-4886 let attackers bypass auth-url external authentication annotations in ingress-nginx by exploiting how backslashes were handled in request paths, and it carried a CVSS score of 8.8. Ingress-nginx supports an nginx.ingress.kubernetes.io/auth-url annotation that many teams use to enforce authentication at the ingress layer before a request ever reaches an internal service — a common pattern for protecting internal admin panels or APIs that don't have their own auth. The bug meant a specially crafted path containing backslash sequences could be normalized differently by nginx's internal routing than by the annotation's path-matching logic, so a request that looked like it was hitting an authenticated route could actually reach an unauthenticated backend path instead. Any team relying on ingress-level auth as a substitute for application-level auth was directly affected. It was fixed in ingress-nginx 1.6.4, released in December 2022, and is a clear example of why edge-layer authentication should be treated as defense-in-depth rather than a sole control.
Is this only an ingress-nginx problem, or do other controllers have the same risk?
No — Apache APISIX's ingress controller had its own critical, maximum-severity flaw in CVE-2022-24112, a CVSS 10.0 vulnerability disclosed in March 2022 that allowed full remote code execution via the Admin API. The bug lived in the batch-requests plugin, which was enabled by default in some deployments: it let an attacker craft a request that APISIX's internal proxying treated as originating from 127.0.0.1, bypassing IP-based access control lists that were supposed to restrict the sensitive Admin API to localhost only. Once the Admin API was reachable, an attacker could use its scripting feature to run arbitrary Lua and, from there, arbitrary system commands. It was fixed in Apache APISIX 2.12.1. Traefik and HAProxy Ingress have each had lower-severity path-handling and header-injection issues over the same period. The pattern across all of them — ingress-nginx, APISIX, and others — is the same: ingress controllers combine internet-facing exposure, flexible scripting or annotation features, and elevated cluster permissions, which is exactly the combination that turns a parsing bug into a cluster-wide breach.
How can a security team tell if their ingress controller is currently exploitable?
Start by checking the running image tag against the fixed versions for your controller — for ingress-nginx that means confirming you're on 1.12.1, 1.11.5, or later, and on 1.9+ if you depend on snippet annotations being disabled by default rather than manually locked down. Run kubectl get pods -n ingress-nginx -o jsonpath='{.items[*].spec.containers[*].image}' to see the exact image and tag in use, and cross-reference it against the ingress-nginx GitHub security advisories rather than assuming a "latest" tag is current. Separately, audit network policy around the admission webhook port (8443 by default) to confirm it's reachable only from the API server's egress range, and review every configuration-snippet, auth-url, and permanent-redirect annotation currently in use across your Ingress objects for anything that looks like it's smuggling logic rather than configuration. None of this is a one-time check — ingress-nginx has shipped security patches in most years since 2021, so the controller needs to be in the same continuous vulnerability-scanning rotation as every other piece of internet-facing infrastructure.
How Safeguard Helps
Safeguard's reachability analysis is built for exactly this class of problem: rather than flagging every ingress controller CVE in your fleet as equally urgent, it traces whether the vulnerable code path — the admission webhook, the snippet-annotation renderer, the affected plugin — is actually reachable given your cluster's network policy and RBAC configuration, so IngressNightmare-style findings get prioritized correctly instead of buried in a generic CVE feed. Griffin AI correlates that reachability data with real exploit activity and your deployment topology to tell you which clusters need an emergency patch this week versus which are already isolated. Safeguard also generates and ingests SBOMs across your Kubernetes workloads so ingress controller versions are tracked automatically as new advisories land, and where a fix is available, it opens an auto-fix pull request bumping the controller to the patched version and tightening the admission webhook's network policy in the same change, cutting the gap between disclosure and remediation from weeks to hours.