News

Security researchers have revealed several vulnerabilities affecting both NGINX Plus and NGINX Open Source, including a critical memory corruption bug in the rewrite module that persisted unnoticed for roughly 18 years.

The most severe problem, tracked as CVE-2026-42945 and dubbed “NGINX Rift” by the finder depthfirst, is a heap buffer overflow in ngx_http_rewrite_module. The issue carries a CVSS v4 score of 9.2 and can be abused by a remote attacker to execute arbitrary code or to trigger a denial-of-service by crafting specific HTTP requests.

According to an advisory from F5, the flaw is provoked when a rewrite directive is followed by another rewrite, an if, or a set directive, and the replacement string contains an unnamed PCRE capture (for example $1, $2) plus a question mark (?) in the replacement. Under those conditions the module can write past allocated heap memory.

F5 warned that exploitation requires no authentication: an attacker who can reach the vulnerable server over HTTP may send a maliciously formed request that overflows the heap in an NGINX worker process, potentially causing it to crash and restart. On systems where Address Space Layout Randomization (ASLR) is disabled, the same flaw can be leveraged for remote code execution. The vendors were informed under responsible disclosure on April 21, 2026, and fixes are available in updated releases.

The following product versions were identified as affected and have fixes introduced in later releases:

• NGINX Plus R32 – R36 (Fixes introduced in R32 P6 and R36 P4)
• NGINX Open Source 1.0.0 – 1.30.0 (Fixes introduced in 1.30.1 and 1.31.0)
• NGINX Open Source 0.6.27 – 0.9.7 (No fixes planned)
• NGINX Instance Manager 2.16.0 – 2.21.1
• F5 WAF for NGINX 5.9.0 – 5.12.1
• NGINX App Protect WAF 4.9.0 – 4.16.0
• NGINX App Protect WAF 5.1.0 – 5.8.0
• F5 DoS for NGINX 4.8.0
• NGINX App Protect DoS 4.3.0 – 4.7.0
• NGINX Gateway Fabric 1.3.0 – 1.6.2
• NGINX Gateway Fabric 2.0.0 – 2.5.1
• NGINX Ingress Controller 3.5.0 – 3.7.2
• NGINX Ingress Controller 4.0.0 – 4.0.1
• NGINX Ingress Controller 5.0.0 – 5.4.1

In its own write-up, depthfirst emphasized the severity: an unauthenticated remote attacker can send a single specially formed URI to corrupt the heap of a worker process. The overflow is reliably triggerable without any prior access, session, or credentials. Because the excess bytes written beyond the allocation are derived from the attacker-controlled URI, the corruption is deterministic and can be shaped by the attacker rather than occurring randomly. Repeated exploit attempts can keep workers crashing and restarting, creating a persistent availability impact for all sites served by the instance.

Alongside CVE-2026-42945, NGINX Plus and Open Source received patches for three additional vulnerabilities:

CVE-2026-42946 (CVSS v4 score: 8.3) – An excessive memory allocation bug affecting ngx_http_scgi_module and ngx_http_uwsgi_module. A remote, unauthenticated attacker with the ability to manipulate upstream responses (adversary-in-the-middle) could force large allocations when scgi_pass or uwsgi_pass is used, potentially allowing reading of worker memory or causing a worker restart.

CVE-2026-40701 (CVSS v4 score: 6.3) – A use-after-free in ngx_http_ssl_module that can be triggered when ssl_verify_client is set to “on” or “optional” together with ssl_ocsp enabled. An unauthenticated remote attacker may be able to influence limited data modification or restart the NGINX worker process.

CVE-2026-42934 (CVSS v4 score: 6.3) – An out-of-bounds read in ngx_http_charset_module that can disclose memory contents or restart a worker. This can be induced when charset, source_charset and charset_map are configured and proxy_pass is used with buffering disabled (“off”).

Administrators are urged to upgrade to the patched releases as soon as possible. If an immediate software update for CVE-2026-42945 is not feasible, a recommended workaround is to update rewrite rules: replace unnamed PCRE captures ($1, $2, etc.) with named captures in every affected rewrite directive to avoid the problematic code path.