CVE-2026-42533: NGINX ASLR-enabled network RCE

CVE-2026-42533 is a memory-safety flaw in NGINX complex script/value evaluation for HTTP variables. A crafted configuration using regular-expression captures, a volatile map, slice/proxy processing, and a second overflow path can make the length pass and value-copy pass observe different capture contents. In the vulnerable commit, NGINX allocates based on the stale/short length and then copies attacker-controlled bytes from a later capture state, enabling a heap overwrite through real HTTP/TCP requests. The current run confirmed the full claimed impact: ASLR-enabled remote command execution from a separate network peer against NGINX commit 28219209e0b4f9e155fd8bd91ab81b8ac30628f2, with fixed commit b767540492e8c79a58bc26034d3bab2f708b7bd1 failing closed as a negative control.

• Package/component affected: NGINX Open Source, HTTP script/variable processing (src/http/ngx_http_script.c, related capture handling), exercised through the HTTP map, regex location, slice, and proxy modules.
• Affected versions: the vulnerable source commit validated by this run is 28219209e0b4f9e155fd8bd91ab81b8ac30628f2; the fixed negative-control commit is b767540492e8c79a58bc26034d3bab2f708b7bd1.
• Risk level and consequences: critical. A remote peer able to send crafted HTTP requests to the configured NGINX listener can turn the capture length/value mismatch into target-worker command execution when the vulnerable configuration preconditions are present. The proof command writes a harmless target-local marker and retrieves it via HTTP.

Impact Parity

• Disclosed/claimed maximum impact: code_execution through the NGINX HTTP/TCP listener while ASLR remains enabled.
• Reproduced impact from this run: code_execution. The final successful run created two run-unique target-local command markers in two fresh vulnerable NGINX workers and retrieved them through /rce-proof; the same attacker procedure against the fixed commit did not create markers.
• Parity: full.
• Not demonstrated: no stronger impact than command execution is claimed. Sanitizers, debugger-derived addresses, and disabled ASLR were not used by the primary proof.

Root Cause

The vulnerable path is a time-of-check/time-of-use mismatch inside NGINX script complex-value evaluation. During the length calculation pass, a variable/capture can have one size, but during the value-copy pass a volatile map and regex capture sequence can change the capture contents. The vulnerable code trusts the previously calculated size and does not check that later copied script-variable bytes still fit into the allocated destination buffer. The fixed commit b767540492e8c79a58bc26034d3bab2f708b7bd1 adds ngx_http_script_check_length and corresponding checks so a later value that exceeds the computed allocation is rejected instead of being copied past the destination.

Fix commit: https://github.com/nginx/nginx/commit/b767540492e8c79a58bc26034d3bab2f708b7bd1

Reproduction Steps

1. Run bundle/repro/reproduction_steps.sh from any directory. The script uses PRUVA_ROOT when set and otherwise resolves the bundle root relative to itself.
2. The script reads bundle/project_cache_context.json, reuses /pruva/project-cache/repo when the prepared cache is available, resolves and archives the exact vulnerable and fixed commits, verifies that the vulnerable source lacks ngx_http_script_check_length and the fixed source contains it, and builds hardened Docker images for each tree.
3. It generates the calibrated NGINX configuration and Python support programs at runtime, starts real NGINX target containers with ASLR enabled, and launches separate attacker containers on a Docker network. The attacker obtains same-worker disclosure data only through the NGINX HTTP listener, performs heap shaping and the overflow through HTTP/TCP, and retrieves /rce-proof through the NGINX listener.
4. Expected evidence of reproduction is two vulnerable trial logs containing EXPLOIT_CONFIRMED marker=..., marker files whose contents match the run-unique marker, two fixed negative-control observations with marker_present=false, and verifier evidence showing different randomized mappings between vulnerable trials.

Evidence

Primary evidence locations written by the script:

• bundle/logs/reproduction_steps.log — full build and runtime transcript.
• bundle/logs/randomize_va_space.log — kernel ASLR setting (2 in the final successful run).
• bundle/logs/patch_hunk_verification.log — vulnerable/fixed patch-hunk verification.
• bundle/logs/vulnerable-1.attacker.log and bundle/logs/vulnerable-2.attacker.log — separate network peer exploit transcripts.
• bundle/logs/vulnerable-1.marker and bundle/logs/vulnerable-2.marker — marker bodies retrieved through /rce-proof.
• bundle/logs/vulnerable-1.maps and bundle/logs/vulnerable-2.maps — verifier process maps captured after service start and not used as exploit inputs.
• bundle/logs/vulnerable-1.mitigations and bundle/logs/vulnerable-2.mitigations — readelf/ldd/file hardening and loader evidence.
• bundle/logs/fixed-1.attacker.log, bundle/logs/fixed-2.attacker.log, and fixed observation JSON files — fixed negative-control evidence.
• bundle/logs/proof_summary.json — structured summary combining vulnerable and fixed observations.
• bundle/repro/runtime_manifest.json — runtime-backed manifest for the TCP peer entrypoint.

Key excerpts from the final successful run:

• VULNERABLE_ATTEMPT_CONFIRMED role=vulnerable attempt=1 marker=PRUVA_42533_VULNERABLE_1_1784957428_6AA723FB
• VULNERABLE_ATTEMPT_CONFIRMED role=vulnerable attempt=2 marker=PRUVA_42533_VULNERABLE_2_1784957430_DAEE2FFD
• FIXED_NEGATIVE_CONTROL_OK role=fixed attempt=1 attacker_rc=1 marker_present=false marker=PRUVA_42533_FIXED_1_1784957432_FBE549D5
• FIXED_NEGATIVE_CONTROL_OK role=fixed attempt=2 attacker_rc=1 marker_present=false marker=PRUVA_42533_FIXED_2_1784957441_7727967F
• ASLR verifier: vulnerable executable mapping bases differ: 0x55d551e45000 vs 0x564f17702000

bundle/logs/proof_summary.json records confirmed=true, vulnerable build ID b9bb7df3e0b9ec8f3ea74448be3d11ca926eef45, vulnerable executable SHA-256 4b01896ce3283476723310e42a8f39f78d45c560309f546b90d7bd9e87a3d4a7, fixed build ID 2b428651367e71c91898b797fb532cb5a18ac8e2, and fixed executable SHA-256 16e242c2965b52ce9dfce13158d7812845e700e15d968c9f35dc2bf568fffdf1.

Recommendations / Next Steps

• Upgrade to a release or commit containing b767540492e8c79a58bc26034d3bab2f708b7bd1 or equivalent script length validation.
• Keep HTTP variable/capture regression tests that force length-pass and copy-pass capture divergence, including volatile map, regex location, proxy, and slice module combinations.
• Treat configurations that combine attacker-controlled regex captures with complex variable expansion as high-risk until patched.
• Maintain hardening such as PIE, NX, RELRO, stack canaries, and ASLR, but do not rely on those mitigations as a substitute for the length check.

Additional Notes

The reproduction is idempotent: it creates fresh Docker containers and a fresh Docker network per run, removes them on exit, rebuilds or verifies exact source commits, and writes fresh current-run evidence under bundle/logs/ and bundle/repro/. The final script version was executed successfully after all edits. Historical exploit-knowledge records were used only as reference mechanics; all verdict-relevant evidence comes from current script executions.