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. ## The Validation Gap: Automated Pentesting Answers One Question. You Need Six. Automated pentesting tools deliver real value, but they were built to answer one question: can an attacker move through the network? They were not built to test whether your controls block threats, your detection rules fire, or your cloud configs hold. This guide covers the 6 surfaces you actually need to validate. [Download Now](https://hubs.li/Q048zztN0)