NGINX Vulnerability Overview
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).
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.
Vulnerability Details
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.
Exploitation and Impact
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.
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.”
Other Vulnerabilities and Fixes
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. These include:
- CVE-2026-42946 — excessive memory allocation in SCGI/UWSGI modules that can crash workers via ~1 TB allocations
- CVE-2026-40701 — use-after-free in asynchronous OCSP DNS resolution handling
- CVE-2026-42934 — off-by-one UTF-8 parsing bug causing out-of-bounds reads
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 various NGINX builds, including NGINX Open Source, NGINX Plus, and NGINX Instance Manager.
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.
Real-World Exploitability
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.
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.
Source: BleepingComputer