On March 24, 2025, WIZ Research disclosed critical vulnerabilities in the Kubernetes Ingress NGINX Controller that allow unsanitized user input to be injected into the temporary NGINX configuration file during validation. This unsanitized input, when processed by the nginx -t command, can lead to remote code execution (RCE) on the pod running the controller.
Vulnerability Overview
When processing an incoming AdmissionReview request, the Ingress NGINX Controller builds a temporary NGINX configuration file from the provided ingress object. Critical fields - particularly those originating from annotations - are inserted without sufficient sanitization. This gap allows an attacker to inject arbitrary NGINX directives that are processed during configuration testing.
Technical Explanation
The exploitation of this vulnerability involves two key steps:
Payload Delivery via Client-Body Buffering
NGINX writes HTTP request bodies larger than a set threshold (by default, 8KB) to a temporary file. Under normal circumstances, this file is deleted immediately after use. However, by setting the HTTP Content-Length header to a value larger than the actual payload, the attacker forces NGINX to wait for more data. This causes the process to hang, keeping the temporary file’s file descriptor open. Although the file is deleted from the filesystem, the open file descriptor remains accessible via ProcFS. In a container with few processes, guessing the PID and file descriptor number is feasible.
Directive Injection via AdmissionReview Request
The attacker then crafts an AdmissionReview request containing a malicious injection. By leveraging unsanitized fields in the ingress object, the attacker injects the ssl_engine directive into the configuration. This directive instructs NGINX to load a shared library. The injected configuration specifies the ProcFS path of the open file descriptor containing the payload. When nginx -t executes, it processes the injected directive, loads the shared library from the specified file descriptor, and executes its code - thus achieving remote code execution.
This multi-step attack effectively combines the predictable behavior of NGINX’s client-body buffering with the unsanitized configuration injection, allowing for arbitrary code execution within the pod’s highly privileged context.
Important Note: In order to exploit this vulnerability, the attacker must have network access to the ingress controller’s pod to send arbitrary AdmissionReview requests. While such access is not available by default in many environments, it can be achieved if the attacker gains a foothold within the cluster - such as through compromising another pod - or by leveraging SSRF vulnerabilities. This requirement raises the barrier for exploitation, although it does not eliminate the risk.
Remediation
Our security team verified that our Helm chart deployment of open-appsec / Check Point CloudGuard WAF - which uses the Ingress NGINX Controller - was affected by these vulnerabilities. To address this issue, within 24 hours we provided the fix by updating the controller to version 1.21.1, which includes all the necessary patches and improvements to ensure proper sanitization of user inputs during configuration generation.
open-appsec is an open-source project that builds on machine learning to provide pre-emptive web app & API threat protection against OWASP-Top-10 and zero-day attacks. It simplifies maintenance as there is no threat signature upkeep and exception handling, like common in many WAF solutions.
To learn more about how open-appsec works, see this White Paper and the in-depth Video Tutorial. You can also experiment with deployment in the free Playground.
