IngressNightmare: Critical RCE Vulnerabilities Threaten Kubernetes Clusters

David Tessier
Jun 12
6 min read

Updated: Jun 13

Kubernetes has become the de facto standard for container orchestration, and exposing applications within it to the internet often relies on Ingress controllers. The Ingress NGINX Controller, a core Kubernetes project based on the popular NGINX reverse proxy, is one of the most widely used, found in over 41% of internet-facing clusters. It serves to accept incoming traffic and route it to the correct Kubernetes Services and Pods.

Recently, a series of critical unauthenticated Remote Code Execution (RCE) vulnerabilities, collectively termed #IngressNightmare, were discovered in Ingress NGINX Controller versions prior to 1.12.1 and 1.11.55. These vulnerabilities, including CVE-2025-1974, CVE-2025-1097, CVE-2025-1098, and CVE-2025-24514, carry a high CVSS v3.1 base score of 9.85. Successful exploitation could grant attackers unauthorized access to all secrets across all namespaces in a cluster, potentially leading to a complete cluster takeover.

Based on research, about 43% of cloud environments are vulnerable to these issues, with over 6,500 clusters, including those of Fortune 500 companies, found to be publicly exposing vulnerable admission controllers. This highlights the significant risk across various cloud platforms and deployments.

The Core Vulnerability: Unauthenticated Admission Controller Access

The heart of the IngressNightmare vulnerabilities lies in the admission controller component of Ingress NGINX Controller. This component runs within the Ingress NGINX pod and is designed to validate incoming ingress objects before they are deployed. Critically, admission controllers are often accessible over the network without authentication, making them a highly appealing attack vector. Normally, only the Kubernetes API server should send AdmissionReview requests to this endpoint. However, its lack of authentication allows attackers with minimal network access from any pod within the cluster to craft and send arbitrary AdmissionReview requests.

When the Ingress NGINX admission controller processes an ingress object, it constructs a temporary NGINX configuration and validates it using the nginx -t command. Researchers discovered several ways to inject arbitrary NGINX configuration directives remotely by sending a malicious AdmissionReview request containing a specially-crafted ingress object directly to this unauthenticated admission controller.

Specific injection vulnerabilities were found in how the admission controller parses annotations from the ingress object18:

