NGINX runs roughly a third of the websites on the internet. So when a flaw turns up that lets an unauthenticated attacker run code on an NGINX server with a single HTTP request, it’s worth dropping what you’re doing.
That’s exactly what CVE-2026-42945 — nicknamed NGINX Rift — does. It’s a heap buffer overflow in the rewrite module that has been sitting in the codebase for 18 years, and it’s already being exploited in the wild.
What is CVE-2026-42945 (NGINX Rift)?
It’s a heap buffer overflow in ngx_http_rewrite_module — the module that handles URL rewriting, one of the most commonly used features in any NGINX config. The CVSS v4 score is 9.2, which lands it firmly in critical territory.
The bug was found by researchers at depthfirst security, who reported it responsibly on April 21, 2026. NGINX published the public advisory on May 14. Patches shipped the same day.
The part that should make you nervous: the affected version range goes all the way back to NGINX 0.6.27, which dates to around 2008. This code has been quietly exploitable for almost two decades.
How the attack works
The vulnerability only triggers under a specific (but common) rewrite configuration. It needs all of these in the same scope:
- A
rewritedirective that uses an unnamed PCRE capture — the$1,$2style references - A replacement string containing a question mark (
?) - Another
rewrite,if, orsetdirective following it in the same block
If your config matches that pattern, an attacker who can reach your server over HTTP can send one crafted request that overflows the heap in the NGINX worker process. No login. No existing session. No prior foothold.
According to Akamai’s security research team, the overflow happens inside the worker process that handles requests, which is exactly the process you don’t want an attacker controlling.
DoS is easy, RCE is proven
Like a lot of memory-corruption bugs, this one has two tiers.
Denial of service is the easy outcome. Overflow the heap, crash the worker, repeat. Your server stops serving legitimate traffic.
Remote code execution is the dangerous outcome. On systems without ASLR (address space layout randomization), researchers achieved full RCE directly. After the initial disclosure, a proof-of-concept with ASLR bypass techniques was released publicly, which removes the main obstacle on hardened systems too.
That PoC release is why this jumped from “patch soon” to “patch now.” Once working exploit code is public, the gap between disclosure and mass exploitation collapses to days.
Which versions are affected
Vulnerable:
- NGINX Open Source 0.6.27 through 1.30.0
- NGINX Plus R32 through R36
- Derivative products: NGINX App Protect, Gateway Fabric, Ingress Controller, Instance Manager
Patched:
- NGINX Open Source 1.30.1 and 1.31.0
- NGINX Plus R32 P6 and R36 P4
The NGINX Ingress Controller line matters a lot here. If you’re running Kubernetes with NGINX as your ingress, you’re potentially exposing this to the entire internet at your cluster’s front door.
How to fix it
Two real options:
- Upgrade NGINX. Get to Open Source 1.30.1/1.31.0 or NGINX Plus R32 P6/R36 P4. This is the clean fix. Most Linux distributions have backported the patch — check your package manager.
- Rewrite your rewrite rules. If you genuinely can’t patch today, the official mitigation is to replace every unnamed capture with a named capture in your affected rewrite directives. So instead of
$1, use a named group like(?<path>...)and reference$path. This breaks the exact condition the exploit needs.
The second option is fiddly and error-prone across a large config. Treat it as a stopgap, not a destination. Patch as soon as you can.
How to check if you’re exposed
Run nginx -v to get your version. If it’s in the vulnerable range, check your configs for the trigger pattern. Grep your config tree for rewrite directives using unnamed captures:
grep -rn "rewrite" /etc/nginx/ | grep '\$[0-9]'If that returns rewrite rules using $1/$2 style references with question marks in the replacement, and there’s an if/set/rewrite after them in the same block, you have the vulnerable pattern. But don’t rely on “my config looks safe” as your defense — patch the binary regardless. Config audits miss things.
Why “18 years old” keeps happening
This is the third major “ancient flaw, just discovered” story in cybersecurity in a single week, after a 9-year-old Linux kernel bug and a double-free in Apache’s HTTP/2 module. It’s not a coincidence.
The foundational infrastructure software we all depend on — web servers, kernels, crypto libraries — was largely written before modern memory-safety tooling and fuzzing matured. The code is stable, widely deployed, and rarely rewritten. That’s exactly the environment where a subtle memory bug can hide for two decades.
The uncomfortable takeaway: there are almost certainly more of these waiting. The current wave of AI-assisted vulnerability research (both defensive and offensive) is starting to surface them faster than ever.
Frequently asked questions
Is CVE-2026-42945 being actively exploited?
Yes. Active in-the-wild exploitation has been reported, and a proof-of-concept exploit with ASLR bypass is publicly available. This is a patch-immediately situation, not a scheduled-maintenance one.
Does this affect all NGINX servers?
It affects NGINX Open Source 0.6.27 through 1.30.0 and NGINX Plus R32 through R36. The exploit only triggers if your configuration uses a specific rewrite pattern (unnamed PCRE captures with a question mark, followed by another rewrite/if/set directive). However, you should patch regardless of whether you think your config is vulnerable.
What’s the difference between this and the recent Apache HTTP/2 flaw?
They’re different bugs in different software. The Apache flaw (CVE-2026-23918) was a double-free in the HTTP/2 module. NGINX Rift (CVE-2026-42945) is a heap buffer overflow in the rewrite module. Both allow unauthenticated attacks, but they affect entirely separate web servers. If you run both, patch both.
Am I safe if I use named captures in my rewrite rules?
Using named captures instead of unnamed ones ($1, $2) is the official mitigation, so a config built entirely on named captures avoids the trigger condition. But this is a workaround, not a guarantee. Patch the NGINX binary as the real fix.
Does this affect Kubernetes ingress?
Yes. The NGINX Ingress Controller is in the affected product list. If you run Kubernetes with NGINX ingress, this bug may be exposed at your cluster’s internet-facing edge. Update your ingress controller image to a patched version.
How do I know if I’ve already been compromised?
Check for unexpected NGINX worker process crashes or restarts in your logs (a sign of DoS attempts), and audit for unexpected processes or outbound connections from the server (signs of successful RCE). If you have any doubt and you were running a vulnerable version on an internet-facing server, treat the host as potentially compromised and investigate accordingly.
Bottom line
NGINX Rift is the worst kind of web-server bug: unauthenticated, single-request, and already being exploited with public PoC code. The fix is a straightforward version upgrade, and the temporary mitigation (named captures) is available if you’re stuck.
Run nginx -v right now. If you’re below 1.30.1 on Open Source or below the patched Plus releases, this is tonight’s job, not next sprint’s.
Sources
- The Hacker News: 18-Year-Old NGINX Rewrite Module Flaw Enables Unauthenticated RCE
- Akamai Security Research: Mitigating a Critical Heap Buffer Overflow in NGINX (CVE-2026-42945)
- Orca Security: NGINX Rewrite Module Vulnerability CVE-2026-42945
- SOC Prime: CVE-2026-42945 Critical NGINX Rewrite Flaw
- Cloud Security Alliance: NGINX Rift CVE-2026-42945 Research Note
- F5 Official Advisory: NGINX ngx_http_rewrite_module vulnerability CVE-2026-42945
Last updated: May 25, 2026.