CVE-2026-42533 Exploit & Vulnerability Analysis

The Exploit

An unauthenticated attacker can trigger a heap buffer overflow by sending a crafted HTTP request to an endpoint that uses a map directive with regex matching and a string expression referencing regex capture variables before the map output variable.

GET /?a=AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA HTTP/1.1
Host: target.com
User-Agent: Mozilla/5.0
Accept: */*

The attacker observes an NGINX worker process crash with a SIGSEGV signal and a restart. The error log contains entries like:

2026/05/01 12:34:56 [alert] 12345#0: *1 writev() failed (14: Bad address)
2026/05/01 12:34:56 [crit] 12345#0: *1 ngx_slab_alloc() failed: no memory

Under controlled conditions (ASLR disabled or attacker can bypass ASLR), this memory corruption can be weaponized for arbitrary code execution.

What the Patch Did

Before (vulnerable ngx_http_script_copy_code):

    p = e->pos;
    if (!e->skip) {
        e->pos = ngx_copy(p, e->ip + sizeof(ngx_http_script_copy_code_t),
                          code->len);
    }

After (fixed ngx_http_script_copy_code):

    p = e->pos;
    if (!e->skip) {
        if (ngx_http_script_check_length(e, code->len) != NGX_OK) {
            return;
        }
        e->pos = ngx_copy(p, e->ip + sizeof(ngx_http_script_copy_code_t),
                          code->len);
    }

The patch adds a bounds check using the new ngx_http_script_check_length() function, which verifies that the write destination (e->pos) will not exceed the buffer boundary (e->end). This is a classic buffer overflow guard implemented as a runtime length validation before each memory copy operation in the script engine.

Root Cause

CWE-122: Heap-based Buffer Overflow. The dataflow begins when an attacker-specified HTTP request triggers NGINX's map directive with regex matching. The regex captures are referenced in a string expression before the map output variable. During script execution, ngx_http_script_complex_value_code (line ~1790) sets e->pos = e->buf.data and e->sp->len = e->buf.len, but no e->end is set to track the buffer boundary. Subsequent copy operations in ngx_http_script_copy_code, ngx_http_script_copy_capture_code, and similar handlers blindly increment e->pos without checking whether the remaining space is sufficient for the length they copy. The attacker controls the length of capture groups through crafted regex patterns and can cause the copied data to overflow the allocated value->data buffer, corrupting adjacent heap memory.

Why It Works

The single load-bearing line is e->end = value->data + len; in the ngx_http_script_run function (line ~97 in the fix). Without this initializer, all subsequent ngx_http_script_check_length() calls would short-circuit because e->end == NULL triggers the early-exit path if (e->end == NULL) return NGX_OK;. The engineer added it as the fundamental boundary anchor. The other additions — the check_length function itself, the per-copy calls to it, and the e->status propagation — are all secondary: they implement the enforcement mechanism, but the enforcement only activates if e->end is correctly set at allocation time. The order matters: first set the end bound (prevention anchor), then check against it (runtime guard). If the engineer had only added the checks without that initializer, the vulnerability would remain exploitable.

Hardening Checklist

1. Initialize buffer boundaries immediately after allocation — Every time a dynamically allocated buffer is created for script output, set a corresponding end pointer (buffer + allocated_length) before any writes occur. This mirrors the e->end = value->data + len pattern.
2. Add guard functions for every write path — Implement a length validation function (like ngx_http_script_check_length()) and call it before every ngx_copy() or memcpy() that writes into the buffer. Ensure the guard short-circuits safely (returns error) when buffer space is insufficient.
3. Propagate errors through execution state — Use a status field in the script engine struct (like the new e->status) to propagate failures from guards up to the caller, rather than silently continuing execution after a bounds violation.
4. Sanitize length calculations in capture handlers — When using regex capture groups to compute copy lengths, ensure the length is cast to size_t before subtraction to prevent integer underflow (as seen in ngx_stream_script_copy_capture_len_code where cap[n+1] - cap[n] had no size_t cast).

References

• https://nvd.nist.gov/vuln/detail/CVE-2026-42533
• (CVE record not yet published on Wordfence at time of writing)
• (Vendor changelog not publicly available)