IngressNightmare: critical Kubernetes vulnerabilities in ingress NGINX controller
Take action: If you are running Kubernetes, check if you're affected. If you do run ingress-nginx, this should be treated as an emergency. If you can't implement patches, make sure the ingress-nginx is isolated from the internet, and disable the admission webhook functionality.
Learn More
Wiz Research has discovered a series of critical vulnerabilities in the Ingress NGINX Controller for Kubernetes, collectively dubbed "IngressNightmare." These vulnerabilities represent one of the most serious security issues affecting Kubernetes environments in recent years, potentially allowing attackers to gain full control over affected clusters.
The "IngressNightmare" vulnerabilities consist of multiple unauthenticated Remote Code Execution (RCE) flaws in the admission controller component of Ingress NGINX Controller. Exploitation of these vulnerabilities can lead to unauthorized access to all secrets stored across all namespaces in a Kubernetes cluster, ultimately resulting in complete cluster takeover.
According to research by Wiz, approximately 43% of cloud environments are vulnerable, with over 6,500 clusters (including those of Fortune 500 companies) publicly exposing vulnerable Kubernetes ingress controllers' admission controllers to the internet, putting them at immediate critical risk.
Vulnerability summary
- CVE-2025-1097 (CVSS score 9.8): An injection vulnerability in the Ingress NGINX Controller
- CVE-2025-1098 (CVSS score 9.8): An injection vulnerability in the Ingress NGINX Controller
- CVE-2025-24514 (CVSS score 9.8): An injection vulnerability in the auth-url annotation parser
- CVE-2025-1974 (CVSS score 9.8): A privilege-escalation vulnerability in the admission controller
The attack vector requires no authentication, making it comparable to the widely exploited Log4Shell vulnerability. Only one of the injection vulnerabilities combined with the privilege-escalation flaw is needed to successfully exploit "IngressNightmare."
The vulnerabilities exist in the admission controller component of Ingress NGINX Controller, which validates incoming ingress objects before deployment. By default, these admission controllers are accessible over the network without authentication, making them an appealing attack vector.
When the admission controller processes an incoming ingress object, it constructs an NGINX configuration and validates it using the NGINX binary. The vulnerabilities allow attackers to inject arbitrary NGINX configurations remotely by sending malicious ingress objects directly to the admission controller through the network.
During the configuration validation phase, the injected configuration causes the NGINX validator to execute code, allowing remote code execution on the Ingress NGINX Controller's pod. The controller's elevated privileges and unrestricted network accessibility create a critical escalation path.
The vulnerabilities affect Ingress NGINX Controller versions prior to 1.11.5 and 1.12.1.
The Kubernetes team and Ingress NGINX maintainers have released patches for all vulnerabilities. Users are strongly encouraged to:
- Update to Ingress NGINX Controller version 1.12.1 or 1.11.5 immediately
- Ensure the admission webhook endpoint is not exposed externally
If immediate upgrading is not possible, temporary mitigations include:
- Enforcing strict network policies so only the Kubernetes API Server can access the admission controller
- Temporarily disabling the admission controller component of Ingress-NGINX
- For Helm installations: reinstall with controller.admissionWebhooks.enabled=false
- For manual installations: delete the ValidatingWebhookConfiguration called ingress-nginx-admission and remove the --validating-webhook argument from the ingress-nginx-controller container's Deployment or DaemonSet
Remember to re-enable the Validating Admission Controller after upgrading, as it provides important safeguards for your Ingress configurations.
To check if you are affected: Run kubectl get pods --all-namespaces --selector app.kubernetes.io/name=ingress-nginx with cluster administrator permissions to identify if your clusters use Ingress NGINX.