CVE-2026-42533: NGINX Regex Map Flaw Can Crash Workers and May Allow RCE

NGINX has patched CVE-2026-42533, a configuration-dependent vulnerability that can let an unauthenticated attacker crash worker processes and potentially execute code remotely. The underlying defect has existed since regex support was added to the map directive in NGINX 0.9.6 in March 2011.

Not every NGINX installation is immediately exploitable. A vulnerable server must use a specific combination of regular-expression captures and a regex-based map variable in an unsafe evaluation order. When those conditions exist, a crafted request can trigger a heap buffer overflow inside an NGINX worker.

The official NGINX security advisory lists versions 0.9.6 through 1.31.2 as vulnerable. Administrators should upgrade to NGINX 1.30.4 on the stable branch, NGINX 1.31.3 on the mainline branch, or the appropriate patched NGINX Plus release.

What Is CVE-2026-42533?

CVE-2026-42533 is a memory-safety vulnerability in the NGINX script engine. It arises when regex capture data stored in a shared request structure is overwritten while NGINX is building a string for a directive.

The F5 advisory K000162097 says a remote, unauthenticated attacker can send crafted requests that cause a heap buffer overflow when a vulnerable configuration is present. The immediate result can be worker-process termination and denial of service. Code execution may also be possible, particularly if address space layout randomization is disabled or bypassed.

The issue affects the NGINX data plane. F5 says the management or control plane is not exposed through this vulnerability.

Vulnerability detail	Information
CVE identifier	CVE-2026-42533
Affected component	NGINX script engine and regex capture handling
Attack access	Remote and unauthenticated when a vulnerable configuration exists
Primary impact	Worker crash, denial of service, information disclosure, and possible code execution
Configuration required	Regex captures combined with a regex-based map variable in an unsafe evaluation order
Patched open-source releases	NGINX 1.30.4 and 1.31.3

How the NGINX Buffer Overflow Works

NGINX evaluates some scripted strings in two stages. A length stage calculates how much memory is needed, and a value stage writes the final content into that allocated buffer.

Both stages can depend on regex captures such as $1, $2, or a named capture. These captures are stored in mutable request state. If a regex-based map is evaluated between capture references, it can replace the original capture information.

According to Stan Shaw’s technical analysis, the length and value stages can then operate on different capture values. The allocated buffer may be smaller or larger than the data handled during the write stage.

Capture-state mismatch	Potential result
The replacement capture is larger than the original	The value stage writes beyond the allocated buffer, causing heap corruption
The replacement capture is smaller than the original	The response may include uninitialized heap data

Can CVE-2026-42533 Lead to Remote Code Execution?

The vendor-backed impact includes denial of service and possible code execution. The public NVD record also describes a remotely reachable heap buffer overflow that depends on server-side configuration conditions outside the attacker’s control.

The researcher reports building a reliable exploit chain by combining an information leak with controlled heap corruption. Testing reportedly achieved remote code execution on Ubuntu 24.04 with ASLR enabled, using a leak request, approximately 40 heap-spraying connections, and a final overflow request.

This distinction matters for risk assessment. The possibility of remote code execution is supported by the vulnerability’s memory-corruption impact, but the specific claim of consistent exploitation with ASLR enabled comes from the researcher’s laboratory testing.

Which NGINX Versions Are Affected?

Product	Affected versions	Fixed version
NGINX Open Source, stable branch	0.9.6 through 1.30.3	1.30.4
NGINX Open Source, mainline branch	Up to and including 1.31.2	1.31.3
NGINX Plus R33 through R36	Unpatched releases through R36 P6	R36 P7
NGINX Plus 37	37.0.0.1 through 37.0.2.1	37.0.3.1

The official NGINX security page identifies 1.30.4 and 1.31.3 as the first non-vulnerable open-source releases. Both versions were released on July 15, 2026.

NGINX Plus customers should follow the fixed-release information in the F5 product advisory. Installing updates for unrelated 2026 NGINX vulnerabilities does not guarantee protection from CVE-2026-42533.

Which Configurations May Be Vulnerable?

