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

NGINX has long been regarded as one of the most reliable and high-performance web servers on the Internet, powering millions of websites, APIs, reverse proxies, Kubernetes ingress controllers, and cloud-native applications. That reputation makes the disclosure of CVE-2026-42533 particularly significant. Rather than affecting a recently introduced feature, the flaw traces back to March 2011, when regular expression support was added to the map directive. For over 15 years, a subtle bug inside nginx’s internal script engine remained unnoticed, only surfacing when a very specific combination of configuration directives caused its internal assumptions to break.

F5 addressed the vulnerability in nginx 1.30.4 (stable), 1.31.3 (mainline), and NGINX Plus 37.0.3.1, warning that specially crafted HTTP requests could trigger a heap buffer overflow in worker processes. Successful exploitation can terminate worker processes, causing denial of service, and under certain conditions may allow remote code execution. According to F5, exploitation requires a vulnerable configuration rather than simply running a vulnerable version of nginx, making configuration auditing just as important as patching.

Unlike many memory corruption vulnerabilities that originate from complex parsing logic, CVE-2026-42533 stems from an inconsistency between two internal execution phases responsible for building strings during request processing. The bug does not involve HTTP parsing itself, TLS handling, or request routing. Instead, it affects the scripting subsystem used by numerous directives such as proxy_set_header, proxy_pass, fastcgi_param, grpc_set_header, rewrite, return, root, alias, and others whenever they evaluate variables at runtime.

Previously: Critical NGINX Vulnerabilities Patched by F5

A Vulnerability Hidden in Plain Sight

The affected code is part of nginx’s internal script engine, a component responsible for evaluating variables before directives are executed. Administrators rarely interact with it directly, but it silently powers a large portion of nginx configuration processing.

Consider a configuration such as:

location ~ ^/api/(.+)$ {
    proxy_set_header X-ID "$1-$is_bot";
}

Here, $1 represents the first capture group from the location regular expression, while $is_bot may be generated through a separate map directive that itself evaluates another regular expression.

At first glance, this configuration appears perfectly valid. Internally, however, nginx performs considerably more work than simply replacing variables with strings.

Before allocating memory, nginx first calculates exactly how many bytes the final string will occupy. Only after determining the required size does it allocate a buffer and perform a second pass that writes the actual contents.

Normally, both passes observe identical variable values, ensuring the allocated buffer precisely matches the output.

CVE-2026-42533 breaks this assumption.

Understanding nginx’s Two-Pass Script Engine

To understand why the vulnerability exists, it helps to look at how nginx evaluates expressions.

Whenever nginx encounters a directive containing variables, it does not immediately generate the final string. Instead, it executes two independent phases.

The first phase, commonly called the LEN pass, walks through every variable and determines how many bytes the final string will require.

LEN PASS
"$1-$is_bot"
↓
Length($1)
+
Length("-")
+
Length($is_bot)
↓
Allocate Buffer

Once sufficient memory has been reserved, nginx performs a second execution.

VALUE PASS
"$1-$is_bot"
↓
Copy $1
Copy "-"
Copy $is_bot
↓
Final Output Buffer

This design is extremely efficient because it avoids repeated reallocations while building strings. The approach has existed inside nginx for years and is used extensively across the HTTP stack.

The vulnerability appears because both execution phases rely on a shared piece of mutable state.

The Role of PCRE Capture State

Whenever nginx evaluates a regular expression, the PCRE engine stores captured groups inside an internal request structure.

For a request such as:

GET /api/users HTTP/1.1

matched against:

location ~ ^/api/(.+)$

the first capture becomes:

$1 = users

Internally, nginx records the capture offsets inside the request object, commonly referenced as:

r->captures

Every subsequent $1, $2, or $3 reference reads from this shared capture array.

The design assumes those captures remain unchanged throughout script evaluation.

Unfortunately, that assumption does not always hold true.

Where Everything Goes Wrong

The vulnerability requires two separate regular expression evaluations during the same request.

