IngressNightmare: CVE-2025-1974 Remote Code Execution Vulnerability & Remediation

May 2025 marked the public disclosure of a critical security vulnerability, CVE-2025-1974, dubbed IngressNightmare, affecting the Kubernetes ingress-nginx controller widely deployed across cloud native infrastructures. This vulnerability allows unauthenticated attackers to inject arbitrary configurations into NGINX, potentially leading to unauthorized RCE (remote code execution) and full cluster compromise.

As part of the OPSWAT Fellowship program, our fellows conducted an in-depth technical analysis to better understand its root cause, exploitation path, and mitigation strategies surrounding this high-severity issue.

1. Each configuration is parsed and passed to generateTemplate to be formatted according to predefined NGINX templates.
2. Subsequently, testTemplate validates the generated configuration against the underlying NGINX binary.

All NGINX configurations are based on predefined templates found in the nginx.tmpl file within the ingress-nginx source code:

Within the generateTemplate function, the configuration is processed as shown in the following code snippet:

However, input validation and sanitization are insufficient. Specifically, the uid field from an Ingress Object is directly inserted into the NGINX configuration template, creating an injection point. An attacker can exploit this by supplying crafted input such as uid="1234#;\n\n}\n}\n}\n injection_value".

This malicious input allows global scope injection into the NGINX template, enabling attackers to trigger arbitrary NGINX directives and potentially achieve RCE.

To exploit the vulnerability, an attacker needs to identify a directive capable of executing malicious code. Initially, our fellows identified the load_module directive as potentially useful, because this directive allows NGINX to load external plugins. However, this directive is only permitted in the early phase of configuration parsing, which does not match our injection point.

To solve this challenge, we continued further research, which led to the ssl_engine directive, described as "The module may be dynamically loaded by OpenSSL during configuration testing." This raised curiosity due to its capability to dynamically load modules, necessitating a deeper examination.

On startup, NGINX loads its initial state, then parses configuration files line by line. Each directive is handled by the nginx_command_t structure, with the directive ssl_engine directly invoking the ngx_openssl_commands.

Upon analyzing the ngx_openssl_commands function, our fellows discovered that it relies on OpenSSL support, specifically the function ENGINE_by_id which is used for hardware-accelerated SSL modules.

And while analyzing the ENGINE_by_id function, we determined that it enables the dynamic loading of shared libraries. Moreover, if the library is compiled with the __attribute__((constructor)) extension, the associated function can be executed immediately upon loading. This indicates that by exploiting the ssl_engine directive, an attacker could load arbitrary shared libraries on the host, potentially leading to RCE.

By default, when an incoming request exceeds 8KB, NGINX writes the request body to a temporary file located at /tmp/nginx/client-body, using a filename in the format cfg-{random_value}. These temporary files are retained for up to 60 seconds between successful chunks of a received message.

After writing a partial request body to a temporary file, NGINX defers deletion until the entire body is received. If the request remains incomplete and no data is received for up to 60 seconds, the file is eventually purged. However, by intentionally withholding the final chunk of data, an attacker can keep the temporary file in use, making it exploitable.

Although the uploaded file content can be controlled, locating it on the file system is difficult due to the randomized filename. The storage path can be configured using client_body_temp_path, but the filename is randomly generated at runtime, making it unpredictable. This randomness significantly hinders targeted access even through brute force. To overcome this, the team leveraged behaviors inherent to the Linux OS. Consider the following example:

This code opens a file and keeps it in an active state, closely mimicking the behavior of NGINX's client body buffer mechanism. Using /proc/{pid}/fd directory, attackers can find symbolic links created by the Linux kernel that map open file descriptors to their corresponding file paths. This route allows attackers to reduce the brute-force space to only two variables: the process ID (pid) and the file descriptor (fd).

After compilation, the size of the resulting shared library comfortably exceeded 8KB, allowing it to be buffered by NGINX without requiring additional padding.

Our fellows then crafted a request with an inflated Content-Length value (e.g., 1MB) to introduce a size mismatch. This caused NGINX to buffer the entire body rather than processing it immediately, ensuring the shared object would be written to a predictable location.

Successful RCE requires the ssl_engine directive to reference the correct path to the buffered file. This can be achieved via an automated brute force script that systematically iterates over possible combinations of process IDs and file descriptors to identify the valid symbolic link pointing to the buffered shared object.

Below is a sample of the generated NGINX template that triggered the exploit.

Upon successful exploitation, the attacker could gain shell access under the context of the ingress-nginx pod, which by default had access to sensitive Kubernetes cluster secrets.