Table of Contents
Content Error or Suggest an Edit
Notice a grammatical error or technical inaccuracy? Let us know; we will give you credit!
Introduction
If your server runs nginx with rewrite and set directives in its configuration — and a large number of WordPress setups do — you’re potentially exposed to a critical remote code execution vulnerability that’s been sitting undetected since 2008.
The flaw, dubbed NGINX Rift and tracked as CVE-2026-42945, carries a CVSS score of 9.2. It was discovered by researchers at Depth First using an automated vulnerability analysis system that scanned the nginx source code and identified four memory corruption issues — one of them critical. A working proof-of-concept exploit now exists. Patches are available.
Affected versions: nginx 0.6.27 through 1.30.0.
Fixed in: nginx 1.30.1 (stable) and 1.27.5 (mainline).
What Is Nginx Drift (CVE-2026-42945) and Why Does It Matter?
At its core, this is a heap buffer overflow in nginx’s rewrite module (ngx_http_rewrite_module). The vulnerable code path requires two directives to be present in the nginx configuration:
- A
rewritedirective whose replacement string includes a question mark (which triggers query string handling) - A
setdirective that follows it and references a regex capture group
A minimal example of a vulnerable configuration block:
nginx
location ~ ^/api/(.*)$ {
rewrite ^/api/(.*)$ /internal?migrated=true;
set $original_endpoint $1;
}
This kind of pattern is extremely common. API migration configurations, proxy routing, and URL normalization setups routinely combine rewrite and set this way. Many WordPress nginx configurations, especially those handling custom rewrites for REST API endpoints or plugin-specific routes, fall into this category.
Additional CVEs Disclosed in the Same Report
Three more vulnerabilities were confirmed by nginx as part of the same research:
| CVE | Severity | CVSS | Module | Description |
|---|---|---|---|---|
| CVE-2026-42945 | Critical | 9.2 | ngx_http_rewrite_module | Heap buffer overflow → RCE |
| CVE-2026-42946 | High | 8.3 | ngx_http_scgi_module, ngx_http_uwsgi_module | State mismatch causes ~1TB allocation → worker crash |
| CVE-2026-40701 | Medium | 6.3 | ngx_http_ssl_module | Use-after-free via async OCSP DNS resolution on connection close |
| CVE-2026-42934 | Medium | 6.3 | ngx_http_charset_module | Off-by-one in UTF-8 handling → out-of-bounds read before upstream buffer |
How Exploitable Is This in the Real World?
The researchers built a working proof-of-concept that achieves remote code execution — with ASLR disabled. With ASLR enabled, exploitation is significantly harder. The fact that nginx uses a multi-process architecture (worker processes forking from a single master) actually makes the heap layout deterministic across workers, which is a factor researchers noted as relevant to exploit reliability.
At the time of writing, no active exploitation in the wild has been publicly confirmed. That said, a PoC exists and is publicly available on GitHub. The window between “researcher PoC available” and “active exploitation” tends to be short once a 9.2-scoring vulnerability draws attention.
Am I Running a Vulnerable nginx Version?
You’re in the vulnerable range if you’re running nginx 0.6.27 to 1.30.0 with a configuration block that includes both a rewrite directive with a ? in the replacement and a set directive referencing a capture group ($1, $2, etc.).
To check your nginx version:
nginx -v
To search your nginx config for the relevant directive combination:
grep -rn "rewrite\|set \$" /etc/nginx/
Look for any location block where a rewrite line contains a ? and a set line follows it using $1 or similar.
What You Need to Do Right Now
Patch. The fix is available now. F5/nginx released patched versions on May 13, 2026. The vendor advisory is at K000160932 (F5 login required).
For most setups this comes down to:
# Ubuntu/Debian (if using official nginx repo) apt update && apt install nginx # Verify the installed version after update nginx -v
Target versions: 1.30.1 (stable branch) or 1.27.5 (mainline).
If patching immediately isn’t feasible, the specific trigger requires both directives in combination. Reviewing whether your config actually uses rewrite with a question mark followed by a set $var $N pattern, and temporarily restructuring those blocks, removes the attack surface while you arrange a maintenance window.
What WordPress Site Owners and Admins Should Know
If you manage WordPress through a hosting control panel — RunCloud, Ploi, GridPane, SpinupWP, or similar — your nginx configuration was generated automatically and may well contain the rewrite and set directive combination that triggers this vulnerability. These panels handle a lot of complexity on your behalf: subdirectory installs, multisite routing, PHP handler configuration, and custom rewrite rules. That convenience comes with configs most site owners have never read, let alone audited.
Don’t assume you’re clear. Pull your actual nginx config and check it.
Other common places the vulnerable pattern appears in WordPress environments:
- REST API and WooCommerce endpoint routing
- Reverse proxy setups passing specific paths to Node.js or other backends
- Site migration configurations redirecting old URL structures to new ones
- Any custom
locationblock added manually over time
The standard nginx.org WordPress template uses try_files and doesn’t combine rewrite and set in the triggering way — but that template is a starting point, not what most managed hosting stacks actually deploy.
Provider Responses
GridPane
Servers running Ubuntu 22/24 Patched.
Runcloud
No response.
References
PoC repository — DepthFirstDisclosures/Nginx-Rift
