Skip to content

NGINX CVE-2026-42533 two-pass capture-clobbering RCE risk

Summary

CVE-2026-42533 is a configuration-dependent heap-buffer-overflow vulnerability in the NGINX script engine. NGINX fixed it on 2026-07-15 in open-source 1.30.4 stable and 1.31.3 mainline. The vulnerable code dates to NGINX 0.9.6 and remains present through 1.30.3 and 1.31.2.

The bug appears when a request-time string expression evaluates a capture from an earlier regular-expression match before a variable backed by a regex map. The map evaluation replaces shared capture state between NGINX's length-calculation and value-writing passes. The first pass can therefore allocate for one capture length while the second writes a different attacker-controlled length, producing worker-process memory corruption.

F5 describes denial of service and potential remote code execution where ASLR is disabled or bypassed. Researcher Stan Shaw reports a complementary uninitialized-memory disclosure that can reveal heap and libc pointers and defeat ASLR on a tested default Ubuntu 24.04 build, making reliable pre-authentication RCE possible under the vulnerable configuration. That stronger exploitability claim is public research, not independently reproduced vendor guidance; no public proof of concept or confirmed in-the-wild exploitation of CVE-2026-42533 was identified at publication.

Tags

Why this matters

  • NGINX is widely deployed as an internet-facing web server, reverse proxy, ingress layer, and application-delivery component.
  • Affected versions span roughly 15 years, so version-only inventory will identify a broad population even though actual exploitability also depends on configuration.
  • The overflow length and content can be controlled through ordinary unauthenticated HTTP request fields once the required regex-capture and regex-map ordering exists.
  • The same state mismatch can reportedly run in reverse and expose uninitialized heap data, potentially weakening the ASLR condition in F5's RCE assessment.
  • F5's advisory also lists NGINX Plus and NGINX-based products, including Ingress Controller, Gateway Fabric, App Protect WAF, and Instance Manager; defenders should use the vendor matrix rather than assuming an appliance or container image is unaffected.

Technical characteristics

  • Affected open-source range: NGINX 0.9.6 through 1.30.3 stable and 1.31.2 mainline.
  • Fixed open-source builds: 1.30.4 stable and 1.31.3 mainline.
  • NGINX Plus fix: 37.0.3.1; consult the F5 advisory for earlier release-branch fixes and product-specific status.
  • Required pattern: an earlier regex source such as location, server_name, rewrite, or if produces a numbered capture, and a later-evaluated variable is backed by a regex map that overwrites shared capture state.
  • Engine failure: NGINX evaluates complex strings in a length pass, allocates that measured size, then performs a value pass. Regex-map evaluation mutates r->captures and r->captures_data, so the two passes can disagree.
  • Reachable directives: the researcher identified affected expression paths including proxy_set_header, proxy_method, proxy_pass, FastCGI/uwsgi/SCGI/gRPC parameters, return, add_header, rewrite, set, root, alias, and access_log, across HTTP and stream modules.
  • Outcomes: worker crash/restart and denial of service; controlled heap overflow with possible code execution; and, according to the researcher, uninitialized-memory disclosure sufficient to recover heap/libc pointers in the tested environment.

Defender actions

  1. Upgrade rather than relying on configuration review. Move open-source NGINX to 1.30.4 or 1.31.3 or later, and apply the corresponding fixed NGINX Plus/product release from F5.
  2. Inventory packaged and embedded NGINX. Check container images, Kubernetes ingress components, gateways, WAFs, management products, and vendor appliances—not only standalone nginx services.
  3. Audit vulnerable expression ordering. Find regex map blocks and trace where their variables are evaluated after numbered captures such as $1 from regex location, server_name, rewrite, or if expressions. Cross-directive ordering in the same request context can matter.
  4. Use named captures only as a temporary mitigation. F5's reported workaround is to replace affected numbered regex captures with named captures. Validate against the vendor advisory and still schedule the fixed build.
  5. Preserve evidence before restart or rebuild if exploitation is suspected. Collect access/error logs, reverse-proxy/WAF telemetry, core dumps, worker crash/restart events, service-manager logs, container events, and memory where feasible.
  6. Hunt behaviorally. Look for repeated crafted requests immediately preceding worker segmentation faults, abnormal restart loops, unexpected large request fields interacting with regex-routed paths, and follow-on child processes, modified web content, new credentials, or outbound connections from the NGINX security context.

Exploitation-status caveat

CVE-2026-42533 should not be labeled actively exploited based on the public material reviewed here. Shaw cites exploitation of the related May 2026 NGINX rewrite-module flaw CVE-2026-42945 after proof-of-concept publication as a reason to withhold the new exploit, but that history is not evidence that CVE-2026-42533 itself has been exploited. Treat exposed vulnerable configurations as urgent patching and monitoring candidates without converting risk into an unsupported incident claim.

Sources