NGINX Rift: CVE-2026-42945 Critical Heap Buffer Overflow Vulnerability Explained

On May 13, 2026, security researchers disclosed a critical remote code execution vulnerability in NGINX that had been silently lurking in the codebase for 18 years. Named NGINX Rift and tracked as CVE-2026-42945, the vulnerability carries a CVSS score of 9.2 (Critical) and affects the most widely deployed web server on the internet. Given that NGINX powers roughly a third of all websites globally and sits at the critical edge of countless backend systems, the disclosure of an unauthenticated remote code execution vulnerability carries serious implications for organizations worldwide.

In this blog, we explain how the NGINX-Rift CVE-2026-42945 vulnerability works and provide practical steps for validation and remediation.

Simulate Vulnerability Exploitation Attacks with 14-Day Free Trial of Picus Platform

NGINX-Rift CVE-2026-42945 Vulnerability Explained

What is NGINX?

NGINX is an open source web server, reverse proxy, load balancer, and HTTP cache that has become a foundational component of modern internet infrastructure. NGINX powers nearly a third of all websites globally. It is deployed by hyperscale cloud providers, content delivery networks, e-commerce platforms, banks, government agencies, and countless small businesses.

This widespread deployment is precisely what makes a vulnerability in NGINX so significant. A single flaw in this layer of the stack can expose countless backend systems that sit safely behind it. Because NGINX is typically the first piece of software to process an incoming HTTP request, attackers do not need to bypass additional defenses to reach it. The web server itself becomes the entry point.

NGINX-Rift CVE-2026-42945 Vulnerability

On May 13, 2026, security researchers disclosed CVE-2026-42945, a vulnerability in NGINX's URL rewriting functionality [1]. The flaw affects the ngx_http_rewrite_module, which is widely used to rewrite URLs and preserve original request paths. Because rewrite and set directives are commonly used together in real-world deployments, the vulnerability has broad relevance across enterprise environments.

At a high level, the vulnerability stems from the way NGINX internally processes certain rewrite rules. Under specific conditions, the server incorrectly handles memory when processing manipulated URLs. An unauthenticated remote attacker can exploit this behavior by sending specially crafted HTTP requests, potentially triggering a heap buffer overflow.

The vulnerability was discovered in April 2026 alongside three additional flaws.

• CVE-2026-42946 (CVSS 8.3): A denial of service vulnerability affecting the SCGI and uWSGI modules that can trigger excessive memory allocation and crash NGINX worker processes.
• CVE-2026-40701 (CVSS 6.3): A use-after-free vulnerability in the SSL module that may cause NGINX to access released memory during specific TLS and OCSP processing scenarios.
• CVE-2026-42934 (CVSS 6.3): An out-of-bounds read vulnerability in the charset module that can cause unintended memory access while handling incomplete UTF-8 sequences.

The impact extends beyond the open source NGINX project itself. Affected products include several versions of NGINX Plus, NGINX Instance Manager, F5 WAF for NGINX, NGINX App Protect WAF, NGINX App Protect DoS, NGINX Gateway Fabric, and the NGINX Ingress Controller. Organizations using these products should review the affected version ranges published by F5 and apply the latest security updates as soon as possible.

As a temporary mitigation, administrators can review NGINX configurations that use rewrite rules containing question marks alongside set directives referencing captured values. Security teams should also monitor for unusual HTTP requests, heavily encoded payloads, or abnormal URL patterns, as these may indicate active exploitation attempts.

How NGINX-Rift CVE-2026-42945 Exploit Works?

The exploit chain for CVE-2026-42945 is a textbook example of how a single state mismatch can be transformed into reliable remote code execution. The attack proceeds through several distinct stages, with each phase building on the last.

Step 1: Triggering the Overflow

The attacker sends an HTTP request whose URI matches a vulnerable location block. A typical vulnerable configuration looks like the following snippet.

The question mark in the rewrite replacement string causes ngx_http_script_start_args_code to permanently set e→is_args = 1. When the subsequent set directive evaluates the capture group, the two-pass length calculation and copy process diverge.

The length calculation pass uses a fresh sub engine where is_args is zero, so it returns the raw unescaped capture length. The copy pass uses the main engine, where is_args is still one, causing it to call ngx_escape_uri with the NGX_ESCAPE_ARGS flag. This expands every escapable character, such as a plus sign or ampersand, from one byte to three bytes.

