CVE-2026-42945: Heap-based Buffer Overflow in NGINX ngx_http_rewrite_module

NGINX utilizes the ngx_http_rewrite_module to process URI modification directives, including rewrite, set, and if statements. This module relies on a specialized internal script engine to evaluate variables and string substitutions dynamically during request processing. The vulnerability, tracked as CVE-2026-42945, resides within this script evaluation framework and specifically affects how the engine handles state flags during multi-phase execution.

The flaw represents a classic Heap-based Buffer Overflow (CWE-122) condition. It manifests when a configuration uses a rewrite directive containing a query string delimiter (?), immediately followed by another directive that references unnamed capture groups ($1, $2). The presence of the query string delimiter modifies an internal flag (is_args), altering how subsequent operations calculate necessary memory allocations.

Discovered by researcher Zhenpeng (Leo) Lin of depthfirst, the vulnerability has existed in the NGINX codebase since version 0.6.27, released in 2008. The issue was introduced as part of performance optimizations aimed at standardizing variable evaluation memory overhead. The vulnerability exposes any internet-facing NGINX instance that implements the specific, albeit uncommon, vulnerable configuration pattern.

Successful exploitation results in severe memory corruption within the NGINX worker process. While the primary and most consistent impact is a Denial of Service (DoS) through worker process termination, precise heap manipulation permits remote code execution. Exploitation requires no authentication, rendering affected configurations highly vulnerable to automated exploitation sequences.

The root cause of CVE-2026-42945 lies in a state inconsistency during the NGINX script engine's two-pass execution cycle. To optimize memory allocation, NGINX evaluates script directives in two distinct phases: a Length Calculation pass (Pass 1) and a Data Copy pass (Pass 2). Pass 1 iterates over all script components to compute the exact byte length required for the final string, allowing NGINX to perform a single contiguous heap allocation.

When a rewrite directive's replacement string contains a question mark (?), NGINX sets the is_args flag on the primary script engine structure (e->is_args = 1). This flag indicates that subsequent string data represents URI arguments, which require standard URI escaping according to RFC 3986. The vulnerability occurs because this is_args flag fails to propagate to the temporary sub-engine utilized exclusively during Pass 1.

During Pass 1, the function ngx_http_script_complex_value_code initializes a zeroed sub-engine (le) to calculate the required length of captured variables. Because the structure is zeroed, le.is_args is explicitly set to 0. Consequently, Pass 1 assumes no escaping is required and returns the raw byte length of the captured string. For example, a capture group containing the ampersand character (&) registers as exactly one byte in the total allocation calculation.

During Pass 2, the function ngx_http_script_copy_capture_code executes using the primary script engine (e), where the e->is_args flag remains set to 1. Recognizing the flag, the copy operation routes the string through ngx_escape_uri. The 1-byte ampersand character (&) expands into the 3-byte sequence %26. This expansion writes data beyond the capacity of the heap buffer allocated during Pass 1, resulting in a heap-based buffer overflow.

Analyzing the vulnerable source code in src/http/ngx_http_script.c highlights the structural flaw in sub-engine initialization. During the length calculation phase, NGINX initializes the sub-engine context using ngx_memzero, which wipes all inherited state from the parent process.

// Vulnerable Pass 1: Length Calculation
void
ngx_http_script_complex_value_code(ngx_http_script_engine_t *e)
{
    size_t                      len;
    ngx_http_script_engine_t    le;
    ngx_http_script_len_code_pt lcode;
 
    // The sub-engine is entirely zeroed, dropping e->is_args
    ngx_memzero(&le, sizeof(ngx_http_script_engine_t));
    
    // ... calculation proceeds without escaping logic ...
}

Conversely, the data copy phase executes using the original engine context. The ngx_http_script_copy_capture_code function checks the e->is_args flag and enforces URI escaping if the flag evaluates to true. This direct discrepancy between the length calculation logic and the memory writing logic creates the arithmetic mismatch.

// Pass 2: Data Copy
void
ngx_http_script_copy_capture_code(ngx_http_script_engine_t *e)
{
    // ... 
    if (e->is_args) {
        // Expansion occurs here, converting characters like '&' to '%26'
        e->pos = (u_char *) ngx_escape_uri(e->pos, p, len, NGX_ESCAPE_ARGS);
    } else {
        e->pos = ngx_cpymem(e->pos, p, len);
    }
    // ...
}