The first regular expression usually comes from a directive such as:

location ~ ^/api/(.+)$

which populates:

$1 = users

Later during evaluation, nginx encounters a variable originating from a regex-based map.

For example:

map $http_user_agent $is_bot {
    ~*(bot|crawler) yes;
    default no;
}

Evaluating this map performs another regular expression match.

Instead of preserving the previous capture state, nginx overwrites the shared r->captures array with the captures generated by the new regex.

At this point the original $1 no longer points to the value captured by the location directive.

It now references completely different capture data.

The critical problem is that this overwrite occurs between the LEN pass and the VALUE pass.

During buffer size calculation, nginx still sees the original capture.

During data copying, nginx sees the overwritten capture.

The two phases no longer agree on the size of the output.

How a Heap Buffer Overflow Occurs

Imagine the following scenario.

The original URI capture contains only a few bytes:

$1 = abc

During the LEN pass nginx calculates:

Length = 3 bytes

A heap buffer slightly larger than three bytes is allocated.

Before the VALUE pass begins, the regex-based map evaluates another request field, replacing the capture state with attacker-controlled data.

The new capture now contains:

AAAAAAAAAAAAAAAAAAAAAAAAAAAA...

perhaps hundreds or thousands of bytes long.

When the VALUE pass executes, nginx copies the much larger value into the small heap allocation.

Allocated:
+---------+
| abc     |
+---------+
Written:
+-----------------------------------------------+
| AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA |
+-----------------------------------------------+

The write continues beyond the allocated buffer, corrupting adjacent heap memory.

Because both the overwritten data and its length originate from the HTTP request, the attacker controls both the contents and the extent of the overflow.

This is why F5 classifies the issue as a heap buffer overflow capable of crashing worker processes and potentially leading to remote code execution if additional exploit conditions are satisfied.

The Reverse Direction Produces a Different Primitive

The researcher who reported the issue, Stan Shaw, also describes the opposite scenario.

Instead of replacing a small capture with a large one, an attacker can cause the original capture to be very large while the overwritten capture becomes extremely small.

The LEN pass therefore allocates a large heap buffer.

The VALUE pass writes only a few bytes.

The remainder of the allocated memory is left untouched.

According to Shaw’s research, if nginx later returns this oversized buffer, portions of uninitialized heap memory may be exposed to the client, potentially leaking heap and libc pointers useful for bypassing Address Space Layout Randomization (ASLR). These findings go beyond F5’s advisory and should currently be considered the researcher’s analysis rather than a vendor-confirmed exploitation path. At the time of writing, proof-of-concept exploit code has not been publicly released.

This distinction matters because F5’s advisory explicitly states that remote code execution may be possible if ASLR is disabled or otherwise bypassed, whereas Shaw argues the vulnerability itself may provide the information disclosure necessary to defeat ASLR under certain conditions.

Why Most nginx Servers Are Not Automatically Vulnerable

One of the most misunderstood aspects of CVE-2026-42533 is that exposure depends on configuration, not just software version.

The vulnerable code path is reached only when several conditions are met simultaneously.

A request must first trigger a regular expression that populates capture variables such as $1. During evaluation of a later directive, nginx must execute a regex-based map that overwrites those captures. Finally, the original capture and the map variable must appear together within the same script expression in an order that allows the shared capture state to be replaced between the LEN and VALUE passes.

Because all of these requirements must align, many deployments running vulnerable nginx versions may never execute the affected path. Conversely, organizations with carefully crafted reverse proxy configurations, API gateways, or complex header manipulation rules may unknowingly satisfy every prerequisite.

This configuration dependency explains why the flaw remained undiscovered for over fifteen years. The underlying bug existed in the engine itself, but only a narrow combination of directives caused its internal state to become inconsistent. Rather than a classic parser vulnerability that triggers on any malformed request, CVE-2026-42533 is a state-management flaw that emerges only when nginx’s scripting engine evaluates multiple regular expressions within the same execution context.