Exposure depends on how a request is processed. A configuration may be vulnerable when a directive first references a capture produced by a regex and later evaluates a regex-based map variable while building the same output string.

The original capture can come from directives such as location, server_name, rewrite, or if. The vulnerable ordering may occur inside one directive or across separate directives evaluated in the same request context.

The flaw is not limited to ordinary HTTP proxy configurations. The research identified affected paths in both HTTP and stream modules, including at least 13 call sites across nine source files.

• proxy_set_header, proxy_method, proxy_pass, and proxy_set_body
• fastcgi_param, fastcgi_pass, uwsgi_param, and scgi_param
• grpc_set_header and related gRPC configuration processing
• return, rewrite, set, add_header, and add_trailer
• root, alias, index, and access_log

Named Captures and Cross-Directive Triggers

Administrators should inspect both numbered captures, such as $1, and named groups written in forms such as (?P<name>...). Named capture variables are stored differently, but the researcher found that they can create an independently exploitable form of the same underlying problem.

A simple search for a capture and a map inside one configuration line may therefore miss vulnerable cases. Includes, inherited settings, and the order in which multiple directives are evaluated can all affect exposure.

The CVE-2026-42533 record reflects this requirement by assigning high attack complexity. The attacker does not need credentials or user interaction, but the target must already contain the necessary configuration pattern.

Why the Vulnerability Remained Hidden for 15 Years

The affected code dates to NGINX 0.9.6, released in March 2011, when regex support was introduced for the map directive. The age refers to the vulnerable code path, not to the date the security issue became publicly known.

A 2014 NGINX ticket documented cases where regex captures could be overwritten during configuration processing. The behavior was recognized as a defect, but its memory-safety and remote-exploitation implications were not fully addressed at the time.

Shaw reported the security vulnerability to F5’s security team on May 17, 2026. F5 acknowledged the report the following day and coordinated fixes for open-source NGINX and NGINX Plus.

What the NGINX Patch Changes

The patch does more than preserve one set of numbered captures. It adds bounds checks before scripted data is written to an output buffer and tracks the amount of data actually produced.

If processing would exceed the allocated boundary, NGINX now stops the operation instead of writing past the buffer. An affected HTTP request should fail with an internal server error rather than corrupting worker memory.

Calculating output length from the bytes actually written also addresses the information-disclosure condition. This broader approach protects numbered and named capture paths covered by the flaw.

Exploit and Scanner Availability

No full public exploit had been released as of July 20, 2026. The researcher’s disclosure says the complete proof of concept and exploitation write-up will be withheld for 21 days after the July 15 patch release to give administrators time to update.

A non-exploit CVE-2026-42533 configuration scanner is available on GitHub. It examines NGINX configuration files for potentially unsafe capture and map evaluation sequences, follows included files, and can generate machine-readable results.

A clean scan should not replace patching. Static analysis may miss configurations generated dynamically, files that are unavailable to the scanner, or behavior introduced by third-party modules.

Recommended Actions for NGINX Administrators

1. Upgrade NGINX Open Source to 1.30.4 or 1.31.3, depending on the branch in use.
2. Upgrade NGINX Plus to R36 P7 or 37.0.3.1, as applicable.
3. Run the static configuration scanner across active configurations and included files.
4. Review regex-based map blocks and all references to numbered or named capture variables.
5. Check configurations generated by deployment systems, ingress controllers, templates, and automation platforms.
6. Monitor for repeated worker crashes, HTTP 500 responses, abnormal connection bursts, and unexpected NGINX restarts.
7. Confirm that ASLR and other operating-system memory protections remain enabled, while treating them as additional safeguards rather than substitutes for the patch.

Organizations should prioritize internet-facing reverse proxies, API gateways, load balancers, and multi-tenant systems. A vulnerable configuration can expose these systems to unauthenticated requests without requiring a valid account.

Administrators should also verify the version of the running NGINX binary after updating. Replacing a package without restarting the service can leave an older worker process active in memory.

Because configuration is central to exploitability, security teams should preserve the active configuration and relevant logs if suspicious crashes occurred before patching. These records may help determine whether the behavior was caused by routine errors, scanning, or an attempted exploit.

FAQ