Wiz recently published a detailed analysis of a critical vulnerability in the NGINX Ingress admission controller—what they’ve dubbed IngressNightmare (CVE-2025-1097, CVE-2025-1098, CVE-2025-1974, CVE-2025-24514). The vulnerability stems from insufficient input validation during configuration file processing, allowing an attacker to inject arbitrary code into the NGINX process. Wiz’s writeup is excellent and covers the technical nuances thoroughly, so we won’t dive too deep into the internals.
In short: the admission controller converts Kubernetes Ingress objects into NGINX configuration files. By crafting a malicious request that writes to the filesystem and then triggering validation, an attacker can trick the controller into loading a shared object of their choosing—effectively executing arbitrary code inside the NGINX process responsible for validating configuration files. Successful exploitation is high impact, as the admission controller typically has access to internal cluster secrets across all namespaces by default.
As part of our ongoing work securing customer environments through Chariot – our Continuous Threat Exposure Management solution – we analyzed the vulnerability’s impact to help organizations assess their exposure and determine practical steps to mitigate risk. We’ve also released an improved Nuclei template that more accurately detects the vulnerability than previously published detection rules.
What Security Teams Need to Know About IngressNightmare
We know security teams are often stretched thin and juggling multiple issues. Here’s the TL;DR:
- This is a serious vulnerability, but it’s not a remote code execution (RCE) issue that’s exploitable from the internet by default.
- The NGINX Ingress admission controller is not exposed externally in default Kubernetes configurations. An attacker must be able to access the admission controller service to exploit it.
- There’s no legitimate reason to expose this service externally. Our research found no common use cases or products that rely on exposing it to the internet. If it is exposed, it’s likely due to misconfiguration.
- The bigger concern is internal cluster communication. If a pod has overly permissive network access and can reach services in the ingress-nginx namespace, it could exploit the vulnerability to run code in the admission controller pod.
- This pod is highly privileged, with access to sensitive resources like Kubernetes secrets. Successful exploitation could lead to full cluster compromise.
- Corporate environments without strict network segmentation are also at risk. An attacker with internal network access could scan for exposed nginx ingress admission controller services and use this for lateral movement into a Kubernetes cluster or post-exploitation if internal network segmentation is not enforced properly.
Recommended Actions
Step 1: Audit External Exposure
Ensure that the NGINX Ingress admission controller is not externally accessible. If you’re using a platform like Chariot, this is covered by our automated discovery and monitoring tools. Otherwise, you can perform manual scanning to identify exposed services. Authenticated scanning tools such as Wiz will be more useful for identifying a list of vulnerable clusters that need to be updated, but they won’t be able to cover shadow IT assets that aren’t monitored or onboarded into authenticated scanning tools.
Step 2: Upgrade Strategically
Prioritize upgrading nginx ingress controllers, starting with the clusters that host your most critical services. Focus on versions 1.11.5+ or 1.12.1+, as these contain the necessary fixes and hardening.
Key Takeaways
- Default configurations are safe from unauthenticated RCE over the internet.
- The impact of a successful exploit is high, especially in clusters without strict internal network segmentation.
- External exposure of the NGINX Ingress admission controller is almost always a misconfiguration.
- Organizations should harden network policies to prevent unnecessary inter-namespace communication and limit pod-to-pod access.
Improving Detection: Our Contribution
During our research, we reviewed the existing detection templates from ProjectDiscovery, specifically the one for CVE-2025-24514 (labeled as CVE-2025-1974, but the template tests for CVE-2025-24514). However, we found that the template didn’t reliably detect vulnerable instances running v1.12.0, which introduced hardening that blocks the exploitation of CVE-2025-24514 through additional input validation on the auth-url attribute. However, this validation was not applied to other fields such as the uid field targeted in CVE-2025-1098 (see this portion of the Wiz writeup on CVE-2025-24514 for more details). An attacker could leverage CVE-2025-1098 in place of CVE-2025-24514 in the exploit chain and trigger remote code execution on v1.12.0.
To improve detection, we developed a custom Nuclei template targeting CVE-2025-1098—a closely related vulnerability that affects a different field not protected by the filters introduced in v1.12.0. This template successfully triggers the vulnerability in both v1.11.4 and v1.12.0, bridging the detection gap that we identified where v1.12.0 wasn’t being detected as vulnerable with the existing template.
During our testing we primarily tested against versions v1.11.4 (vulnerable), v1.11.5 (not vulnerable), v1.12.0 (vulnerable), and v1.12.1 (not vulnerable). Our testing indicated that both templates functioned properly except in the case of v1.12.0 where the existing template reported the instance as not vulnerable whereas our new method of testing leveraging CVE-2025-1098 functioned properly (see Figure 1).
We’ve uploaded a copy of our template for CVE-2025-1098 to our Chariot capabilities repository on Github.
Conclusion
Ingress Nightmare is a significant vulnerability with potentially severe consequences—but the real-world exposure is limited by the default configuration of Kubernetes. Most environments are not vulnerable to unauthenticated external RCE unless the admission controller has been explicitly and improperly exposed.
That said, the high privilege level of the vulnerable component means that internal exposure still poses a substantial risk, especially in environments without tight network controls. Our advice: Audit your exposure, upgrade your controllers, and segment your networks. While not an internet-exploitable zero-click RCE, this is still a vulnerability worth addressing quickly—particularly for clusters hosting high-value workloads.
If you’re a Chariot customer, we’ve already rolled out checks and detections to help you assess your environment and stay ahead of potential threats. If not, please reach out to learn more.
