18-year-old NGINX vulnerability allows DoS, potential RCE

An 18-year-old flaw in the NGINX open-source web server, discovered using an autonomous scanning system, can be exploited for denial of service and, under certain conditions, remote code execution.

The vulnerability is tracked as CVE-2026-42945 and received a critical severity rating of 9.2, based on the latest version of the Common Vulnerability Scoring System (CVSS).

Three more memory corruption security issues were discovered in the same six-hour code scanning session by researchers at AI-native security company DepthFirst AI.

NGINX is a massively used web server and reverse proxy platform, powering a third of the top ranked websites. It can efficiently balance load by distributing incoming network traffic to multiple backend servers and reduce load times by caching content.

Owned and maintained by American tech firm F5, the web server is used by cloud providers, SaaS companies, banks, media platforms, e-commerce sites, and in Kubernetes clusters.

CVE-2026-42945 is a heap buffer overflow in ngx_http_rewrite_module affecting NGINX versions 0.6.27 through 1.30.0, which has been in the project’s code for roughly 18 years.

According to DepthFirst, the vulnerability can be triggered when NGINX configurations use both the ‘rewrite’ and ‘set’ directives, a pattern the researchers say is common in API gateways and reverse proxy setups.

The flaw stems from inconsistent state handling in NGINX’s internal script engine, which processes rewrites in two passes: one to calculate the amount of memory to allocate, and one to copy the actual data.

An ‘is_args’ flag remains set after a rewrite containing ‘?’, causing NGINX to calculate buffer size using unescaped URI lengths but later write larger escaped data like ‘+’ and ‘&’, leading to a heap buffer overflow.

The researchers demonstrated unauthenticated code execution via specially crafted HTTP requests that corrupt adjacent NGINX memory pool structures, overwrite cleanup handler pointers, spray fake structures into memory via POST request bodies, and force NGINX to execute ‘system()’ during pool cleanup.

However, remote code execution was achieved on a system with the Address Space Layout Randomization (ASLR) protection against memory-based attacks turned off. This defense is active by default, but it can be disabled to increase performance in some environments, such as embedded systems and virtual machines used for analysis.

DepthFirst notes that NGINX’s multi-process architecture makes exploitation easier because worker processes inherit nearly identical memory layouts from the master process, enabling reliable heap manipulation and repeated attempts if a worker crashes.

“If our exploit fails and crashes a worker, the master process simply spawns a new one with the exact same memory layout,” the researchers explain.

“This allows us to safely try multiple times until we succeed without worrying about the worker crashing and changing the memory layout.”

“Theoretically, we could leverage this design to leak ASLR (Address Space Layout Randomization) by progressively overwriting pointers byte by byte.”

The other three flaws uncovered by DepthFirst received a medium severity rating:

• CVE-2026-42946 — excessive memory allocation in SCGI/UWSGI modules that can crash workers via ~1 TB allocations (high severity)
• CVE-2026-40701 — use-after-free in asynchronous OCSP DNS resolution handling (medium severity)
• CVE-2026-42934 — off-by-one UTF-8 parsing bug causing out-of-bounds reads (medium severity)

Impact and fixes

The vulnerabilities were discovered on April 18, 2026, and reported to the vendor on April 21.

According to F5’s security advisory, released yesterday, the flaws impact the following NGINX builds:

• NGINX Open Source versions 0.6.27 through 1.30.0
• NGINX Plus R32 through R36
• NGINX Instance Manager 2.16.0 through 2.21.1
• F5 WAF for NGINX 5.9.0 through 5.12.1
• NGINX App Protect WAF 4.9.0 through 4.16.0 and 5.1.0 through 5.8.0
• F5 DoS for NGINX 4.8.0
• NGINX App Protect DoS 4.3.0 through 4.7.0
• NGINX Gateway Fabric 1.3.0 through 1.6.2 and 2.0.0 through 2.5.1
• NGINX Ingress Controller 3.5.0 through 3.7.2, 4.0.0 through 4.0.1, and 5.0.0 through 5.4.1

Fixes were made available in NGINX Open Source 1.31.0 and 1.30.1, NGINX Plus R36 P4, and NGINX Plus R32 P6.

For those unable to upgrade, F5 recommends replacing unnamed PCRE capture groups ($1, $2, etc.) in vulnerable ‘rewrite’ rules with named captures, which eliminates the main exploitation prerequisite.

Exploitability in the real world

Some security researchers have pushed back on the real-world exploitability claims surrounding CVE-2026-42945, arguing that DepthFirst's proof-of-concept relies on highly specific conditions that are not commonly present in default deployments.

Researcher Kevin Beaumont noted that exploitation requires a vulnerable NGINX configuration using particular rewrite patterns, the attacker must know or discover the affected endpoint, and the published RCE PoC was tested with ASLR disabled.

Beaumont stressed that the researchers’ exploit was built against a deliberately vulnerable setup and does not demonstrate reliable code execution against hardened real-world systems

AlmaLinux echoed a similar assessment in their advisory, after independently reproducing the flaw.

The Linux distribution maintainers confirmed that crashing NGINX worker processes via a crafted request is trivial and reliable, making denial-of-service attacks realistic.

However, they stated that turning the heap overflow into dependable remote code execution on systems with ASLR enabled “is not trivial,” and they do not expect a generic, reliable exploit to emerge from depthfirst’s work.

At the same time, AlmaLinux cautioned that “not easy” does not mean impossible, and the DoS potential is enough on its own to treat the issue as urgent.

99% of What Mythos Found Is Still Unpatched.

AI chained four zero-days into one exploit that bypassed both renderer and OS sandboxes. A wave of new exploits is coming.

At the Autonomous Validation Summit (May 12 & 14), see how autonomous, context-rich validation finds what's exploitable, proves controls hold, and closes the remediation loop.

Claim Your Spot