A vulnerability that has sat undetected in nginx’s internals since 2011 has just been disclosed, and it is a serious one. Tracked as CVE-2026-42533, the flaw allows an unauthenticated attacker to achieve remote code execution against nginx workers by abusing a quirk in how the web server evaluates regular expression captures. It has taken fifteen years, a security researcher named Stan Shaw, and a coordinated response from F5 to finally bring the issue into the open.

Where the Bug Actually Lives

The root cause traces back to March 2011, when nginx’s map directive gained support for regular expressions. Every time nginx evaluates an expression, it runs two passes: a “LEN” pass that calculates how large a buffer needs to be, and a “VALUE” pass that actually writes the data into that buffer. Both passes lean on a shared, mutable array that stores regex capture groups.

The problem arises when a map directive using a regex pattern executes in between two references to a capture group, such as $1. That evaluation silently overwrites the shared capture state, so the earlier LEN pass and the later VALUE pass end up disagreeing about how big the buffer should be. That mismatch is the seed of the entire exploit chain.

Two Attack Primitives, One Reliable Exploit

According to the disclosure, this mismatch can be steered in two directions, depending on how the capture is clobbered:

• If the corrupted capture ends up larger than intended, the VALUE pass writes past the allocated buffer, producing a heap buffer overflow with attacker-controlled content.
• If it ends up smaller, the buffer is left oversized, and the server leaks uninitialized heap memory back to the client, including pointers that can defeat ASLR.

Researchers found that chaining these two primitives together produces a remarkably reliable attack path: roughly one request to leak memory, around 40 spray connections to groom the heap, and a final request to trigger the overflow. In testing against Ubuntu 24.04 with ASLR fully enabled, the exploit reportedly succeeded 10 times out of 10.

Wider Than a Single Directive

What makes this disclosure especially concerning is scope. The underlying flaw isn’t confined to one configuration pattern; researchers identified at least 13 independent call sites spread across nine source files, touching both the HTTP and stream modules. Any nginx configuration that combines a regex capture source, such as a location, server_name, rewrite, or if block, with a regex-based map variable evaluated afterward in the same request is potentially exploitable. That includes common directives such as proxy_set_header, proxy_pass, fastcgi_param, add_header, rewrite, and alias, among others. A separate variant involving named capture groups exists as well, and is not automatically remediated by patches targeting numbered captures.

Notably, several recent nginx security fixes, including patches for CVE-2026-42945, CVE-2026-9256, CVE-2026-42055, and CVE-2026-48142, do nothing to address this particular issue. Organizations that believe they are current on nginx patching may still be exposed.

Fixes and What Defenders Should Do Now

F5 has shipped fixes across the nginx product line: version 1.30.4 for the stable branch, 1.31.3 for mainline, R36 P7 for NGINX Plus R33–R36, and 37.0.3.1 for the newer NGINX Plus line. Given the exploit’s reliability and the breadth of affected configurations, security teams should treat this as an urgent patch regardless of whether they use any of the other recently patched nginx modules.

The researcher has also published a static configuration scanner that identifies risky directive orderings without needing to exploit anything, giving defenders a way to audit their exposure before patching. The full technical write-up and proof-of-concept are being withheld for a 21-day window following the patch release, a decision informed by how quickly a previous nginx flaw was weaponized once details went public.

Recommended Actions

• Upgrade immediately to nginx 1.30.4, 1.31.3, or the equivalent patched NGINX Plus release.
• Run the publicly released static scanner against production configurations to flag risky directive orderings.
• Audit any location block that mixes regex captures with regex-based map variables, and restructure configs where captures are referenced both before and after a map evaluation.
• Do not assume recent, unrelated nginx CVE patches have already closed this gap.

Given that this bug went unnoticed for over a decade despite being flagged internally as far back as 2014, it is a reminder that even mature, heavily audited software can carry silent, high-severity defects for years before anyone connects the dots.