The remediation strategy implemented in patched versions ensures that the is_args flag state accurately propagates from the primary engine to the length calculation sub-engine. By passing the flag configuration into le, Pass 1 correctly calculates the expanded length of the URI arguments, ensuring the subsequent heap allocation accurately matches the requirements of Pass 2.

Exploitation of CVE-2026-42945 requires an attacker to identify an NGINX server operating with a specific, vulnerable configuration sequence. The routing block must contain a rewrite directive that appends a question mark (?) to the replacement URI. This directive must be immediately followed by another configuration directive, such as set, that references an unnamed regex capture group originating from the request URI.

Upon identifying a target, the attacker constructs a malicious HTTP request designed to traverse the vulnerable configuration path. The URI payload must contain characters that require escaping under standard URI rules, such as spaces ( ), ampersands (&), or plus signs (+). The attacker places these characters within the segment of the URI that maps to the unnamed capture group (e.g., $1).

When the NGINX worker processes the request, the rewrite directive sets the internal is_args flag. The subsequent set directive triggers the script engine evaluation. The engine calculates the required memory based on the raw byte length of the attacker's payload. During the copy operation, the engine escapes the special characters, expanding the payload and writing out-of-bounds onto the heap.

The complexity of weaponizing this vulnerability into reliable remote code execution is High. An attacker must perform precise heap grooming to place target structures, such as function pointers or critical NGINX worker structures, immediately adjacent to the dynamically allocated buffer. Modern mitigations like Address Space Layout Randomization (ASLR) further restrict exploitation, generally reducing the outcome to persistent worker process crashes.

The fundamental impact of CVE-2026-42945 is a high-severity disruption of availability through persistent memory corruption. When the out-of-bounds write occurs, the NGINX worker process overwrites adjacent heap chunks. Depending on the size of the overflow and the state of the heap, this corruption typically triggers a SIGSEGV when the memory allocator or the application attempts to process the corrupted metadata.

NGINX operates using a multi-process architecture where a master process oversees multiple worker processes. If a worker process crashes due to a segmentation fault, the master process automatically respawns a replacement worker. While this provides resilience, an attacker can continuously send malicious requests to repeatedly crash the workers. This results in dropped connections, severe performance degradation, and a complete Denial of Service condition for the affected application.

The potential for Remote Code Execution elevates the severity of the vulnerability. If an attacker successfully aligns the heap layout, the out-of-bounds write can overwrite execution control data, such as virtual function pointers associated with HTTP connection processing structures. Hijacking the execution flow grants the attacker code execution within the context of the NGINX worker process, typically a low-privileged user like www-data or nginx.

The CVSS v3.1 vector evaluates to 8.1 (CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H). The Attack Complexity is classified as High (AC:H) due to the requirement for specific configuration sequences and the difficulty of circumventing heap randomization mitigations across different operating environments. Despite the complexity, the absence of authentication requirements (PR:N) poses a significant risk to affected organizations.

The definitive remediation for CVE-2026-42945 is upgrading the NGINX software to the official patched releases provided by the vendor. Organizations utilizing NGINX Open Source must deploy version 1.31.0 (mainline) or 1.30.1 (stable). Customers operating NGINX Plus must upgrade their instances to release R37, R36 P4, or R32 P6, which contain the comprehensive script engine state propagation fixes.

In environments where immediate binary patching is impossible, administrators can implement configuration changes to eliminate the vulnerable code path. The vulnerability specifically targets unnamed capture groups ($1, $2) when evaluated after a rewrite operation containing a query string delimiter. Administrators must replace all unnamed capture variables with named capture groups (?<id>) within the affected location blocks.

The named capture group workaround is structurally sound because NGINX handles named variables using a separate variable evaluation hash map rather than the vulnerable indexed script sub-engine logic. Implementing set $original_id $id; instead of set $original_id $1; bypasses the state inconsistency entirely. Organizations must audit all NGINX configuration files, including included virtual host definitions, for the vulnerable pattern.

Security teams should actively monitor server logs for indicators of exploitation attempts. Frequent HTTP 502 Bad Gateway or 504 Gateway Timeout errors correlating with specific endpoint access patterns strongly suggest worker process crashes caused by heap corruption. Furthermore, organizations can deploy Web Application Firewall (WAF) rules to detect and drop requests containing excessive URI-encoded characters targeting endpoints known to utilize rewrite rules.