NGINX Rift: Achieving NGINX Remote Code Execution via an 18-Year-Old Vulnerability TLDR: We used depthfirst’s system to analyze the NGINX source code, and it autonomously discovered 4 remote memory corruption issues, including a critical heap buffer overflow introduced in 2008. We further investigated the exploitability of the issues, and developed a working proof of concept demonstrating RCE with ASLR off. If you use rewrite and set directives in your NGINX configuration, you’re at risk. In mid-April, I was chatting with a colleague about the most vulnerable spot in our infrastructure. Since most of our services live entirely inside a private network, our app platform is the only exposed surface. He joked that achieving remote code execution on our web service would mean hacking into depthfirst completely. Hacking the web service itself is not my usual focus. However, the idea of hacking the underlying web server intrigued me, which directed my attention to NGINX. NGINX is the most popular web server today, powering nearly a third of all websites globally . Its high performance architecture makes it the undisputed leader for handling massive volumes of web traffic. From serving static content to acting as an essential reverse proxy, it sits at the critical edge of the modern internet. A single vulnerability in this core infrastructure can therefore expose countless backend systems to severe risks. Internally, we have an autonomous system that specializes in analyzing low level software. Analyzing NGINX simply required a single click to onboard the repository and trigger the analysis. After six hours of scanning, the system identified 5 security issues including a high severity finding, which is a heap overflow issue when handling NGINX rewrite directive. Figure 1: The depthfirst system identified 4 remote memory corruption issues in NGINX. After briefly reviewing the findings, we reported the issues to NGINX via github security advisory. For each finding, we provided a detailed vulnerability description, root cause analysis, and a proof of concept generated directly by our system. 4 of the findings were confirmed by NGINX: CVE-2026-42945 (Critical, CVSS 9.2): A heap buffer overflow issue in ngx_http_rewrite_module , an unpropagated is_args flag during a rewrite and set sequence causes an undersized buffer allocation. The copy phase then writes attacker-controlled escaped URI data past the heap boundary, leading to RCE. CVE-2026-42946 (High, CVSS 8.3): An excessive memory allocation issue in ngx_http_scgi_module and ngx_http_uwsgi_module , a state mismatch after an incomplete upstream status line read causes a cross-buffer pointer subtraction. This produces a ~1 TB key length, crashing the worker process. CVE-2026-40701 (Medium, CVSS 6.3): A use after free issue in ngx_http_ssl_module , if a TLS connection closes before asynchronous OCSP DNS resolution completes, the context pool is destroyed without cancelling the resolver request. The DNS timer later dereferences the freed pointer. CVE-2026-42934 (Medium, CVSS 6.3): An out-of-bounds read issue in ngx_http_charset_module , an off-by-one error when handling incomplete UTF-8 sequences across proxy buffer boundaries corrupts the length state. This computes a negative source offset, reading 2 bytes before the allocated upstream buffer. Among the 4 confirmed issues, CVE-2026-42945 is the most critical one. It is a heap buffer overflow issue that was introduced in 2008 , impacting NGINX versions from 0.6.27 to 1.30.0 . Given the high severity and the fact that it has been around for 18 years, we decided to investigate it in depth. CVE-2026-42945 This vulnerability requires rewrite and set directives to trigger, but what are these directives? Imagine you are migrating a legacy API to a new system. You need to seamlessly route incoming requests to the new endpoints. The rewrite directive allows you to modify the request path on the fly. However, your backend application might still need to know the original requested path. This is exactly where the set directive proves essential. It lets you capture and store the original path in a custom variable before the rewrite occurs. Together, these two directives are common building blocks in API gateway configurations. The rewrite directive changes the request URI based on regular expressions. When a request matches the specified pattern, NGINX replaces the URI with a new string. For example, rewrite ^/api/(.*)$ /v2/api/$1 takes the matched part in the parentheses (a capture group) and appends it to the new path using the $1 variable. If the replacement string contains a question mark, NGINX treats the rest of the string as a query string and appends the original request arguments to it. The set directive is used to assign a value to a custom variable. This is incredibly useful in practice for temporarily storing parts of the original request, dynamically routing endpoints, or maintaining state throughout the request life...