The attacker can then pad the matched portion of the URI with large numbers of plus signs, causing data to be written beyond the allocated buffer. Each escaped character produces additional overflow bytes into adjacent heap memory, ultimately leading to a heap buffer overflow condition.

Step 2: Selecting the Corruption Target

The attacker chooses to overwrite the cleanup field of an adjacent ngx_pool_t structure. This field, located at offset 64 of the pool structure, points to a linked list of ngx_pool_cleanup_t entries, each containing a function pointer (handler) and a data argument (data).

When the pool is destroyed, NGINX walks this cleanup list and invokes each handler with its associated data. By replacing the cleanup pointer with an attacker-controlled value, the attacker gains control over which function gets executed and what argument is passed to it.

Step 3: Solving the Contiguous Overflow Problem

Because the overflow is sequential, reaching the cleanup pointer requires overwriting all preceding pool metadata fields, including d, max, current, chain, and large. Any allocation or read operation that touches these corrupted fields afterward will dereference invalid data and crash the worker process before the exploit can complete.

To bypass this problem, the attacker uses a cross-request heap feng shui technique. First, an initial connection is opened, and partial headers are sent, causing NGINX to allocate a request pool. Next, a second victim connection is opened, allocating a victim pool adjacent to the first one.

The attacker then completes the initial request headers to trigger the rewrite overflow, which corrupts the victim pool header. Finally, the attacker immediately closes the victim connection, forcing ngx_destroy_pool to execute before any other code accesses the corrupted metadata fields.

Step 4: Injecting the Fake Cleanup Structure

The exploit requires the cleanup pointer to reference a forged ngx_pool_cleanup_s object containing the address of a useful function, such as system from libc, along with a shell command as its data argument.

Because URI parsing and escaping remove characters such as null bytes, the attacker cannot place this fake structure directly inside the overflow payload. Instead, the attacker performs a heap spray using HTTP POST request bodies, which NGINX processes as raw byte streams and which can contain arbitrary byte values, including null bytes.

The spray payload is carefully crafted to place a fake cleanup structure at a predictable memory location, pointing to the system function followed by the attacker-controlled shell command.

Step 5: Overwriting the Cleanup Pointer with a URI Safe Address

Because NGINX uses a fork-based multi-process architecture, every worker process inherits an identical memory layout from the master process. This makes heap addresses deterministic across workers, meaning a crashed worker is typically replaced by a new process with the same memory layout.

The attacker can then brute force the sprayed heap address until finding one composed entirely of URI-safe bytes, ensuring the address survives the URI escaping process intact. The overflow only needs to overwrite the lower bytes of the cleanup pointer to redirect execution toward the sprayed fake structure.

Step 6: Triggering Execution

Closing the victim socket causes ngx_destroy_pool to walk the now redirected cleanup linked list. The loop reads the corrupted cleanup pointer, follows it to the attacker's sprayed fake structure, and calls system(command) with the attacker-controlled shell command.

At this point, the attacker achieves unauthenticated remote code execution inside the NGINX worker process.

How Picus Helps Simulate NGINX-Rift CVE-2026-42945 Attacks?

We also strongly suggest simulating the NGINX-Rift CVE-2026-42945 vulnerability to test the effectiveness of your security controls against sophisticated cyber attacks using the Picus Security Validation Platform. You can also test your defenses against other vulnerability exploitation attacks, such as regreSSHion, Citrix Bleed, and Follina, within minutes with a 14-day free trial of the Picus Platform.

Picus Threat Library includes the following threats for NGINX-Rift CVE-2026-42945 exploitation attacks:

Picus also provides actionable mitigation content. Picus Mitigation Library includes prevention signatures to address NGINX-Rift CVE-2026-42945 vulnerability exploitation attacks in preventive security controls. Currently, Picus Labs has validated the following signatures for NGINX-Rift CVE-2026-42945 vulnerability:

Start simulating emerging threats today and get actionable mitigation insights with a  14-day free trial  of the Picus Security Validation Platform.

References

[1] Z. Lin, "NGINX Rift: Achieving NGINX Remote Code Execution via an 18-Year-Old Vulnerability," May 13, 2026. Available: https://depthfirst.com/research/nginx-rift-achieving-nginx-rce-via-an-18-year-old-vulnerability