CTIPilot
AI-generated · no human review · verify critical claims against the linked source. how it works →
← Back to Daily brief 2026-07-20
HIGHCVE-2026-42533updatedNATOB2vulnerabilitydeep dive · network-stack-rce

CVE-2026-42533, nginx / NGINX Plus: PCRE capture-clobber pre-auth heap overflow, researcher demonstrates RCE beyond F5's DoS-only framing (CVSS 9.2)

F5 out-of-band patches a 15-year-old pre-auth heap overflow in nginx's script engine; credited researcher shows it reaches RCE

Defender actions

  • Upgrade every internet-facing nginx to ≥ 1.30.4 (stable) or 1.31.3 (mainline), and NGINX Plus to R36 P7 / 37.0.3.1, F5 released this out-of-band, so it is not carried by a normal release-train upgrade.
  • Before patching, audit each internet-facing nginx config for a regex map variable referenced after a regex capture ($1/$2/named groups from location/server_name/rewrite/if) in the same evaluated string; restructure (move the map reference before the capture, or split the expression) to remove the trigger on any host that cannot be patched immediately.

Analysis

CVE-2026-42533 is a missing save/restore of PCRE capture state across nginx's two-pass script-expression engine. nginx evaluates a compiled expression in a LEN pass that measures the result size and a VALUE pass that writes into a buffer sized by the LEN pass, and both passes resolve capture references such as $1 by reading r->captures, a shared mutable array on the request (Stan Shaw, 2026-07-19). When a map directive using a regex pattern is evaluated between the two passes, i.e. a config where a regex capture source (location, server_name, rewrite, or if) produces captures that appear before a regex map variable in the same evaluated buffer; the map's own regex evaluation clobbers the shared capture state, so the LEN and VALUE passes disagree on the buffer size. The result is an unauthenticated, pre-auth heap buffer overflow triggerable by crafted HTTP requests, reachable from any directive that evaluates a compiled expression (proxy_set_header, fastcgi_param, return, add_header, rewrite, set, root, alias, access_log, and more). The clobber is not specific to one call site: the same LEN/VALUE pattern appears in at least 13 independent call sites across 9 source files (Stan Shaw, 2026-07-19).

The bug has existed since nginx 0.9.6 (2011, when map gained regex support). F5 (which owns nginx) shipped an out-of-band fix on 2026-07-15/16 in nginx 1.30.4 (stable) and 1.31.3 (mainline), and in NGINX Plus R36 P7 and release 37.0.3.1, rating it CVSS 4.0 9.2 (critical) / CVSS 3.1 8.1 (high) (SecurityWeek, 2026-07-16). F5's advisory frames real-world risk on ASLR-enabled systems as primarily denial-of-service, a characterization the credited discoverer directly disputes (Stan Shaw, 2026-07-19; The Hacker News, 2026-07-19). The credited discoverer, Stan Shaw, disputes the DoS-only framing and demonstrates two chainable primitives: an information-leak variant (a clobbered capture smaller than the original) that returns uninitialised heap residue (on Ubuntu 24.04 with glibc 2.39 a libc pointer at offset 0x08 and a heap pointer at 0x10, enough to defeat ASLR in one unauthenticated GET) and a heap-overflow variant (a clobbered capture larger than the original) that writes attacker-controlled request-body content past the buffer and hijacks control flow through nginx's pool-cleanup mechanism, which the original post reported at 10/10 reliability with full ASLR enabled (Stan Shaw, 2026-07-19). The revised write-up refines that figure, as the update of 2026-09-29 below records. "A reader of the F5 advisory could reasonably conclude this is DoS-only on default systems. It is not," Shaw told The Hacker News (2026-07-19).

The author held back the proof of concept and the full write-up for about three weeks after the patch and has since published both (see the update below); no in-the-wild exploitation has been reported and the CVE is not in CISA KEV. The precedent the author cites is directly relevant: CVE-2026-42945 ("Rift"), a weaker flaw in the same nginx script engine that only mattered with ASLR disabled, "saw active exploitation shortly after its PoC dropped" (Stan Shaw, 2026-07-19; Rift's confirmed in-the-wild exploitation was covered here on 2026-05-18). This bug does not require ASLR to be off, so the same trajectory should be assumed now that the PoC is public.

Cited evidence

In one direction that is a heap overflow with attacker-controlled content and unbounded length. In the other it is an uninitialised heap read that hands back a libc pointer and a heap pointer. Chained, they give pre-auth RCE against a stock worker with full ASLR on.

This bug works with ASLR on, since the info leak primitive defeats it in a single GET request, and that is exactly why I wanted people to have time to patch first.

the patch has shipped and deployment windows have passed, so the proof of concept and the full exploitation write-up are now public

Stan Shaw (cyberstan.co.uk) 2026-07-19

Updates1

Update

The proof of concept is public. Three weeks after the patch the discoverer released it with the full exploitation write-up, writing that "the patch has shipped and deployment windows have passed, so the proof of concept and the full exploitation write-up are now public" (Stan Shaw, revised since). The PoC has three modes, crash, leak and RCE, plus a deterministic RCE variant. The crash and leak modes reproduce on any build of an affected version, which makes a worker crash and a heap-pointer leak available to anyone who can reach a vulnerable configuration. The RCE mode was developed against nginx 1.30.1 built from source on Ubuntu 24.04 with full ASLR, and the author notes that the deterministic variant depends on a controlled configuration whose heap layout is reproducible, which a stock deployment is not (0xCyberstan, CVE-2026-42533-POC; Stan Shaw, revised since). No in-the-wild exploitation has been reported and the CVE is not in CISA's KEV catalog as of 2026-09-29. The precedent the author gave for holding the PoC back, CVE-2026-42945, was exploited shortly after its own PoC appeared, so an unpatched instance with a regex map configuration should be treated as exposed to at least the crash and the leak today.

The revised write-up also refines the reliability figure the original post gave as 10/10. The leak worked on 100 out of 100 requests, but on a stock deployment a single exploit attempt lands "about two thirds of the time", and a miss crashes the worker, whose respawn inherits the same heap layout and misses the same way (Stan Shaw, revised since). Repeated worker crashes on a vulnerable configuration are therefore a plausible trace of a failed attempt.

Sources3

Revision history

  1. Published 2026-07-20T0409Z-intel
  2. Update 2026-09-29T2134Z-audit

    The discoverer has published the proof of concept and the full exploitation write-up, three weeks after the patch. The PoC has crash, leak and RCE modes: the crash and leak modes reproduce on any build of an affected version, and the RCE mode was developed against a source build on Ubuntu 24.04 with full ASLR. No in-the-wild exploitation is reported and the CVE is not in CISA KEV as of 2026-09-29. The summary, status and analysis no longer describe the PoC as withheld. The reliability figure is updated too: the leak worked 100 out of 100 times, and a single exploit attempt lands about two thirds of the time on a stock deployment. The defender takeaway no longer describes detection as pre-PoC.

    Changed: summary tags cves evidence sourcing_note body

PROVENANCE

AI-generated · no human review · this permalink is the shareable record for the finding · verify operationally critical claims against the linked primary source.