The Short Version

  • CVE-2026-42945 (branded NGINX Rift) is a heap buffer overflow in the nginx rewrite module, CVSS 9.2 Critical, dating back approximately 18 years to nginx 0.6.27 (2008).
  • The attack: unauthenticated, single crafted HTTP request. Achieves RCE on hosts with ASLR disabled; reliable DoS on any vulnerable configuration.
  • Affected: NGINX Plus R32 through R36, NGINX Open Source 1.0.0 through 1.30.0, plus the EOL range 0.6.27 through 0.9.7 (no fixes coming for that range).
  • Patches: NGINX Plus R32 P6 and R36 P4; NGINX Open Source 1.30.1 and 1.31.0.
  • Mitigation without patching: replace unnamed PCRE captures ($1, $2) with named captures in any rewrite directive followed by a rewrite, if, or set directive.
  • Three additional lower-severity CVEs in the same release: CVE-2026-42946 (SCGI/uWSGI, CVSS 8.3 High), CVE-2026-40701 (SSL module, CVSS 6.3 Medium), CVE-2026-42934 (charset module, CVSS 4.8 Medium).

F5 published advisories on May 13, 2026 for four nginx vulnerabilities, the most serious of which is CVE-2026-42945, a heap buffer overflow in the nginx rewrite module with a CVSS v4 score of 9.2 (Critical). The flaw, branded by its discoverers at depthfirst as NGINX Rift, dates back to nginx versions as early as 0.6.27 released in 2008, making it approximately eighteen years old. It allows an unauthenticated attacker to corrupt the nginx worker process heap with a single crafted HTTP request, achieving remote code execution on hosts with ASLR disabled and denial of service through crash loops on any vulnerable configuration. depthfirst reported the flaw to F5 on April 21, 2026 and it was patched on May 13.

The other three CVEs in the same release are CVE-2026-42946 (excessive memory allocation in SCGI and uWSGI modules, CVSS v4 8.3 High), CVE-2026-40701 (use-after-free in the SSL module triggered by specific ssl_verify_client and ssl_ocsp configurations, CVSS v4 6.3 Medium), and CVE-2026-42934 (out-of-bounds read in the charset module, CVSS v3.1 4.8 Medium). The CVE-2026-42945 flaw in the rewrite module is the headline; the other three are lower-severity and require more specific configurations to trigger.

Apache 2.4.67 Patches 11 CVEs. One Is RCE. One Hits Shared Hosting.

What Triggers CVE-2026-42945

The vulnerability is in ngx_http_rewrite_module, one of the most widely used nginx modules in production hosting configurations. The conditions that trigger the heap overflow are specific:

  • A rewrite directive is followed by another rewrite, if, or set directive
  • The rewrite uses unnamed Perl-Compatible Regular Expression (PCRE) capture groups (referenced as $1, $2, and so on)
  • The replacement string includes a question mark (?)

An attacker who can reach a vulnerable nginx server over HTTP can send a request crafted to trigger this code path and overflow the worker process heap. depthfirst’s published technical description, summarized by the researchers as “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,” is direct: this is a one-request RCE on hosts with insufficient memory protections, and a reliable DoS in the broader case.

What Is Affected

The affected version coverage is broad:

  • NGINX Plus releases R32 through R36
  • NGINX Open Source versions 1.0.0 through 1.30.0
  • NGINX Open Source versions 0.6.27 through 0.9.7 (no fixes planned for this end-of-life range)
  • Multiple derivative products including NGINX Instance Manager, NGINX WAF, NGINX Gateway Fabric, and NGINX Ingress Controller

Hosting providers running nginx as a reverse proxy, load balancer, or web server frontend should treat the entire production fleet as potentially affected and verify versions against the affected range. The end-of-life version range (0.6.27 through 0.9.7) is particularly concerning because no upstream patches are coming for those builds.

DirtyFrag: Any User Account Can Become Root on Most Linux Servers. The Exploit Is Public. There Is No Patch.

The Patches

