18-Year-Old NGINX Bug Allows DoS and Remote Code Execution

Key Takeaways

• CVE-2026-42945 is a heap buffer overflow affecting NGINX versions 0.6.27 through 1.30.0, present in the codebase for 18 years
• The flaw received a critical 9.2 CVSS score and can be triggered through common rewrite and set directive configurations
• Remote code execution was demonstrated on systems with ASLR disabled, though denial of service is possible regardless

The Vulnerability That Hid for Nearly Two Decades

Security researchers at DepthFirst AI have discovered a critical vulnerability in NGINX that has existed in the web server's codebase for approximately 18 years. The flaw, tracked as CVE-2026-42945, received a severity rating of 9.2 on the CVSS scale, placing it firmly in the critical category.

The discovery came during a six-hour autonomous code scanning session that also uncovered three additional memory corruption issues. NGINX powers roughly one-third of the top-ranked websites globally and serves as a reverse proxy platform for cloud providers, SaaS companies, banks, media platforms, e-commerce sites, and Kubernetes clusters.

How the Flaw Works

CVE-2026-42945 is a heap buffer overflow in the ngx_http_rewrite_module. It affects NGINX versions 0.6.27 through 1.30.0. The vulnerability can be triggered when NGINX configurations use both the 'rewrite' and 'set' directives together. According to DepthFirst, this pattern is common in API gateways and reverse proxy setups.

The root cause lies in inconsistent state handling within NGINX's internal script engine. The engine processes rewrites in two passes: first to calculate how much memory to allocate, then to copy the actual data. The problem occurs when an 'is_args' flag remains set after a rewrite containing '?'. This causes NGINX to calculate buffer size using unescaped URI lengths but then write larger escaped data (characters like '+' and '&'), resulting in a heap buffer overflow.

Exploitation and Impact

Researchers demonstrated that unauthenticated code execution is possible through specially crafted HTTP requests. The attack chain involves corrupting adjacent NGINX memory pool structures, overwriting cleanup handler pointers, spraying fake structures into memory via POST request bodies, and forcing NGINX to execute 'system()' during pool cleanup.

There is an important caveat. Remote code execution was achieved only on a system with Address Space Layout Randomization (ASLR) turned off. ASLR is a memory protection feature that is active by default on most systems. However, it is sometimes disabled to improve performance in environments like embedded systems and virtual machines used for analysis.

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

— DepthFirst AI researchers

DepthFirst notes that NGINX's multi-process architecture actually makes exploitation easier. Worker processes inherit nearly identical memory layouts from the master process. This enables reliable heap manipulation and allows attackers repeated attempts if a worker crashes.

Who Is Affected

The vulnerability affects an enormous range of deployments. NGINX is owned and maintained by F5, and it serves as critical infrastructure for load balancing, content caching, and reverse proxy functionality. Any organization running NGINX versions 0.6.27 through 1.30.0 with configurations using both 'rewrite' and 'set' directives should evaluate their exposure.

Organizations running NGINX in API gateway configurations face the highest risk, as these deployments commonly use the vulnerable directive pattern. Systems with ASLR disabled are at risk of full remote code execution, while those with standard protections enabled remain vulnerable to denial of service attacks.

AI-Powered Discovery

The vulnerability was found by DepthFirst AI, an AI-native security company, using an autonomous scanning system. The fact that a six-hour scanning session uncovered four memory corruption issues, including one hiding in plain sight for 18 years, raises questions about what else might be lurking in widely deployed open-source infrastructure.

This discovery joins a growing trend of AI-assisted vulnerability research. Traditional code auditing methods apparently missed this flaw despite nearly two decades of active development and security scrutiny on one of the internet's most critical pieces of software.

What To Do Now

1. Check your NGINX version. Affected versions are 0.6.27 through 1.30.0.
2. Audit configurations for the 'rewrite' and 'set' directive pattern, especially in API gateway and reverse proxy setups.
3. Ensure ASLR is enabled on all production systems running NGINX.
4. Monitor F5's security advisories for patch information.
5. Consider implementing web application firewall rules to filter malicious requests until patches are applied.

Frequently Asked Questions

Is my NGINX server affected by CVE-2026-42945?

If you're running NGINX versions 0.6.27 through 1.30.0 and your configuration uses both 'rewrite' and 'set' directives together, your server is potentially vulnerable. This pattern is particularly common in API gateway and reverse proxy setups.

Can attackers run code on my server through this vulnerability?

Remote code execution was demonstrated only on systems with ASLR (Address Space Layout Randomization) disabled. With ASLR enabled, which is the default on most modern systems, the vulnerability can still cause denial of service but code execution becomes significantly harder.

How was this vulnerability hidden for 18 years?

The flaw existed in ngx_http_rewrite_module since version 0.6.27. It involves subtle inconsistencies in how NGINX's script engine handles memory allocation across two processing passes. Traditional code auditing apparently missed it until DepthFirst AI's autonomous scanning system flagged the issue.

What should I do to protect my NGINX servers?

Verify your NGINX version and check for vulnerable configuration patterns. Ensure ASLR remains enabled on production systems. Monitor F5's security channels for patch releases. Consider temporary WAF rules to filter potentially malicious requests.

Why does NGINX's architecture make this easier to exploit?

NGINX uses a multi-process architecture where worker processes inherit nearly identical memory layouts from the master process. If an exploit attempt crashes a worker, the master spawns a new one with the same layout, giving attackers multiple attempts to succeed.

Source: BleepingComputer