15-Year-Old NGINX Vulnerability Lets Attackers Crash Workers and Achieve Remote Code Execution

A newly disclosed flaw tracked as CVE-2026-42533 affects nginx’s script engine and has been silently exploitable since March 2011, when the map directive gained regex support.

Security researcher Stan Shaw reported the bug to F5 SIRT, which coordinated a fix released in nginx 1.30.4 (stable) and 1.31.3 (mainline), along with corresponding patches for NGINX Plus R33–R36 (fixed in R36 P7) and 37.0.0.1–37.0.2.1 (fixed in 37.0.3.1).

The vulnerability is a pre-authentication remote code execution flaw rooted in a missing save/restore of PCRE capture state in nginx’s internal script engine.

nginx evaluates expressions in two passes a LEN pass to measure buffer size and a VALUE pass to write the actual data, and both rely on a shared, mutable array called r->captures. When a map directive with a regex pattern executes between two references to a capture group (like $1), it silently overwrites that shared state, causing the LEN and VALUE passes to disagree on size.

15-Year-Old NGINX Vulnerability

This mismatch produces two distinct attack primitives:

• Heap buffer overflow: when the clobbered capture is larger than the original, the VALUE pass writes more data than the buffer was sized for, corrupting adjacent heap memory with fully attacker-controlled content.
• Information leak: when the clobbered capture is smaller, the buffer is oversized, and the response leaks uninitialized heap bytes — including libc and heap pointers sufficient to defeat ASLR in a single unauthenticated GET request.

Chained together, these two primitives allow an attacker to achieve reliable RCE using roughly one leak request, about 40 spray connections, and one overflow-triggering request reported at 10/10 reliability on Ubuntu 24.04 with full ASLR enabled.

According to the Cyberstan report, the bug isn’t limited to a single directive. It spans at least 13 independent call sites across 9 source files, affecting both the HTTP and stream modules. Any configuration combining a regex capture source (location, server_name, rewrite, or if blocks) with a regex-based map variable evaluated afterward in the same request context is potentially exploitable — even across separate directives in the same location block.

Commonly affected directives include:

• proxy_set_header, proxy_method, proxy_pass, fastcgi_param, uwsgi_param, scgi_param
• grpc_set_header, return, add_header, rewrite, set
• root, alias, access_log, and several others

A separate, independently exploitable variant exists through named capture groups ((?P...)), which are cached differently and won’t be fixed by a patch that only addresses numbered captures.

Affected Versions

Notably, recent fixes for other nginx bugs — CVE-2026-42945, CVE-2026-9256, CVE-2026-42055, and CVE-2026-48142 — do not address this issue, meaning organizations that patched for those flaws remain exposed.

Remarkably, this exact tricky behavior was first flagged over a decade ago in a 2014 nginx trac ticket, where developer Maxim Dounin acknowledged it as a defect, but it was never fully remediated as a security-critical issue.

The researcher has released a static config scanner on GitHub (0xCyberstan/CVE-2026-42533-Config-Scanner) that identifies vulnerable directive orderings without exploiting anything, giving defenders a way to audit exposure immediately.

The full proof-of-concept and exploitation write-up are being withheld for 21 days after the patch to give administrators time to update, a decision informed by the rapid weaponization seen after CVE-2026-42945 (“NGINX Rift”) went public.

Tactical Security Recommendations

• Upgrade immediately to nginx 1.30.4, 1.31.3, or the corresponding patched NGINX Plus release.
• Run the static scanner against production configs to identify vulnerable directive orderings.
• Audit any location block combining regex captures with regex-based map variables, and restructure configs to avoid capture references appearing before or after map variable evaluation.
• Treat this as urgent even if HTTP/3 or other recently patched modules are not in use, since this flaw is independent of those fixes.

 Strengthen Your SOC by Accelerating Threat Detection & Rapid Investigations. -> Integrate ANY.RUN With Your SOC Now.