CVE-2026-42533 is a heap buffer overflow in NGINX request processing that can crash worker processes and, under specific configurations, may allow pre-authentication remote code execution. NGINX Open Source versions 0.9.6 through 1.30.3 and mainline 1.31.2 contain the vulnerable code; the complete fix is in stable 1.30.4 and mainline 1.31.3 [1].
This is not a claim that every NGINX server is immediately exploitable. The dangerous path needs a configuration where regex capture variables and a regex-based map value are evaluated in an unsafe order. Because NGINX commonly sits in front of websites, APIs, and application servers, administrators should check both the installed build and the active configuration instead of relying on the version number alone.
Who Is Affected
| Deployment | Risk and decision |
|---|---|
| NGINX Open Source 0.9.6–1.30.3 or 1.31.2 | Vulnerable code is present. Upgrade to 1.30.4 or 1.31.3, then test and reload the configuration. |
| NGINX Plus before the fixed vendor build | Use the F5 product matrix and install the corresponding patched release. |
| Older package-manager build | Check the distributor security notice; a backported patch may keep an older-looking version string. |
No regex-based map and capture interaction |
The known trigger may be absent, but patching still removes the vulnerable code and is safer than treating configuration as permanent. |
Why the Configuration Matters
NGINX builds some strings in two passes: one pass calculates the required buffer length, and the next writes the value. The vulnerable interaction lets a regex map overwrite capture state between those passes. If the second pass writes more data than the first pass measured, the worker can write beyond the allocated heap buffer.
F5 describes denial of service through worker restart and possible code execution when Address Space Layout Randomization (ASLR) is disabled or bypassed [2]. Researcher Stan Shaw reports a separate information-leak direction that exposed heap pointers on Ubuntu 24.04 and allowed ASLR to be bypassed in his tests. That stronger RCE claim is independent research: the full exploit and proof of concept remain withheld, so administrators should treat it as a reason to patch promptly rather than as proof of active exploitation [3].
How to Check Without Sending an Exploit
- Record the running build. Use
nginx -vand confirm which binary and package actually serve traffic. - Dump the effective configuration safely. Review the output of
nginx -T, including files pulled in throughinclude. - Look for the required interaction. Prioritize blocks that combine regex captures such as
$1or named groups with a regex-basedmapvariable in the same string-building path. - Check upstream and generated configs. Hosting panels, ingress controllers, templates, and deployment automation can create vulnerable ordering outside the main
nginx.conf. - Do not test production with a crash or leak request. The reporter published a static configuration scanner that follows includes and checks preconditions without exploiting the server.
The safe scanner is useful for triage, but it is not a substitute for the patched binary. The same code path can be reached through multiple directives, and configurations change over time. A clean scan today does not make an unpatched worker safe indefinitely.
What to Do Now
- Upgrade to NGINX Open Source
1.30.4or1.31.3, or the matching fixed NGINX Plus release. - Run
nginx -tbefore reload and confirm the new worker processes use the expected binary afterward. - Review regex maps and capture references even after patching; simplifying fragile evaluation order reduces future configuration risk.
- Check error logs for unexplained worker exits, segmentation faults, or repeated restarts, but do not treat their absence as proof that the server was never exposed.
- If a public server showed suspicious crashes before the update, preserve logs and investigate the host for unexpected files, processes, credentials, and persistence rather than assuming the master process restart contained everything.
This issue is distinct from NGINX Rift CVE-2026-42945, which involved a different rewrite-rule pattern and was fixed in earlier releases. Installing only the May patch does not fix CVE-2026-42533.
References
- NGINX. “nginx-1.30.4 stable and nginx-1.31.3 mainline versions released.” NGINX Community Forum, July 15, 2026. Release announcement.
- NGINX. “Buffer overflow when using map and regex: CVE-2026-42533.” NGINX Security Advisories, accessed July 19, 2026. Security advisory.
- Stan Shaw. “15-Year-Old Pre-Auth nginx RCE Across 13 Call Sites: Two-Pass Capture Clobbering CVE-2026-42533.” cyberstan, July 2026, accessed July 19, 2026. Technical analysis.
