NGINX Hit by Critical 18-Year-Old Vulnerability — Patch Now

CVE-2026-42945 | CVSS 9.2 Critical | Heap Buffer Overflow | DoS + Potential RCE
Discovered: April 18, 2026 | Public Disclosure: May 18, 2026

A critical vulnerability hiding in NGINX's codebase for 18 years has been uncovered by AI-native security firm DepthFirst AI — and it's bad. The flaw can reliably crash NGINX worker processes with a single crafted HTTP request, and under the right conditions, may allow an unauthenticated attacker to execute arbitrary code remotely.

With NGINX powering roughly one-third of the world's top websites, the blast radius here is enormous. If you're running an unpatched version, treat this as urgent.

What Happened

Researchers at DepthFirst AI were running an autonomous code scanning session — six hours, no humans in the loop — when they hit gold. Not one bug, but four previously unknown vulnerabilities in NGINX, including a critical heap buffer overflow that's been sitting quietly in the codebase since around 2008.

The crown jewel, CVE-2026-42945, lives inside ngx_http_rewrite_module and affects every NGINX release from version 0.6.27 all the way up to 1.30.0.

How It Works

The bug is a classic case of a two-pass processing mismatch.

NGINX's internal script engine handles URL rewrites in two stages:

1. Allocation pass — calculates how much memory to reserve using unescaped URI lengths.
2. Write pass — copies the actual data, but writes escaped values that are physically larger (think + and & expanding in size).

The culprit is an is_args flag that stays incorrectly set after a rewrite rule contains a ?. The result: NGINX allocates a buffer that's too small, then overflows it. Heap buffer overflow.

This triggers when configs use both rewrite and set directives together — a pattern that's extremely common in API gateways and reverse proxies.

How Bad Is the Exploit?

Denial of Service — Trivially Exploitable

Crashing an NGINX worker with a crafted HTTP request is reliable and easy. AlmaLinux independently reproduced this. No special conditions required. DoS alone makes this a patch-now situation.

Remote Code Execution — Harder, But Not Off the Table

DepthFirst went further and demonstrated unauthenticated RCE by:

• Corrupting adjacent memory pool structures
• Overwriting cleanup handler function pointers
• Spraying fake structures into memory via POST body data
• Forcing NGINX to call system() during pool cleanup

The catch? Their PoC was demonstrated on a system with ASLR disabled — a memory protection that's on by default but sometimes turned off in embedded or virtualized environments for performance reasons.

The Respawn Problem

Here's what makes NGINX's architecture uniquely dangerous in this context: when a worker process crashes, the master process spawns a new one with an identical memory layout. Attackers get unlimited retries. No layout randomization between attempts. The researchers also suggest this could theoretically be abused to leak ASLR byte-by-byte through progressive pointer overwrites.

"If our exploit fails and crashes a worker, the master process simply spawns a new one with the exact same memory layout. This allows us to safely try multiple times until we succeed." — DepthFirst AI

Community Reaction

Not everyone is sounding full alarm bells on the RCE side.

Security researcher Kevin Beaumont pushed back, noting that reliable code execution requires a specific vulnerable config pattern, the attacker must know or identify the affected endpoint, and the published PoC was built against a deliberately weakened setup — not a hardened production system.

AlmaLinux, after independently reproducing the vulnerability, confirmed the DoS is real and trivial, but called dependable RCE on ASLR-enabled systems "not trivial" and said they don't expect a generic working exploit to emerge from DepthFirst's work.

That said — not easy isn't the same as impossible. And the DoS is enough on its own.

Affected Versions

What To Do

Patch (Preferred)

Update now. F5's advisory is live as of May 18, 2026.

Can't Patch Yet? Mitigate.

Replace unnamed PCRE capture groups ($1, $2, etc.) in your rewrite rules with named captures. F5 confirms this removes the primary exploitation prerequisite. It's not a permanent fix, but it buys time.

Bonus Bugs — Three More From the Same Session

All four found in the same six-hour automated scan. That's a rough Tuesday for NGINX.

References

• F5 Security Advisory (K000148656)
• NVD — CVE-2026-42945
• DepthFirst AI Research
• AlmaLinux Security Advisory