Ingress NGINX RCE Vulnerability Allows Attackers to Compromise Entire Cluster

A series of remote code execution (RCE) vulnerabilities known as “IngressNightmare” have been discovered in the Ingress NGINX Controller for Kubernetes.

These vulnerabilities, identified as CVE-2025-1097, CVE-2025-1098, CVE-2025-24514, and CVE-2025-1974, pose a critical threat to Kubernetes clusters, allowing attackers to gain unauthorized access to all cluster secrets and potentially take control of the entire cluster.

CVE-2025-24514: auth-url Annotation Injection

The CVE-2025-24514 vulnerability arises from the handling of authentication-related annotations, specifically the nginx.ingress.kubernetes.io/auth-url annotation.

In the authReq parser, the auth-url field is not properly sanitized when it is incorporated into the NGINX configuration.

This oversight allows attackers to inject arbitrary NGINX directives by crafting malicious annotations.

For instance, if an attacker uses the following annotation:

nginx.ingress.kubernetes.io/auth-url: "http://example.com/#;\ninjection_point"

The resulting NGINX configuration could appear as:

proxy_http_version 1.1;
set $target http://example.com/#;
injection_point
proxy_pass $target;

This vulnerability is particularly dangerous because it allows attackers to inject commands into the NGINX configuration, potentially leading to remote code execution.

CVE-2025-1097: auth-tls-match-cn Annotation Injection

According to the Wiz reports,CVE-2025-1097 involves the nginx.ingress.kubernetes.io/auth-tls-match-cn annotation, which requires a value starting with “CN=” and followed by a valid regular expression.

However, attackers can bypass these checks to inject arbitrary configurations. For example, using the annotation:

nginx.ingress.kubernetes.io/auth-tls-match-cn: "CN=abc #(\n){}\n }}\nglobal_injection;\n#"

can lead to injection of arbitrary NGINX directives into the configuration file.

To exploit this, attackers need access to a TLS certificate or keypair secret in the cluster, which is often readily available in managed environments. Commonly exploited secrets include:

kube-system/konnectivity-certs
kube-system/azure-wi-webhook-server-cert
kube-system/aws-load-balancer-webhook-tls
kube-system/hubble-server-certs
kube-system/cilium-ca
calico-system/node-certs
cert-manager/cert-manager-webhook-ca
linkerd/linkerd-policy-validator-k8s-tls
linkerd/linkerd-proxy-injector-k8s-tls
linkerd/linkerd-sp-validator-k8s-tls

CVE-2025-1098: Mirror UID Injection

In this vulnerability, the mirror annotation parser allows attackers to inject arbitrary directives by manipulating the UID field of the ingress object.

Since this input is not sanitized by regex rules applied to annotations, attackers can easily escape the intended context and inject arbitrary NGINX configurations.

CVE-2025-1974: NGINX Configuration Code Execution

While the previous vulnerabilities allow for configuration injection, CVE-2025-1974 demonstrates how these injections can be leveraged for remote code execution.

By exploiting the ssl_engine directive within the injected configurations, attackers can load arbitrary shared libraries from the filesystem.

This is achieved by using NGINX’s client body buffering feature to temporarily save a shared library onto the pod’s filesystem and then specifying its ProcFS path to load it as a library.

Exploitation Steps

The exploitation involves the following key steps:

1. Upload Shared Library: Send a large HTTP request with the shared library as its body to the NGINX instance, causing it to save the library temporarily.
2. Keep File Descriptor Open: Use a Content-Length header that exceeds the actual request size, keeping the file descriptor open despite NGINX removing the file.
3. Inject Directive: Send an AdmissionReview request with the ssl_engine directive pointing to the file descriptor path.
4. Achieve RCE: The library is loaded, allowing arbitrary code execution due to NGINX’s elevated privileges and access to all cluster secrets.

Mitigation and Detection

To mitigate these vulnerabilities, users should:

• Update Ingress NGINX Controller: Move to version 1.12.1 or 1.11.5.
• Restrict Admission Webhook Access: Ensure the admission webhook endpoint is not exposed to the public internet.
• Implement Network Policies: Allow only the Kubernetes API server to access the admission controller.
• Disable Admission Controller Temporarily: If an immediate update is not feasible.

As these vulnerabilities expose clusters to significant risk, immediate action is advised to secure Ingress NGINX Controllers and prevent potential takeovers.

The security community encourages ongoing vigilance regarding admission controllers, often overlooked but critical components in Kubernetes environments.

Investigate Real-World Malicious Links & Phishing Attacks With Threat Intelligence Lookup - Try for Free