Skip to content
Data Breach

Nginx Buffer Overflow Vulnerability Allows Attackers to Execute Arbitrary Code – PoC Released

A high-severity heap buffer overflow in NGINX Plus and NGINX Open Source can let unauthenticated attackers crash worker processes and, under certain conditions, run arbitrary code. Tracked as CVE-2026-42533, the flaw affects configurations that use regex-based map directives or non-cacheable variabl...

· Jul 28, 2026 · 4 min read · 👁 0 views
Nginx Buffer Overflow Vulnerability Allows Attackers to Execute Arbitrary Code – PoC Released

A high-severity heap buffer overflow in NGINX Plus and NGINX Open Source can let unauthenticated attackers crash worker processes and, under certain conditions, run arbitrary code.

Tracked as CVE-2026-42533, the flaw affects configurations that use regex-based map directives or non-cacheable variables in string expressions, and it is especially dangerous when the Stream module’s ssl_preread feature processes crafted TLS traffic before authentication.

According to the analysis shared by Zhenpeng (Leo), the vulnerability appears when a map directive uses regex matching and a string expression references the map’s regex capture variables before the map output variable.

Nginx Buffer Overflow Vulnerability

The same condition can arise when a non-cacheable variable is used in a string expression under specific setups. An attacker who can send crafted HTTP or TLS requests may trigger a heap buffer overflow in the NGINX worker process, forcing a restart.

On systems where Address Space Layout Randomization (ASLR) is disabled, or where the attacker can bypass ASLR, the overflow can escalate to remote code execution.

The root cause sits in NGINX’s internal script engine, which evaluates “complex values” in two passes. The first pass calculates the total length of the result; the second copies data into a heap buffer of that size.

When a regex-based variable such as one produced by a map is evaluated between those passes, it can update the global capture state. The second pass then copies more data than was allocated, writing past the end of the buffer.

In the Stream module, ssl_preread extracts TLS handshake fields such as the Server Name Indication (SNI) into variables that are often used in complex values. Because this happens before TLS termination, the attack surface is exposed to unauthenticated clients.

In a typical exploit path, an attacker sends a TLS ClientHello with a carefully crafted SNI to a stream listener that has ssl_preread enabled and a configuration that evaluates regex captures inside a complex value.

The length calculation underestimates the final size; after the capture state changes, the copy step overflows the heap. Security researchers have noted that the bug can yield both information-leak and out-of-bounds write primitives, which together support ASLR bypass and reliable exploitation on vulnerable builds.

F5 published the security advisory on July 15, 2026. Researcher Zhenpeng (Leo) Lin and the team at Depth First Labs reported finding the issue with their internal systems, alongside a separate flaw in NGINX’s HTTP/3 QPACK handling (CVE-2026-42530).

Multiple groups appear to have discovered CVE-2026-42533 around the same time, underscoring how widely the affected code paths are used.

Organizations running NGINX Plus or Open Source with stream blocks, ssl_preread, or regex-based maps should treat this as a priority patch.

Until updates are applied, reducing exposure of stream listeners to untrusted networks, avoiding regex capture references in complex values before map outputs, and ensuring ASLR remains enabled can lower risk.

Administrators should monitor official F5 and NGINX channels for fixed releases and apply them promptly, then validate that worker processes no longer crash under malformed ClientHello or HTTP traffic.

CVE-2026-42533 highlights how subtle ordering bugs in script engines can become remote threats when they sit on the path of unauthenticated protocol parsing. For defenders, the takeaway is clear: inventory NGINX stream and map configurations, patch quickly, and keep memory protections such as ASLR firmly in place.

Source: CybersecurityNews.com

Follow ShomoySoft for more: Follow on Facebook

💬 Comments (0)

Login to join the discussion.

No comments yet. Be the first!

Recommended for you