CVE-2025-24514: This vulnerability exists in the auth-url annotation parser. The URL value provided in the annotation was incorporated into the temporary NGINX configuration without proper sanitization, allowing attackers to inject directives. (Note: This specific vulnerability doesn't apply to v1.12.0 due to stricter validation in that version).
CVE-2025-1097: This relates to the auth-tls-match-cn annotation. While validation checks required the value to start with CN= and be a valid regex, researchers found ways to bypass these checks and inject arbitrary NGINX configurations. Exploiting this requires providing a secret name via the auth-tls-secret annotation, which the controller's service account has access to across all namespaces. Common secrets included in managed Kubernetes solutions can be leveraged.
CVE-2025-1098: This vulnerability was found in the mirror annotation parser. The injection point is the ingress object's UID field, which was inserted into the temporary NGINX configuration ($location.Mirror.Source) without being sanitized by annotation regex rules, allowing easy directive injection.

From Injection to Remote Code Execution (RCE)

While injecting configuration directives is severe, achieving RCE requires executing code during the nginx -t testing phase. Researchers found that although the load_module directive, which loads shared libraries, is restricted in where it can be used in the configuration, the ssl_engine directive, part of the OpenSSL module, can load shared libraries during this testing phase and can be used at any point in the configuration, making it suitable for injection.

Executing arbitrary code requires placing a malicious shared library on the Ingress NGINX Controller pod's filesystem. This is achieved by leveraging the NGINX instance running within the same pod as the controller, which listens on ports 80/443. When processing HTTP requests, NGINX uses client body buffering to save large request bodies (>8KB) into temporary files. Although these files are normally removed immediately, by setting the Content-Length header larger than the actual body size, the NGINX process hangs while waiting for more data, keeping an open file descriptor to the temporary file accessible via ProcFS (like /proc/<PID>/fd/<FD>).

The complete RCE exploit combines these steps:

Upload a malicious shared library to the pod using the NGINX client-body buffer abuse.
Send a malicious AdmissionReview request to the unauthenticated admission controller, injecting the ssl_engine directive.
The injected ssl_engine directive points to the ProcFS path of the uploaded malicious shared library.
When the admission controller runs nginx -t to validate the configuration, the injected ssl_engine directive causes NGINX to load and execute the malicious shared library.

This results in Remote Code Execution on the Ingress NGINX Controller pod.

The Critical Escalation: Unauthenticated RCE from the Pod Network

he most severe aspect is CVE-2025-1974, this vulnerability enables anything on the Pod network to exploit the configuration injection flaws through the Ingress NGINX Controller's Validating Admission Controller feature. Unlike needing permission to create an Ingress object (which is a privileged action), attacking the unauthenticated admission controller only requires network access to the pod.

In many common scenarios, the Pod network is accessible to all workloads within a cloud VPC or even connected to a corporate network. This means an attacker with no credentials or administrative access can gain access to the Pod network (potentially via other vulnerabilities like SSRF or container escapes) and then exploit CVE-2025-1974 and the configuration injection vulnerabilities to achieve RCE and potentially take over the entire cluster. The admission controller's elevated privileges and unrestricted network accessibility are key factors in this critical escalation path.

Impact on Kubernetes in Google Cloud

Ingress NGINX Controller is widely used across cloud providers, including Google Cloud. Google Cloud has published its own advisory regarding these vulnerabilities, indicating that Google Cloud environments running vulnerable versions of Ingress NGINX Controller are also affected. The general impact described (unauthenticated RCE from the Pod network) applies equally to Google Cloud environments where the vulnerable controller is deployed.

Mitigation Strategies

Immediate action is strongly recommended. The vulnerabilities are fixed in Ingress NGINX Controller version 1.12.1 and 1.11.5, cluster administrators should update to the latest patched version immediately.

If immediate upgrading is not possible, several mitigations can significantly reduce risk:

Ensure the admission webhook endpoint is NOT exposed externally.
Enforce strict network policies so that only the Kubernetes API Server can access the admission controller.
Temporarily disable the admission controller component of Ingress NGINX.
- If installed using Helm, reinstall with controller.admissionWebhooks.enabled=false.
- If installed manually, delete the ValidatingWebhookConfiguration named 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 you upgrade to a patched version, as it provides important safeguards and quality-of-life improvements for your Ingress configurations.

How CWX Can Help

CWX's provides various security capabilities and offerings that could potentially help in identifying or responding to such threats within a Google Cloud environment:

Multi-Layered Protection: Safeguarding assets with Google Cloud's security combined with proactive threat management leveraging defense-in-depth strategies that make exploitation harder.
24/7 Threat Monitoring: Security experts constantly monitoring your environment to potentially detect suspicious activity related to the exploitation attempt, such as anomalous network traffic patterns towards the admission controller or unusual process behavior within the Ingress NGINX pod.
Advanced Threat Detection: Utilizing state-of-the-art Google Cloud security tools configured to identify patterns indicative of the exploit (e.g., malicious AdmissionReview requests from unexpected sources, attempted file uploads via NGINX buffering, or unusual library loads).
Dynamic Security Frameworks: Employing adaptive security measures that evolve with emerging threats like IngressNightmare are identified.
Security Assurance: Staying informed about security gaps, investigating them, and implementing solutions. CWX can help customers identify if they are running a vulnerable version of Ingress NGINX Controller or if the admission controller is improperly exposed, and then assist in implementing the necessary patching or mitigation steps.

Conclusion

The IngressNightmare vulnerabilities, including CVE-2025-1974, pose a severe risk due to the potential for unauthenticated RCE from the Pod network. Given the widespread use of Ingress NGINX Controller, immediate action is crucial to protect your Kubernetes clusters. Upgrading to versions 1.12.1 or 1.11.5 is the primary and most effective mitigation. If unable to upgrade immediately, implementing strict network policies or temporarily disabling the admission controller can help reduce the attack surface.

We extend our thanks to the Wiz Research team for their responsible disclosure and collaboration with the Kubernetes maintainers and security teams, including those at Google Cloud, to address these critical issues.

For further details on the specific vulnerabilities, please refer to the appropriate GitHub issues below:

Contact CWX today to understand how we can help make sure your cloud environment is secure and can withstand threats like the IngressNightmare.

Sources