F5 has released patches in the following versions:

  • NGINX Plus R32 P6
  • NGINX Plus R36 P4
  • NGINX Open Source 1.30.1
  • NGINX Open Source 1.31.0

The relevant F5 advisories are K000161019, K000161027, K000161021, and K000161028. The standard nginx update path through distribution package managers and official nginx repositories will distribute the patched builds. Operators running nginx from source compilation should rebuild against the patched release tarballs.

Mitigation Without Patching

For operators who cannot immediately deploy patched builds, a specific configuration-level mitigation closes the attack path: replace unnamed regex captures (such as $1, $2) with named captures in any rewrite directive that is followed by a rewrite, if, or set directive. Named captures use the syntax (?<name>...) in the PCRE pattern and are referenced as $name in the replacement string.

This is a working mitigation rather than a workaround. The conditions that trigger the overflow specifically require unnamed captures, and rewriting affected directives to use named captures takes the configuration out of the vulnerable code path entirely. For hosting operators with large nginx configuration footprints across many customer accounts, the patch deployment is likely faster than the configuration audit. For operators in version-pinned environments where upgrades require longer change windows, the configuration mitigation is the path that does not require waiting on a maintenance window.

Copy Fail: Any Local User Can Get Root on Nearly Every Linux System Since 2017

The Eighteen-Year Question

The flaw dates back to nginx 0.6.27, released in 2008. That release predates the founding of Nginx Inc., the company’s acquisition by F5 in 2019, and the bulk of the production deployments that now depend on nginx as critical infrastructure. The rewrite module itself has been a core nginx component for essentially the entire lifetime of the project.

That an eighteen-year-old heap overflow in one of the most widely used modules of one of the most widely deployed web servers in existence was found in April 2026, and not earlier, is the question worth pausing on. The depthfirst team’s disclosure does not directly attribute its discovery to AI-assisted vulnerability research, but the pattern across hosting infrastructure software in April and May 2026 is consistent. cPanel staff said publicly this week that “every system is getting reviewed because the bots are faster than people.” The DirtyFrag kernel vulnerability disclosed on May 7 affected paths in the Linux kernel that had existed since 2017. The May 13 cPanel CVEs included CVE-2026-32993, a CRLF injection in the same vulnerability class as April’s CVE-2026-41940. Today’s nginx disclosure extends the pattern back to 2008.

For hosting providers, the practical implication is straightforward: the assumption that long-deployed, widely audited infrastructure software is free of latent critical vulnerabilities is no longer a working operational assumption. The current vulnerability discovery rate suggests that more eighteen-year-old bugs in foundational hosting components will surface in the coming months, and patch cadence has to accommodate that pace.

Get one-on-one advice on maximizing your hosting company’s valuation and navigating the sale process.

Book a consultation

What Hosting Providers Should Do Today

The immediate operational actions are:

  • Identify all nginx instances across the production fleet and confirm versions against the affected range (NGINX Plus R32-R36, NGINX Open Source 1.0.0-1.30.0).
  • Update to the patched versions (NGINX Plus R32 P6, R36 P4, or NGINX Open Source 1.30.1, 1.31.0) through the standard package channels.
  • For instances where immediate update is not possible, audit nginx configurations for rewrite directives using unnamed PCRE captures followed by rewrite, if, or set directives, and modify those to use named captures.
  • Confirm that ASLR is enabled on hosts running nginx, which raises the bar from straightforward RCE to a more complex exploitation path. ASLR alone does not eliminate the risk, but it is a meaningful defense-in-depth control.
  • For end-of-life nginx deployments in the 0.6.27 through 0.9.7 range, upgrade to a supported release. No upstream patches are coming for those builds.

No active exploitation has been reported at the time of writing. That window is typically short for an unauthenticated RCE in a widely deployed web server, and historical disclosure patterns for nginx-class vulnerabilities suggest public proof-of-concept code will surface within days of the patch release. The mitigation effort is a today task, not a this-week task.

cPanel Patched Five More CVEs. One Fix Is Already Reported Incomplete.