IngressNightmare: Ingress NGINX Remote Code Execution Vulnerability Explained

On March 24th, 2025, Kubernetes disclosed four critical vulnerabilities affecting ingress-nginx [1]. Out of the four vulnerabilities, CVE-2025-1974 is the most serious one with a CVSS score of 9.8 (Critical). These vulnerabilities can be exploited for unauthenticated remote code execution in the Kubernetes cluster and may lead to cluster takeover. 

In this blog, we explained the IngressNightmare vulnerabilities and how organizations can defend against IngressNightmare attacks.

Simulate Vulnerability Exploitation Attacks with 14-Day Free Trial of Picus Platform

IngressNightmare Vulnerability Explained

Ingress-NGINX is an open-source ingress controller designed for Kubernetes environments, and it serves as a critical component for managing external access to applications running within a Kubernetes cluster. In a typical Kubernetes setup, services run inside pods and are accessible internally within the cluster. However, exposing these services to users or applications outside the cluster requires a mechanism to route incoming requests properly. Ingress-NGINX acts as a reverse proxy, meaning it accepts incoming traffic from clients, evaluates routing rules defined by Kubernetes Ingress resources, and forwards the traffic to the appropriate backend services or pods.

IngressNightmare is a critical set of security vulnerabilities affecting the Ingress-NGINX controller in Kubernetes, allowing unauthenticated remote code execution (RCE). These vulnerabilities expose Kubernetes clusters to a severe attack vector, potentially leading to full cluster compromise. According to security researchers, more than 40% of cloud environments using Ingress-NGINX are vulnerable, and thousands of exposed clusters, including those belonging to Fortune 500 companies, are at immediate risk [2].

The root cause of IngressNightmare lies in how the Ingress-NGINX admission controller processes incoming requests. The admission controller is a component responsible for validating and modifying Kubernetes Ingress objects before they are deployed. By default, this controller is accessible over the network without authentication. The vulnerability stems from flaws in how it constructs and validates NGINX configurations, allowing an attacker to inject arbitrary configuration directives remotely. When the admission controller processes these malicious directives, they can be executed within the Ingress-NGINX pod, enabling the attacker to run arbitrary commands with elevated privileges.

Once exploited, this vulnerability allows an attacker to access all secrets across all namespaces in the Kubernetes cluster. Since Kubernetes relies on secrets to store sensitive information such as credentials, API tokens, and TLS certificates, gaining access to these secrets can enable further attacks, including lateral movement and complete control over the cluster. Additionally, Ingress-NGINX often runs with broad privileges, which increases the impact of the attack, making it easier for adversaries to escalate their access and compromise other critical components.

How Ingress NGINX CVE-2025-24514 Exploit Works?

CVE-2025-24514 vulnerability targets the way the Ingress-NGINX controller processes the auth-url annotation, which is used to define an external URL for authentication purposes. This annotation is meant to point to an external service that validates incoming requests before allowing access to a backend application. However, the flaw lies in how the controller takes the value of this annotation and embeds it directly into the generated NGINX configuration without proper sanitization.

When an Ingress resource is created or modified, the admission controller of Ingress-NGINX validates the configuration by rendering a temporary NGINX configuration file and running the nginx -t test command. During this process, the value provided in the auth-url annotation is inserted into the configuration template. If the input is not properly checked or escaped, an attacker can inject newline characters or malicious NGINX directives into the annotation value. These injected directives are then processed by the NGINX binary during the validation phase.

How Ingress NGINX CVE-2025-1907 Exploit Works?

CVE-2025-1097 vulnerability targets the auth-tls-match-cn annotation in the Ingress-NGINX controller, which is designed to enforce client certificate authentication by matching the Common Name (CN) field of a presented certificate against a specified value.