Which Configurations Are Vulnerable?

One of the most important aspects of CVE-2026-42533 is that simply running a vulnerable version of nginx is not enough to make a server exploitable. The vulnerable code path is only reached when nginx evaluates multiple regular expressions within the same request and those evaluations interfere with one another.

At a high level, a vulnerable configuration typically consists of three components:

1. A directive that creates regex capture variables such as $1, $2, or $3.
2. A regex-based map directive that performs another regular expression match during request processing.
3. A script expression that references both values in an order that causes the capture state to be overwritten between the LEN and VALUE evaluation passes.

For example:

map $http_user_agent $is_bot {
    ~*(bot|crawler) yes;
    default no;
}
location ~ ^/api/(.+)$ {
    proxy_set_header X-Test "$1-$is_bot";
}

This configuration appears harmless. The location regex captures the request path, while the map evaluates the User-Agent header. However, both operations internally manipulate the same capture storage. If the capture state changes between the two evaluation passes, nginx measures one value and writes another.

That subtle inconsistency is the root cause of the vulnerability.

Why the Bug Survived for More Than Fifteen Years

At first glance, it may seem surprising that a memory corruption bug remained unnoticed for over a decade in software as widely deployed as nginx.

The explanation lies in the architecture of the script engine.

The vulnerable code does not execute for every HTTP request. It only becomes reachable when several independent features interact in a specific order. Most nginx deployments use either regex captures or map directives, but relatively few combine them within the same runtime expression.

Even among configurations that satisfy those requirements, the captured values usually have similar lengths. If the original capture and the overwritten capture happen to be nearly identical in size, the overflow is either extremely small or does not occur at all. This makes the bug difficult to notice during normal operation, automated testing, or fuzzing.

Only when an attacker deliberately manipulates the request so that the two captures differ significantly in size does the vulnerability become obvious.

This explains why the flaw could remain dormant for years despite countless production deployments processing billions of requests every day.

Directives That Can Reach the Vulnerable Script Engine

The vulnerable logic is not limited to a single nginx directive. Instead, it affects the internal scripting subsystem responsible for evaluating variables before execution.

As a result, many commonly used directives rely on the same code path, including:

• proxy_set_header
• proxy_pass
• proxy_method
• fastcgi_param
• uwsgi_param
• scgi_param
• grpc_set_header
• return
• rewrite
• set
• add_header
• root
• alias
• access_log

Not every use of these directives is vulnerable. They become relevant only when the evaluated expression combines regex captures with variables generated by a regex-based map.

This distinction is important because administrators should avoid assuming that every occurrence of these directives is affected.

A Look Inside the Patch

The official fix is remarkably small considering its impact.

The vulnerability exists because nginx stores regular expression captures in shared request state. During script execution, that state is overwritten without preserving the values expected by the earlier evaluation pass.

Rather than redesigning the entire scripting engine, the patch saves the capture state before evaluating a regex-based map and restores it immediately afterward.

Conceptually, the fix changes the workflow from this:

Capture A
      │
LEN PASS
      │
Map executes
      │
Capture overwritten
      │
VALUE PASS

to this:

Capture A
      │
LEN PASS
      │
Save captures
      │
Map executes
      │
Restore captures
      │
VALUE PASS

After restoration, both passes observe identical capture data.

The measured length now matches the copied data, eliminating the inconsistency that allowed heap corruption.

This is a classic example of fixing a state-management bug rather than a memory allocation bug. The allocator itself was functioning correctly. The problem was that nginx measured one object and later copied another.

Can the Vulnerability Really Lead to Remote Code Execution?

F5’s advisory takes a conservative position.

According to the vendor, the vulnerability can reliably cause worker crashes and denial of service. Remote code execution may be possible if Address Space Layout Randomization (ASLR) is disabled or can be bypassed.

The researcher who reported the issue argues that the vulnerability provides both requirements needed for exploitation.

