A newly discovered set of five critical vulnerabilities—collectively dubbed IngressNightmare—has sent shockwaves across the Kubernetes ecosystem. These flaws affect the Ingress NGINX Controller, a widely deployed component responsible for managing HTTP(S) traffic routing inside Kubernetes clusters. With a staggering CVSS score of 9.8 assigned to the most severe of the issues, the risks are far from theoretical. According to cloud security firm Wiz, over 6,500 clusters exposed to the public internet may be vulnerable to unauthenticated remote code execution (RCE).
What sets IngressNightmare apart is its impact on the admission controller component of the Ingress NGINX Controller. This component, which should typically be tightly secured, is accessible over the network without authentication in many deployments. The vulnerability chain allows attackers to send crafted AdmissionReview requests directly to the controller, injecting malicious configuration that gets interpreted by NGINX, ultimately enabling code execution inside the controller’s pod.
The consequences are severe. An attacker exploiting these flaws can read all secrets across all namespaces in a Kubernetes cluster—an entry point to a full cluster compromise. The root cause stems from overly permissive network exposure and unsafe handling of NGINX configuration annotations. These include:
- CVE-2025-24513 (CVSS 4.8): Improper input validation, leading to directory traversal and potential secret leakage or denial-of-service when chained.
- CVE-2025-24514, CVE-2025-1097, CVE-2025-1098 (CVSS 8.8 each): Exploitable through
auth-url,auth-tls-match-cn, andmirror-*annotations. These allow injection of arbitrary NGINX configuration, opening the door to RCE. - CVE-2025-1974 (CVSS 9.8): An unauthenticated attacker on the pod network can achieve RCE via remote payload upload and subsequent configuration injection.
The attack scenario is both sophisticated and plausible. By abusing NGINX’s client-body buffer feature, an attacker uploads a shared library containing malicious code. Then, they trigger its execution by pushing an AdmissionReview request containing an injected directive that instructs NGINX to load the shared library. Since the admission controller often runs with elevated privileges and broad access to the cluster, this vector becomes a one-shot path to complete cluster control.
Wiz researcher Hillai Ben-Sasson noted that attackers could abuse a strong Kubernetes Service Account to pivot further, enabling persistent access or lateral movement within cloud environments. The real-world exposure is significant—around 43% of cloud environments run configurations susceptible to these vulnerabilities.
It’s important to distinguish this from other similar-sounding projects. The affected component is the Ingress NGINX Controller, not to be confused with NGINX Ingress Controller or NGINX Plus, which are separate implementations.
Remediation is available: the vulnerabilities have been patched in versions 1.12.1, 1.11.5, and 1.10.7 of the Ingress NGINX Controller. Immediate upgrades are strongly advised. Additionally, clusters should ensure the admission webhook is not publicly accessible. If not actively used, the admission controller component should be disabled as a temporary mitigation.
Limiting network access to the Kubernetes API Server alone for the admission controller is another essential best practice that can reduce risk.
For a deep dive into the vulnerabilities and the full scope of impact, the detailed report from Wiz can be found via The Hacker News.