The vulnerability arises from the way the auth-tls-match-cn annotation is processed and validated. Specifically, the NGINX controller tries to verify that the value of this annotation starts with the prefix CN= and that the remaining portion is a valid regular expression. However, this validation is not robust enough to prevent attackers from injecting malicious content. By carefully crafting the annotation value to satisfy the superficial checks, adversaries can inject arbitrary NGINX configuration directives into the final configuration file that the controller generates and tests.

How Ingress NGINX CVE-2025-1908 Exploit Works?

CVE-2025-1098 vulnerability takes advantage of how the Ingress-NGINX controller processes the metadata.uid field of an Ingress resource. In Kubernetes, the uid is typically a unique identifier automatically assigned to every resource, and it is not something users usually manipulate directly. However, in the context of the admission controller, the attacker can craft a fake AdmissionReview request where they control the uid value entirely.

In vulnerable Ingress NGINX applications, the uid value is passed unsanitized into the NGINX configuration template during the process of rendering a temporary configuration file for validation. Specifically, the uid gets embedded into the NGINX configuration as part of the mirror module, which is designed to duplicate requests for debugging or analysis purposes. Since this uid field is not treated like a typical user-provided annotation, it bypasses the usual input validation and regex checks applied to annotations. As a result, it becomes a new injection point that the attacker can fully control.

An attacker with network access to the Ingress-NGINX admission controller can craft a malicious AdmissionReview request containing a specially designed uid value. By inserting newline characters or NGINX directives into the uid, the attacker can break out of the expected configuration context and inject arbitrary NGINX directives directly into the temporary configuration file. Because the controller runs an nginx -t test on this file, those injected directives are parsed and executed by the NGINX process.

How Ingress NGINX CVE-2025-1974 Exploit Works?

CVE-2025-1974 is the most critical vulnerability in the IngressNightmare series because it turns the configuration injection issues into actual remote code execution (RCE). While the other vulnerabilities enable attackers to inject arbitrary NGINX directives into the temporary configuration file, CVE-2025-1974 explores how this injection can be used to execute code within the Ingress-NGINX controller pod. It does so by leveraging a powerful but lesser-known NGINX directive called ssl_engine.

The vulnerability stems from the way the Ingress-NGINX admission controller tests the generated NGINX configuration. When an AdmissionReview request is received, the controller creates a temporary NGINX configuration file based on the input and runs the nginx -t command to validate it. The assumption is that this validation is harmless because the configuration is never actually applied. However, this assumption proves dangerous because certain NGINX directives can execute actions even during the test phase.

The researchers discovered that ssl_engine, a directive from the OpenSSL module, can load a shared library from the filesystem and ssl_engine can be placed anywhere within the configuration, making it a perfect candidate for injection. To execute code, the attacker must first place a malicious shared library file somewhere on the pod’s filesystem. This is where NGINX's own behavior helps. When NGINX handles large HTTP requests, it stores the request body as a temporary file. By sending a large enough request to the pod’s NGINX instance, an attacker can ensure that the payload—crafted as a shared library—is written to disk. Although NGINX tries to delete the temporary file immediately, the process keeps an open file descriptor, which remains accessible through the Linux /proc filesystem.

Finally, the attacker crafts an AdmissionReview request that injects an ssl_engine directive pointing to that open file descriptor in /proc. When nginx -t runs, the injected directive causes NGINX to load the attacker’s library, leading to arbitrary code execution inside the pod. Because the admission controller runs with high privileges and often has access to all cluster secrets, this code execution can escalate to a full cluster compromise.

References

[1] “Ingress-nginx CVE-2025-1974: What You Need to Know,” Kubernetes, Mar. 24, 2025. Available: https://kubernetes.io/blog/2025/03/24/ingress-nginx-cve-2025-1974/

[2] N. Ohfeld, R. Shustin, S. Tzadik, and H. Ben-Sasson, “IngressNightmare: 9.8 Critical Unauthenticated Remote Code Execution Vulnerabilities in Ingress NGINX,” wiz.io, Mar. 24, 2025. Available: https://www.wiz.io/blog/ingress-nginx-kubernetes-vulnerabilities