First, an attacker obtains an information disclosure primitive capable of leaking heap and libc addresses. Those leaked pointers can then be used to defeat ASLR.

Second, the attacker uses the heap overflow primitive to corrupt memory using precisely controlled data.

According to the published research, combining these primitives allows reliable exploitation under default Ubuntu 24.04 configurations. However, these exploitation details have not yet been independently verified by F5 or accompanied by a public proof-of-concept at the time of writing. Administrators should therefore distinguish between the confirmed vulnerability and the researcher’s proposed exploitation chain.

Regardless of the exact exploitation reliability, a remotely reachable heap overflow in one of the world’s most widely deployed web servers should be treated as a critical issue.

Temporary Mitigations

Organizations unable to upgrade immediately still have options to reduce exposure.

F5 recommends replacing numbered captures such as $1 with named capture groups where possible. This prevents the most common vulnerable configuration from occurring and reduces the attack surface until patches can be deployed.

However, Stan Shaw notes that this mitigation may not completely eliminate every variant. According to his analysis, if both the location regex and the map define the same named capture, a similar capture-clobbering condition may still occur through a different execution path. These findings are based on the researcher’s testing and are not reflected in F5’s advisory.

For that reason, configuration changes should be viewed only as temporary risk reduction.

Upgrading remains the only complete remediation.

Detecting Vulnerable Configurations

Unlike vulnerabilities that can be identified by checking software versions alone, CVE-2026-42533 requires administrators to inspect nginx configurations.

The goal is to identify situations where:

• a regex directive creates capture variables,
• a regex-based map executes later during evaluation, and
• both variables participate in the same runtime expression.

Because nginx configurations often span dozens or hundreds of files through nested include directives, manually auditing production deployments can be difficult.

To help defenders, the reporting researcher released a static configuration scanner that follows includes and identifies potentially vulnerable directive orderings without attempting exploitation. While useful for identifying exposure, it should complement rather than replace upgrading to a fixed release.

Affected Versions

According to F5, the following releases are affected:

The vulnerability also affects several downstream F5 products built on nginx, including NGINX Ingress Controller, Gateway Fabric, App Protect WAF, and Instance Manager. Administrators should monitor F5 for product-specific updates and patched releases.

A Broader Pattern in Recent nginx Vulnerabilities

CVE-2026-42533 is not an isolated incident.

In recent months, nginx has addressed several high-profile memory corruption vulnerabilities, including NGINX Rift (CVE-2026-42945) and the rewrite-module capture handling flaw CVE-2026-9256.

Although each vulnerability is triggered differently, they share an architectural theme. The script engine frequently performs a length calculation before writing data into the allocated buffer. When internal state changes between those operations, the assumptions made during allocation no longer hold.

In CVE-2026-42945, stale internal state caused the calculated length to become inaccurate.

In CVE-2026-9256, overlapping capture handling produced a similar mismatch.

In CVE-2026-42533, the problem is caused by overwritten PCRE capture state.

The immediate triggers differ, but all three vulnerabilities illustrate how two-phase evaluation becomes fragile when shared mutable state is introduced between measurement and output.

Final Thoughts

CVE-2026-42533 demonstrates that some of the most dangerous vulnerabilities are not introduced by new features but by long-standing design assumptions that quietly fail under unusual conditions. A missing save-and-restore operation inside nginx’s scripting engine was enough to create a remotely reachable heap buffer overflow that remained undiscovered for roughly fifteen years.

For most administrators, the priority should be straightforward: upgrade to nginx 1.30.4, 1.31.3, or the corresponding patched NGINX Plus release as soon as possible. Organizations with complex reverse proxy configurations should also review their use of regex captures and regex-based map directives, especially where both appear within the same evaluated expression.

While public exploit code has not yet been released, history suggests that sophisticated memory corruption vulnerabilities in widely deployed infrastructure software rarely remain theoretical for long. Applying the available patches before exploitation techniques become public is the most effective way to reduce risk.