A critical security flaw lurking in the NGINX open-source web server for nearly two decades has been uncovered by an autonomous scanning system. This vulnerability can be leveraged to launch denial-of-service attacks and, in specific scenarios, achieve remote code execution.
Identified as CVE-2026-42945, the issue carries a critical severity score of 9.2 under the latest Common Vulnerability Scoring System (CVSS) framework.
During the same six-hour automated code analysis session, researchers at AI-driven security firm DepthFirst AI identified three additional memory corruption vulnerabilities in NGINX.
NGINX is a widely adopted web server and reverse proxy solution, supporting approximately one-third of the world’s most visited websites. It excels at distributing incoming traffic across multiple backend servers to balance loads and accelerates response times through content caching.
Developed and maintained by U.S.-based technology company F5, the platform serves cloud providers, SaaS businesses, financial institutions, media outlets, online retailers, and Kubernetes environments.
CVE-2026-42945 is a heap buffer overflow within the ngx_http_rewrite_module, impacting NGINX versions from 0.6.27 to 1.30.0. This flaw has existed in the codebase for approximately 18 years.
DepthFirst reports that the vulnerability is triggered when NGINX configurations employ both the ‘rewrite’ and ‘set’ directives simultaneously—a combination frequently encountered in API gateway and reverse proxy configurations.
The root cause lies in how NGINX’s internal script engine manages state during rewrite operations. The engine processes rewrites in two stages: first determining how much memory to allocate, then copying the actual data into that space.
An ‘is_args’ flag persists after a rewrite containing a ‘?’ character, causing NGINX to calculate buffer sizes based on unescaped URI lengths. However, it subsequently writes larger escaped data—such as ‘+’ and ‘&’—into that buffer, resulting in a heap buffer overflow.
The research team demonstrated unauthenticated remote code execution by sending specially crafted HTTP requests that corrupt neighboring NGINX memory pool structures, overwrite cleanup handler pointers, inject fabricated structures into memory via POST request bodies, and trigger NGINX to invoke ‘system()’ during pool cleanup.
That said, the remote code execution demonstration was performed on a system with Address Space Layout Randomization (ASLR)—a defense mechanism against memory-based exploits—disabled. While ASLR is enabled by default, it is sometimes turned off to boost performance in environments like embedded systems and virtual machines used for testing.
DepthFirst highlights that NGINX’s multi-process architecture actually facilitates exploitation. Worker processes inherit almost identical memory layouts from the master process, making heap manipulation predictable and allowing repeated exploitation attempts if a worker process 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 remaining three vulnerabilities identified by DepthFirst were assigned medium severity ratings:
- CVE-2026-42946 — excessive memory allocation in SCGI/UWSGI modules capable of crashing workers through approximately 1 TB allocations (high severity)
- CVE-2026-40701 — use-after-free flaw in asynchronous OCSP DNS resolution handling (medium severity)
- CVE-2026-42934 — off-by-one UTF-8 parsing error leading to out-of-bounds memory reads (medium severity)
Impact and fixes
The vulnerabilities were discovered on April 18, 2026, and disclosed to the vendor on April 21.
Per F5’s security advisory, published yesterday, the following NGINX products are affected:
- 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
Patches were released in NGINX Open Source 1.31.0 and 1.30.1, NGINX Plus R36 P4, and NGINX Plus R32 P6.
For organizations unable to apply updates immediately, F5 suggests replacing unnamed PCRE capture groups ($1, $2, etc.) in vulnerable ‘rewrite’ rules with named captures. This change removes the primary condition needed for exploitation.
Exploitability in the real world
Some security experts have questioned the practical exploitability of CVE-2026-42945, contending that DepthFirst’s proof-of-concept depends on highly specific conditions rarely found in standard deployments.
Researcher Kevin Beaumont pointed out that successful exploitation requires a vulnerable NGINX configuration with particular rewrite patterns, the attacker must identify or discover the affected endpoint, and the published RCE proof-of-concept was tested with ASLR turned off.
Beaumont emphasized that the researchers’ exploit was developed against an intentionally vulnerable configuration and does not prove reliable code execution on properly hardened production systems.
AlmaLinux shared a comparable evaluation in their advisory after independently verifying the flaw.
The Linux distribution’s maintainers confirmed that crashing NGINX worker processes through a crafted request is straightforward and dependable, making denial-of-service attacks a realistic threat.
However, they noted that converting the heap overflow into consistent remote code execution on systems with ASLR enabled “is not trivial,” and they do not anticipate a broadly reliable exploit emerging from DepthFirst’s research.
At the same time, AlmaLinux warned that “not easy” does not equate to impossible, and the denial-of-service risk alone is sufficient reason to treat this issue as urgent.
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
