CVE-2026-42945 · Heap-based Buffer Overflow · CVSS v4.0 9.2 (Critical) found autonomously by depthfirst

NGINX Rift

An 18 year old memory corruption flaw in NGINX Plus and NGINX Open Source lets an unauthenticated attacker crash worker processes or execute remote code with crafted HTTP requests.

Read the technical writeup Try depthfirst on your codebase

TL;DR

A bug in the ngx_http_rewrite_module lets a remote, unauthenticated attacker corrupt the heap of an NGINX worker process by sending crafted URI. The trigger is a common configuration pattern: a rewrite directive with an unnamed regex capture ($1, $2) and a replacement string that contains a question mark, followed by another rewrite, if, or set directive.

When that pattern is present, NGINX computes the destination buffer using one set of escaping assumptions and then writes to it using another. The write runs past the allocated buffer, producing deterministic memory corruption.

Any NGINX deployment running an affected version with that pattern is exposed until it is patched or reconfigured.

Why it matters:

The bug is reachable from the public internet without authentication.
Crafted HTTP requests triggers a deterministic heap overflow.
The outcome is remote code execution in the NGINX worker process.

Security impact

NGINX sits in front of a large share of the public internet.

An attacker who can reach a vulnerable NGINX server over HTTP can send a single request that overflows the heap in the worker process and achieves remote code execution. There is no authentication step, no prior access requirement, and no need for an existing session. The bytes written past the allocation are derived from the attacker’s URI, so the corruption is shaped by the attacker rather than random. Repeated requests can also be used to keep workers in a crash loop and degrade availability for every site served by the instance.

There is no control plane exposure. This is a data plane issue in the request-handling path.

What is affected

The vulnerability lives in ngx_http_rewrite_module, which is part of every standard NGINX build.

NGINX Open Source versions 0.6.27 through 1.30.0.
NGINX Plus R32 through R36.
NGINX Instance Manager 2.16.0 through 2.21.1.
F5 WAF for NGINX 5.9.0 through 5.12.1.
NGINX App Protect WAF 4.9.0 through 4.16.0 and 5.1.0 through 5.8.0.
F5 DoS for NGINX 4.8.0.
NGINX App Protect DoS 4.3.0 through 4.7.0.
NGINX Gateway Fabric 1.3.0 through 1.6.2 and 2.0.0 through 2.5.1.
NGINX Ingress Controller 3.5.0 through 3.7.2, 4.0.0 through 4.0.1, and 5.0.0 through 5.4.1.

F5 Distributed Cloud, F5 Silverline, NGINX One Console, BIG-IP, BIG-IQ, F5OS, Traffix SDC, and F5 AI Gateway are not affected. The full evaluation is in the F5 advisory.

Remediation

Recommended action: upgrade.

If you run an affected version, install one of the fixed releases listed below. Restart NGINX after the upgrade so workers reload with the patched binary.

Product	Fixed in
NGINX Open Source	1.31.0
NGINX Open Source	1.30.1
NGINX Plus R36	R36 P4
NGINX Plus R32	R32 P6

For NGINX Instance Manager, F5 WAF for NGINX, NGINX App Protect WAF and DoS, NGINX Gateway Fabric, and NGINX Ingress Controller, F5 has not yet released a fix in the same branch. F5 recommends moving to a release that contains the fix.

If you cannot upgrade immediately: change your rewrite configuration.

The bug is reachable only when an unnamed PCRE capture is paired with a replacement string that contains a question mark, followed by a rewrite, if, or set directive in the same scope. Replace unnamed captures ($1, $2) with named captures in every affected rewrite directive.

Vulnerable pattern:

rewrite ^/users/([0-9]+)/profile/(.*)$ /profile.php?id=$1&tab=$2 last;

Mitigated pattern:

rewrite ^/users/(?<user_id>[0-9]+)/profile/(?<section>.*)$ /profile.php?id=$user_id&tab=$section last;

Technical details

The bug lives in src/http/ngx_http_script.c. When a rewrite replacement contains a question mark, ngx_http_script_start_args_code sets e->is_args = 1 on the main script engine and never clears it. A later call to ngx_http_script_complex_value_code recomputes the destination length using a freshly zeroed sub-engine, so ngx_http_script_copy_capture_len_code measures the capture as raw bytes. The actual copy then runs on the main engine, which still has is_args = 1, so ngx_http_script_copy_capture_code re-escapes the capture through ngx_escape_uri in NGX_ESCAPE_ARGS mode. Each +, %, or & byte in the capture expands by two bytes. The destination buffer was sized for the raw length. The write runs past the allocation.

The full root cause analysis, the AddressSanitizer trace, the proof of concept, and the patch are in our technical writeup:

Read the full technical analysis

Credits

This vulnerability was discovered autonomously by the depthfirst platform.

F5 confirmed, patched, and published a coordinated advisory on May 13, 2026. We thank the F5 Product Development and NGINX teams for their responsiveness throughout the disclosure process.

F5 Security Advisory: K000161019
CVE: CVE-2026-42945

Finding vulnerabilities in low level code (C, C++, and beyond) is uniquely hard and remains a major, under defended attack surface. In this live session, Kal and Leo will walk through how depthfirst’s automated detection techniques surface real, remotely exploitable issues in low level code at scale, and will share a technical breakdown of NGINX rift.

Frequently asked questions

How do I know if I am affected?

Check your installed NGINX version against the list above, and grep your NGINX configuration for rewrite directives that combine an unnamed capture group with a question mark in the replacement. If both are present, you are affected.
Is exploitation in the wild?

depthfirst is not aware of in-the-wild exploitation at the time of disclosure. F5 coordinated the advisory with the patch release.
Are reverse proxies, load balancers, and ingress controllers built on NGINX affected?

Many of them are. The F5 advisory lists NGINX Gateway Fabric, NGINX Ingress Controller, NGINX App Protect WAF, NGINX App Protect DoS, F5 WAF for NGINX, F5 DoS for NGINX, and NGINX Instance Manager as affected. Third-party products that embed NGINX may also be affected. Check with your vendor.
Where can I find the technical writeup?

Our full root cause analysis, proof of concept, and patch walkthrough are in the technical blog post.