IngressNightmare — Critical Kubernetes NGINX Vulnerability Puts Clusters at Risk

If you’re running Kubernetes with the ingress-nginx controller — and statistically, there’s a good chance you are — stop reading this and patch first. The set of vulnerabilities collectively dubbed “IngressNightmare” by the researchers at Wiz is as bad as it sounds: unauthenticated remote code execution that can lead to full cluster takeover. This is a CVSS 9.8, and it deserves your immediate attention.

The Vulnerability Chain

#

IngressNightmare isn’t a single vulnerability but a chain of issues (CVE-2025-1974, CVE-2025-1097, CVE-2025-1098, CVE-2025-24514) that, when combined, allow an attacker with network access to the admission controller to achieve remote code execution without any authentication.

The core problem lies in the ingress-nginx admission controller, which validates Ingress objects before they’re applied to the cluster. The controller takes Ingress configuration and passes it through NGINX configuration generation, but certain annotations can be crafted to inject arbitrary NGINX directives. The admission controller runs with elevated privileges — it needs to read secrets across the cluster to configure TLS — which means code execution in this context gives you access to every TLS certificate and secret in the cluster.

The attack flow works roughly like this:

1. An attacker sends a specially crafted AdmissionReview request to the admission controller webhook
2. The malicious Ingress annotations inject directives into the NGINX configuration template
3. When NGINX validates the generated configuration, the injected directives execute arbitrary code
4. The attacker gains a shell with the permissions of the ingress-nginx service account

The particularly nasty aspect is that the admission controller webhook is often exposed on the pod network, meaning any pod in the cluster — or anything that can reach the cluster network — can trigger it. In many cloud environments, the admission webhook endpoint is reachable from within the VPC without additional authentication.

Why This Is Worse Than a Typical CVE

#

Several factors make IngressNightmare especially concerning. First, the prevalence: ingress-nginx is the most popular ingress controller for Kubernetes, used in roughly 40% of clusters according to Wiz’s analysis. That’s an enormous attack surface.

Second, the privilege level: the ingress-nginx controller typically has access to all Secrets in the cluster because it needs to configure TLS. Compromising it doesn’t just give you a foothold — it gives you the keys to the kingdom. TLS private keys, API tokens, database credentials — anything stored as a Kubernetes Secret is potentially exposed.

Third, the stealth factor: the exploit works through the admission webhook, which is a legitimate Kubernetes API endpoint. It doesn’t require creating any persistent resources in the cluster, making it harder to detect through standard audit logging that focuses on resource creation and modification.

The Patch and Mitigation

#

The ingress-nginx team has released patched versions that address all four CVEs. If you’re running ingress-nginx, update to version 1.12.1 or 1.11.5 immediately. Check your installed version:

kubectl get deployment -n ingress-nginx ingress-nginx-controller \
  -o jsonpath='{.spec.template.spec.containers[0].image}'

If you can’t patch immediately, there are mitigations:

Restrict network access to the admission webhook. The admission controller webhook shouldn’t need to be accessible from arbitrary pods. Use NetworkPolicies to limit which sources can reach it:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: restrict-admission-webhook
  namespace: ingress-nginx
spec:
  podSelector:
    matchLabels:
      app.kubernetes.io/name: ingress-nginx
  ingress:
  - from:
    - namespaceSelector: {}
      podSelector: {}
    ports:
    - port: 8443
      protocol: TCP

Disable the admission controller if you’re not actively using it for validation. Remove the ValidatingWebhookConfiguration for ingress-nginx. You lose admission validation, but you eliminate the attack vector.

Audit your annotation usage. The specific annotations exploited include auth-url, auth-tls-match-cn, and custom configuration snippets. If you’re not using these, restrict them via admission policies.

The Bigger Picture: Kubernetes Security Complexity

#

IngressNightmare is a symptom of a broader challenge with Kubernetes security. The platform is extraordinarily flexible, but that flexibility creates a large and complex attack surface. Every controller, operator, and webhook is a potential entry point, and the permissions model — while powerful — makes it easy to grant excessive privileges without realising the implications.

I’ve been working with Kubernetes since the early days, and the security posture of most clusters I encounter still worries me. Common issues include: overly permissive RBAC roles, no network policies (the default is allow-all), secrets stored unencrypted in etcd, and admission controllers running with cluster-admin equivalent permissions.

The ingress controller is particularly critical because it’s the front door — it’s the component that terminates external traffic and routes it into the cluster. Compromising the front door bypasses all the internal security controls you’ve carefully configured.

My Take

#

Every time a vulnerability like IngressNightmare drops, I hear the same refrain: “Kubernetes is too complex.” And there’s truth to that — the operational burden of running Kubernetes securely is substantial. But the answer isn’t to abandon Kubernetes; it’s to invest in understanding and hardening it properly.

What concerns me most about this vulnerability is how many teams are running ingress-nginx in production without understanding the implications of the admission controller’s privilege model. The controller needs broad secret access by design, which means it must be treated as a tier-zero security component — on par with your identity provider and certificate authority.

If this incident motivates you to do one thing, make it this: review the RBAC permissions and network exposure of every admission webhook in your cluster. They’re some of the most privileged components in your infrastructure, and they deserve corresponding security attention.

Patch today. Audit tomorrow. Don’t let this one slip through the backlog.

Part of my Security in Practice series, examining real-world security incidents and what they mean for development and operations teams.