Overview of Recent Ingress-NGINX Vulnerabilities (IngressNightmare)
Ingress-NGINX Controller – a widely used Kubernetes component for routing external traffic to cluster services – was recently found to contain multiple critical security flaws. In late March 2025, security researchers at Wiz and Datadog publicly disclosed a set of vulnerabilities in the Ingress-NGINX controller, collectively dubbed “IngressNightmare.” These vulnerabilities include one Critical (CVSS 9.8) issue and several High/Medium severity issues. If exploited, they could allow attackers to run arbitrary code on Kubernetes clusters and potentially take over entire clusters, accessing all secrets and sensitive data. Given that Ingress-NGINX is used in a large percentage of cloud Kubernetes environments, this is a serious incident requiring immediate attention. In fact, Wiz’s cloud scan indicated over 40% of environments were vulnerable, with thousands of clusters (including those of Fortune 500 companies) exposing the vulnerable Ingress controller component.
Key vulnerabilities identified in the Ingress-NGINX controller include
Path Traversal Flaw (Medium Severity): An issue in how the ingress controller handles authentication secret file paths (CVE-2025-24513), which could allow an attacker to traverse directories and possibly read or misuse files that should be off-limits. This bug doesn’t directly lead to code execution but can expose sensitive data or configuration.
Multiple Annotation Injection Bugs (High Severity): Several vulnerabilities (CVE-2025-24514, CVE-2025-1097, CVE-2025-1098) in which malicious ingress annotations (such as
auth-url,auth-tls-match-cn, or traffic mirror annotations) are not properly sanitized. An attacker with permission to create or modify Ingress resources could inject arbitrary NGINX configuration directives via these fields. This means a crafted Ingress object can “break out” of expected parameters and insert new settings into the NGINX configuration, potentially leaking data (like service account tokens) or setting the stage for code execution.Admission Controller RCE (Critical): The most severe flaw, CVE-2025-1974, is an issue in the Ingress-NGINX admission controller (a Kubernetes webhook that validates or mutates Ingress objects). This bug allows an attacker to achieve unauthenticated remote code execution (RCE) on the ingress controller pod. In practice, exploiting CVE-2025-1974 can grant an attacker full control over the ingress controller and consequently the entire cluster (“cluster takeover”), even without any valid credentials, provided they can reach the vulnerable admission endpoint.
These issues were discovered by Wiz’s research team (not by any particular vendor’s internal team), and both Wiz and Datadog have published technical analyses to inform the community. The IngressNightmare moniker highlights how multiple small bugs can be chained into a nightmare scenario for cluster security. All Kubernetes users running Ingress-NGINX should be aware of these vulnerabilities and understand their implications.
Severity and Impact
The severity of these vulnerabilities is exceptionally high. The Kubernetes Product Security Committee rated the primary issue as Critical (CVSS 3.1 score 9.8). This rating is justified by the potential impact: a successful exploit can lead to a complete Kubernetes cluster compromise. According to Wiz’s disclosure, exploiting the flaws grants unauthorized access to all secrets in all namespaces of the cluster, effectively allowing an attacker to steal credentials, tokens, and sensitive configuration, and even gain full control over workloads. In a typical Kubernetes environment, that means the attacker could pivot to any service or database running in the cluster, escalate privileges, or even disable security controls.
Equally concerning is the breadth of exposure. The Ingress-NGINX controller is one of the most popular ingress implementations (with tens of thousands of deployments). Wiz Research found that about 43% of cloud Kubernetes environments they analyzed were using a vulnerable version of this controller. Moreover, they identified over 6,500 ingress controller instances that were publicly reachable on the internet – many belonging to large enterprises. These numbers imply a vast number of organizations are at immediate risk, especially those who have not restricted network access to their ingress admission controller.
The potential impact can be summarized as follows:
Cluster Takeover: An external attacker could remotely execute code on the ingress controller pod, which often runs with elevated privileges in the cluster. This could lead to installing malware, creating backdoors, or manipulating cluster services. In Wiz’s tests, compromise of the ingress controller allowed dumping all Kubernetes secrets cluster-wide.
Data Exfiltration: Through the configuration injection flaws, an attacker with some level of access (e.g., the ability to create Ingress objects) could leak sensitive info. For instance, by injecting malicious config, they might redirect traffic or dump environment variables and service account tokens from the ingress pod.
Denial of Service or Lateral Movement: Even without full RCE, messing with ingress controller configuration could break application routing or be used to pivot attacks. For example, the path traversal bug might be abused to read credentials from the controller’s file system, which could then be used to move laterally in the cluster.
Considering how central ingress controllers are to Kubernetes networking, a vulnerability in this component is particularly severe. As Datadog’s report noted, ingress controllers are high-value targets for attackers because compromising one grants a foothold into the cluster’s heart. Similar vulnerabilities (e.g., a 2023 ingress bug CVE-2023-5044) have shown that ingress issues can allow code injection and credential exfiltration if not promptly fixed. In short, the impact ranges from sensitive data loss to full production outage, depending on how attackers leverage these flaws.
How Attackers Could Exploit These Flaws
Understanding how these vulnerabilities can be exploited helps underscore why patching is urgent. In essence, the flaws allow attackers to trick the Ingress-NGINX controller into executing unintended commands or loading malicious configurations by supplying data that the controller mistakenly trusts. Here’s a simplified look at potential exploitation scenarios:
Reaching the Vulnerable Endpoint: The critical RCE (CVE-2025-1974) is exploited by sending a crafted request to the ingress controller’s admission webhook (the component that processes new Ingress resource definitions). In Kubernetes, admission webhooks are normally accessed by the API server, but if the ingress controller’s webhook URL is reachable by an attacker, it becomes an entry point. If it’s exposed publicly (as was the case for many clusters), any remote attacker can directly hit it. Even if it’s not public, by default any pod in the cluster can communicate with any other, so a malicious or compromised pod internally could call the webhook and initiate the exploit. In other words, an attacker doesn’t necessarily need cluster admin privileges – network access to the service is the main requirement.
Abusing Unsanitized Inputs: Several of the vulnerabilities involve injection via annotations – these are user-supplied fields in Kubernetes Ingress objects that control NGINX behavior. The controller was supposed to incorporate these values into its NGINX configuration safely, but due to missing input sanitization, an attacker can insert special characters (like newline
\nor quotation marks) to break out of the expected format. For example, Wiz demonstrated that by setting an Ingress annotationnginx.ingress.kubernetes.io/auth-urlto a value containing a#(comment delimiter) and a newline, they could inject new lines of NGINX configuration beyond what was intended. This means an attacker could smuggle malicious directives into the NGINX config. Such directives could be anything NGINX allows – for instance, enabling dangerous features or redirecting requests to attacker-controlled servers. Essentially, this is akin to a configuration injection attack, comparable to how an attacker might perform an HTTP header injection in a web app to manipulate responses. In this case, the target of injection is the NGINX configuration file generated by the controller.“Header Injection” Trick for Code Execution: To actually achieve code execution (beyond just tweaking config), the attackers combined the config injection with a clever HTTP header manipulation. According to Wiz’s technical post, one step of the exploit is to upload a malicious payload (a shared object library containing attacker code) to the ingress controller pod’s file system. How does one upload a file to an ingress? The researchers abused NGINX’s request buffering behavior. If a client sends a large HTTP request body (>8KB), NGINX will save it to a temporary file on disk. Normally, NGINX deletes this file immediately after use, but by sending a mismatched
Content-Lengthheader (claiming the body is larger than it really is), the attacker can force NGINX to keep the file descriptor open and the file in a partially written state. This is a form of header injection influencing server behavior – the Content-Length header is used to confuse NGINX. The file remains accessible in/proc(the Linux proc filesystem) even after deletion. The attacker doesn’t know the exact file name or descriptor in advance, but since the ingress controller pod has a limited number of processes, it’s feasible to guess or brute-force the file path in/procwhere that payload resides.Environment Variable Poisoning / Configuration Abuse: Another angle an attacker might use is similar to environment variable poisoning. By leveraging the configuration injection vulnerabilities, the attacker could insert malicious values that the ingress controller treats as internal settings or environment data. For instance, the ingress controller’s template might use certain variables (like a path to a secret or certificate). An attacker could craft input (via an annotation or Ingress field) that injects a fake value for such a variable or even inserts a new environment variable into the NGINX config. This could mislead the controller into loading the wrong file (perhaps a sensitive host file or an attacker’s file) or to execute commands it shouldn’t. In effect, the attacker “poisons” the controller’s operating environment by supplying unexpected data that gets trusted. An example from the disclosed bugs is the auth-tls CN annotation injection: by carefully formatting the
auth-tls-match-cnvalue, an attacker can terminate the expected regex and add new NGINX config statements globally. In a similar way, one could imagine injecting a directive that sets an environment variable or points to an alternate file path, achieving a comparable outcome to environment poisoning (though through config rather than OS env variables).Executing the Payload (RCE): Once the attacker has both a malicious file present on the system (via the above upload trick) and the ability to inject config, the final step is to get NGINX to execute the attacker’s code. NGINX has a rarely used directive called
ssl_enginewhich can load a given file as an OpenSSL engine (essentially loading a shared library into the NGINX process). The Wiz researchers injected anssl_enginedirective via the annotation vulnerability, pointing it to the path of their uploaded shared library in the/procfilesystem. When the ingress controller’s NGINX process reloads with this config, it will load the attacker’s library and execute it, giving the attackers a remote shell on the ingress controller pod. This multi-step exploit demonstrates the sophistication of an attack – from HTTP header manipulation (Content-Length) to configuration injection (via unsanitized annotations) to abusing a feature to load code. It’s a powerful illustration of how an attacker can chain seemingly minor bugs into a full-blown compromise.
In summary, an attacker with network access to the ingress controller’s admission endpoint can exploit these vulnerabilities to effectively poison the controller’s configuration environment and inject malicious instructions. This could involve sneaking in malicious HTTP headers or payloads and abusing the controller’s own features against it. Datadog’s overview emphasized that if the admission controller is exposed, a remote attacker directly can execute these steps, and if it’s only internal, a compromised application pod could still perform the attack to escalate privileges. The complexity of the exploit is high, but so is the reward for the attacker – and now that the details are public, motivated threat actors could attempt to automate these attacks. This is why immediate defensive action is crucial.
Recommended Actions: Patching and Mitigation
Both Wiz and Datadog strongly recommend that organizations patch their Ingress-NGINX controllers without delay. The maintainers of Kubernetes Ingress-NGINX have released fixed versions that address these vulnerabilities, and the Kubernetes project as well as major cloud providers (AWS, Google Cloud) have published advisories guiding users to update. Here are the key remediation steps:
Upgrade Ingress-NGINX to a Patched Version: Update your ingress controller to v1.12.1 or later, or v1.11.5 or later (depending on which major branch you are on). These versions contain the fixes for all IngressNightmare CVEs. For example, if you deploy via Helm, use chart version 4.12.1 or above for the 1.12 series, or 4.11.5 or above for the 1.11 series. Upgrading will plug the holes in annotation handling and the admission controller logic that enabled the RCE.
Restrict Access to the Admission Webhook: As an immediate protective measure, ensure the ingress admission controller service is not exposed publicly. It should ideally only be accessible by the Kubernetes API server. If possible, configure network policies or firewall rules so that only the control plane can reach the ingress controller’s webhook. This limits the exploitability of CVE-2025-1974 by outside attackers. (Many clusters accidentally had this webhook open to the internet – closing that door greatly reduces risk.) Likewise, consider network isolation so that only authorized pods (or none, ideally) can talk to the admission service internally, to mitigate insider threats.
Follow Kubernetes and Provider Guidance: Check official sources for patches. The Kubernetes security advisory (on the Kubernetes blog) for these CVEs provides details on the fixes. Cloud-managed Kubernetes services (like EKS, GKE, AKS) have likely issued their own security bulletins; follow those to update managed ingress add-ons. The coordination between Wiz and the Kubernetes team means patches were ready at disclosure time – leverage those efforts by applying them promptly.
Review Ingress Resources and RBAC: Since some vulnerabilities require the attacker to create or edit Ingress objects (for the config injection issues), audit who in your organization has the ability to define Ingress resources. Apply the principle of least privilege – ensure that only trusted system components or admins can add annotations like
auth-urlormirroron ingresses. You might also temporarily restrict creation of Ingress objects if a patch cannot be applied immediately, to reduce the attack surface from within.Monitor for Signs of Exploitation: After patching, it’s wise to check logs for any unusual admission webhook calls or ingress configuration errors. Datadog’s Security Labs suggested looking at ingress-nginx controller logs for suspicious patterns (e.g. unexpected
nginx -toutputs or errors about unknown directives) that could indicate attempted exploitation. If you use a security monitoring tool, set up alerts for strange behavior in the ingress controller pod, such as execution of shell or new processes spawning from the NGINX worker process. Even after securing, retrospective detection can tell you if someone tried (or succeeded) in exploiting the flaw prior to your fix.
Above all, speed is of the essence. These vulnerabilities are now public and proof-of-concept exploits could be developed quickly by attackers. The good news is that the Ingress-NGINX maintainers responded swiftly: as noted, patches are available and Kubernetes’s advisory was released concurrently. Organizations should not delay in applying these fixes and any necessary configuration changes. The cost of waiting – a potential Kubernetes breach – far outweighs the effort of upgrading a controller.
Conclusion: Strengthening Kubernetes Supply Chain Security
The IngressNightmare incident is a stark reminder of the importance of Kubernetes and cloud-native supply chain security. In this case, a component that is part of the standard Kubernetes ecosystem (albeit an optional add-on) contained critical flaws that could have far-reaching impact on clusters. No single application vulnerability would likely grant access to all cluster secrets, but a vulnerability in an ingress controller – which straddles the boundary between external and internal, and runs with elevated privileges – has that dangerous capability. This underlines a few key lessons for engineering leaders and security teams:
Maintain a Vigilant Posture: Treat core Kubernetes infrastructure (ingress controllers, API servers, controllers, etc.) as high-value targets. As Datadog’s researchers noted, defenders should continuously monitor ingress-related components for suspicious activity. Assume that attackers are also eyeing these components. Regular audits and threat modeling of cluster add-ons can help identify where a weakness would be most damaging.
Apply Updates and Patches Proactively: The “flexibility” and extensibility of Kubernetes comes with the responsibility of keeping components up-to-date. Whenever upstream releases a patch for a critical vulnerability, prioritize testing and rolling it out. Ingress-NGINX’s flaws illustrate that a delay in patching could mean leaving a door open to attackers. Proactive patching is a fundamental part of a secure software supply chain.
Enforce Defense in Depth: Not every vulnerability can be prevented, so it’s crucial to have multiple layers of defense. In the context of this incident, even a simple network-level restriction (not exposing the webhook publicly) could save a cluster from compromise. Similarly, careful configuration (like disallowing dangerous annotations via policy) and runtime security tools (that detect anomalies) can provide safety nets. Isolation between pods, strict RBAC, and monitoring are all parts of a layered defense that can contain the blast radius of such issues.
Supply Chain Security Oversight: Kubernetes clusters rely on a supply chain of open-source components (ingress controllers, CNI plugins, etc.). Engineering leaders should ensure there’s insight into what versions are running and a process to track CVEs in those dependencies. Incorporate Kubernetes component updates into regular maintenance windows. The discovery by Wiz and analysis by Datadog were external efforts – don’t rely on luck; proactively review components in use and engage with the community (or vendors) for security news.
In summary, the recent Kubernetes Ingress-NGINX vulnerabilities serve as an important alert to the community. A combination of diligent patching and strategic hardening is required to protect our clusters from such threats. By swiftly upgrading affected systems and doubling down on Kubernetes security best practices, organizations can reduce the risk of an “IngressNightmare” in their own environments. This episode reinforces that Kubernetes security is a shared responsibility – from project maintainers to end users – and staying informed and prepared is key to keeping our cloud infrastructure safe.
How Bastioncraft Can Help
At Bastioncraft, we offer comprehensive services aimed at helping organizations strengthen their Kubernetes environments and overall cloud security. Our services include:
Cybersecurity Consulting: We help organizations assess and improve their security posture, including Kubernetes infrastructure.
Penetration Testing: Through targeted assessments, we identify vulnerabilities in your Kubernetes deployments and provide actionable recommendations.
Kubernetes Security Audits: Our team reviews your cluster configurations, RBAC settings, and network policies to identify potential weaknesses.
Cloud Management and Monitoring: We help you implement monitoring systems to detect signs of compromise and ensure your clusters are running securely.
Training and Awareness Campaigns: We offer workshops and guidance on best practices for Kubernetes security and incident response.
