Critical Security Flaws Uncovered in Ingress NGINX Controller: Act Now to Protect Your Kubernetes Clusters.
A set of critical security vulnerabilities has been discovered in the Ingress NGINX Controller for Kubernetes, posing a significant risk to a large number of clusters. Baptised as IngressNightmare by researchers at Wiz, these flaws could allow unauthenticated remote code execution (RCE), potentially leading to complete takeover of your Kubernetes environment.
This article details the vulnerabilities, their potential impact, and the crucial steps you need to take immediately.
Understanding the Threat: IngressNightmare
The Ingress NGINX Controller is a popular tool for exposing applications running within a Kubernetes cluster to the outside world, acting as a reverse proxy and load balancer based on the widely used NGINX web server.
It is deployed in a significant portion of Kubernetes clusters, with estimates suggesting over 40% of cloud environments are vulnerable.
The newly disclosed vulnerabilities, assigned CVSS scores as high as 9.8, collectively threaten the security of these deployments.
These shortcomings specifically affect the admission controller component of the Ingress NGINX Controller for Kubernetes and do not impact the standard NGINX Ingress Controller
The Core Vulnerabilities
Five key vulnerabilities have been identified:
• CVE-2025-1974 (CVSS: 9.8): This critical vulnerability allows an unauthenticated attacker with network access to the pod to achieve arbitrary code execution in the ingress-nginx controller under specific conditions.
This flaw can be chained with the other vulnerabilities to achieve cluster takeover without requiring any credentials or administrative privileges.
• CVE-2025-24514 (CVSS: 8.8): Exploitation of the auth-url Ingress annotation allows for configuration injection into NGINX, resulting in arbitrary code execution within the ingress-nginx controller’s context and the potential disclosure of secrets accessible to it.
Notably, Wiz states this does not affect version 1.12.0, while the vendor indicates it does.
• CVE-2025-1097 (CVSS: 8.8): Similar to CVE-2025-24514, this vulnerability leverages the auth-tls-match-cn Ingress annotation for NGINX configuration injection, again leading to arbitrary code execution and secret disclosure.
This may require a TLS certificate/keypair secret to be specified via the nginx.ingress.kubernetes.io/auth-tls-secret annotation.
• CVE-2025-1098 (CVSS: 8.8): The mirror-target and mirror-host Ingress annotations can be used to inject arbitrary NGINX configurations, leading to arbitrary code execution within the controller and the disclosure of secrets.
The ingress object’s UID is the injection point here.
• CVE-2025-24513 (CVSS: 4.8): An improper input validation vulnerability that could permit directory traversal within the container. This could lead to denial-of-service (DoS) or, when combined with other vulnerabilities, limited disclosure of secret objects.
The Attack Vector: Exploiting the Admission Controller
The Ingress NGINX Controller includes an admission controller that validates incoming ingress objects before they are deployed. Critically, this admission controller is accessible over the network without authentication, making it a prime target for malicious actors.
The vulnerabilities arise because the admission controller constructs NGINX configurations from ingress objects and then validates them using the nginx -t command
Researchers at Wiz discovered multiple methods to inject arbitrary NGINX configuration directives during this validation process by sending specially crafted ingress objects (AdmissionReview requests) directly to the admission controller.
Achieving Remote Code Execution
The path to full Remote Code Execution involves a clever technique:
1. Malicious Payload Upload: An attacker can upload a malicious payload in the form of a shared library to the Ingress NGINX Controller’s pod.
This can be achieved by abusing the client-body buffer feature of NGINX. By sending a large HTTP request with the malicious library in the body, NGINX might temporarily save it to the pod’s filesystem.
2. File Descriptor Persistence: Even if NGINX removes the temporary file, an open file descriptor to it remains accessible via the /proc filesystem (ProcFS).
3. Configuration Injection: The attacker then sends an AdmissionReview request containing one of the aforementioned configuration injection vulnerabilities (e.g., via auth-url, auth-tls-match-cn, mirror-host/mirror-target annotations, or the ingress UID) to the admission controller.
4. Shared Library Loading: The injected configuration leverages the ssl_engine directive (part of the OpenSSL module in NGINX) to load the shared library from its ProcFS path. This directive can be used at any point in the configuration, unlike load_module. This behaviour of ssl_engine for loading shared libraries is reportedly undocumented.
5. Remote Code Execution: If successful, the malicious shared library is loaded, leading to arbitrary code execution within the context of the Ingress NGINX Controller’s pod.
Critical Impact: Cluster Takeover
Successful exploitation of these vulnerabilities grants the attacker the privileges associated with the Ingress NGINX Controller pod.
By default, this often includes access to all secrets stored across all namespaces in the Kubernetes cluster. This level of access can easily lead to a complete takeover of the entire Kubernetes cluster.
Wiz’s research identified over 6,500 clusters with publicly exposed Ingress NGINX Controllers, highlighting the immediate risk.
Furthermore, they estimate that around 43% of cloud environments are vulnerable to these issues.
Immediate Actions and Mitigation
Immediate patching is critical. The vulnerabilities have been addressed in the following Ingress NGINX Controller versions:
• Version 1.12.1
• Version 1.11.5
• Version 1.10.7
Users are strongly advised to upgrade to one of these latest versions as soon as possible.
If an immediate upgrade is not feasible, consider these mitigation strategies:
• Ensure the admission webhook endpoint is not exposed externally
• Limit network access to the admission controller so that only the Kubernetes API Server can communicate with it.
• Temporarily disable the admission controller component if it is not immediately required.
◦ For Helm installations: Reinstall Ingress NGINX Controller setting the Helm value 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 quality-of-life improvements and warnings about incorrect Ingress configurations.
Checking for Ingress NGINX Controller
To determine if your clusters are using the vulnerable Ingress NGINX Controller, run the following command with cluster administrator permissions:
kubectl get pods --all-namespaces --selector app.kubernetes.io/name=ingress-nginx
Responsible Disclosure
These critical vulnerabilities were discovered and responsibly disclosed by Nir Ohfeld, Sagi Tzadik, Ronen Shustin, and Hillai Ben-Sasson from Wiz Research.
Their collaboration with the Kubernetes Security Response Committee and the Ingress NGINX maintainers was crucial in addressing these issues.
Conclusion: Prioritise Patching
The IngressNightmare vulnerabilities represent a severe threat to Kubernetes clusters utilising the Ingress NGINX Controller. The potential for unauthenticated remote code execution and complete cluster takeover demands immediate attention. Prioritise upgrading your Ingress NGINX Controller to the latest patched versions without delay. Implementing the suggested mitigation strategies can provide a temporary layer of defence if immediate patching is not possible. The discovery highlights the importance of secure configuration practices and the need for continuous vigilance in Kubernetes environments.
For further information: CVE-2025-24513, CVE-2025-24514, CVE-2025-1097, CVE-2025-1098 and CVE-2025-1974