NGINX Heap Overflow Flaw Could Let Unauthenticated Attackers Execute Arbitrary Code

A high-severity heap buffer overflow vulnerability has been identified in the NGINX Stream module’s script engine. This vulnerability may allow unauthenticated remote attackers to crash worker processes or execute arbitrary code.

The issue CVE-2026-42533 affects configurations that combine the `ssl_preread` feature with regex-driven variables and complex values in stream blocks.

NGINX Heap Overflow Flaw

The flaw was found in the zplinn/nginx repository, specifically in the file `src/stream/ngx_stream_script.c`, around line 940, in the function `ngx_stream_script_copy_capture_code()`.

It arises from inconsistent handling of regular expression captures during NGINX’s two-stage complex value evaluation process. First, NGINX calculates the size required for a value and then performs a second pass to copy the evaluated data into the allocated buffer.

If a regex-backed variable modifies the global capture state between these two passes, the copy operation can use a larger capture than what was anticipated during the length calculation phase.

This vulnerable condition is particularly relevant for deployments using the Stream module to proxy TCP or UDP services and inspect TLS handshakes before TLS termination.

With `ssl_preread` enabled, NGINX parses selected ClientHello metadata, including the Server Name Indication (SNI), and exposes it through variables such as `$ssl_preread_server_name`.

Administrators may use these values in map directives, routing logic, or return statements. A regex evaluation involving an unnamed capture, like `$1`, can alter capture data after the destination buffer size has already been calculated.

An attacker could exploit this vulnerability by sending a specially crafted TLS ClientHello that contains an oversized SNI value to an exposed stream listener. In the reported proof-of-concept configuration, a regex map evaluates the SNI value.

At the same time, the return directive expands both `$1` and a regex-backed variable. During the initial pass, a small allocation is computed, as reported by Depth First Disclosure.

However, the later evaluation updates the capture data to reflect a larger, attacker-controlled SNI string. NGINX then copies this data into an undersized buffer, leading to an out-of-bounds heap write.

AddressSanitizer output from the proof of concept confirms a heap buffer overflow during a 1,000-byte `memcpy` operation in `ngx_stream_script_copy_capture_code()`.

The affected memory region was only 256 bytes, demonstrating a significant write beyond the allocated heap boundary. Although the supplied test primarily shows a worker process crash, heap corruption in a network-facing process could potentially lead to arbitrary code execution, depending on allocator behavior, build protections, and the surrounding process memory layout.

This vulnerability is particularly concerning because it occurs before authentication, during TLS preread processing. Internet-facing NGINX instances configured with regex-based map directives, unnamed captures, complex stream values, and `ssl_preread` should be prioritized for review.

This issue is separate from the recently documented fault in the HTTP rewrite module. However, both examples highlight how inconsistent state between the length calculation and copy processes in NGINX’s script engine can lead to dangerous heap corruption conditions.

Organizations should audit their stream configurations for `ssl_preread`, regex maps, unnamed captures (like `$1`), and directives that combine capture expansion with dynamically evaluated variables.

Until an upstream fix is confirmed and deployed, defenders should remove unnamed captures from affected complex values, simplify regex-dependent stream logic, restrict exposure of TLS preread listeners, and run NGINX workers with current platform hardening measures, such as Address Space Layout Randomization (ASLR) and least-privilege service accounts.

ALERT: 20+ government sites delivered malware to businesses and citizens. See full attack research to check your own exposure.