On 13 May 2026 F5 released patches for CVE-2026-42945, a flaw in NGINX’s rewrite module that researchers have named NGINX Rift. What stands out is not only the severity (CVSS 4.0 of 9.2, critical) but how long it sat there. The vulnerable code was introduced in version 0.6.27 back in 2008 and went eighteen years without anyone catching it.
What it actually is
It’s a heap buffer overflow (CWE-122) inside ngx_http_rewrite_module, the component that handles the rewrite, if and set directives in NGINX configuration. The NGINX script engine runs in two passes: first it computes the length of the resulting string, then it copies it. The trouble is that an internal state flag (is_args), set during the length-calculation pass, leaks into the copy pass. When a rewrite rule combines an unnamed PCRE capture with a question mark in the replacement string, ngx_escape_uri ends up writing past the allocated buffer.
The result is a deterministic 4,000-byte heap overflow. Proof-of-concept exploits trigger it with a payload of 349 padding bytes followed by 2,000 characters that NGINX tries to escape in the URI.
Who it affects
Almost anyone running NGINX with rewrite rules that match that pattern. The vulnerability reaches NGINX Open Source from 0.6.27 through 1.30.0 and NGINX Plus from R32 to R36. It also bleeds into deployments that rely on NGINX underneath, such as Ingress NGINX on Kubernetes or OpenResty builds.
An unauthenticated remote attacker can force NGINX worker processes to restart repeatedly by sending crafted HTTP requests, which is already a denial of service. On systems with ASLR disabled, or where the attacker can defeat ASLR, the overflow opens the door to remote code execution.
This isn’t theoretical. VulnCheck observed active exploitation in the wild from 16 May 2026, just days after the patch shipped.
Severity
Critical. We’re talking about a web server that usually sits directly on the internet, an exploitation path that needs no credentials, and public proof-of-concept code. The mix of age, reach and exposure puts it among the most serious advisories of the month.
Mitigation and patches
First thing, update. The NGINX project fixed the flaw in 1.30.1 (stable) and 1.31.0 (mainline). If you use your distribution’s packages, wait for the version that ships the fix rather than compiling by hand.
For Red Hat Enterprise Linux 9, advisory RHSA-2026:18029 (critical severity) delivers the corrected package nginx-1.20.1-24.el9_7.3, backporting the fix onto the 1.20.1 branch that Red Hat maintains. It covers RHEL 9 across all architectures (x86_64, aarch64, ppc64le, s390x) and the extended support variants.
If you can’t patch right away, review your config and temporarily remove rewrite directives that use unnamed PCRE captures together with a question mark in the replacement. That shrinks the attack surface, though it’s no substitute for updating. After patching, restart NGINX so the new binaries load.
If you run RHEL in production you may want to read up on what’s new in Red Hat Enterprise Linux 10.2 to plan future migrations.
Source
- Red Hat Security Advisory: RHSA-2026:18029
- NVD: CVE-2026-42945