CVE-2026-42945: NGINX Rewrite Heap Overflow Enables Remote DoS & Potential RCE

CVE-2026-42945 is a heap-based buffer overflow in NGINX that occurs in ngx_http_rewrite_module (the rewrite module). The bug is remotely reachable over HTTP and can be triggered without authentication when specific rewrite-rule patterns are present, which makes it relevant for internet-facing NGINX reverse proxies. Many outcomes will look like worker crashes and restarts Denial of Service(DoS), but multiple reports note potential Remote Code Execution (RCE) in certain environments, especially when ASLR is disabled.

This post breaks down what’s affected, what makes exploitation possible, and what defenders should do now.

What Is CVE-2026-42945 (NGINX Rift)?

CVE-2026-42945 (CVSSv3 8.1) is a heap memory corruption issue in NGINX’s rewrite module that can lead to a heap-based buffer overflow during rewrite processing. Because rewrite logic sits in the request handling path, a remote attacker can trigger the vulnerable behavior using crafted HTTP requests, as long as the target’s configuration matches the known trigger conditions.

The issue also appears to be old. Its introduction is around 2008, meaning it may have persisted for roughly 18 years across a wide range of NGINX releases.

Which NGINX Versions Are Affected?

NGINX Open Source is reported vulnerable across a broad range:

• Vulnerable:0.6.27 through 1.30.0
• Not vulnerable (fixed):1.30.1+ and 1.31.0+

If you run a distribution-packaged NGINX, do not assume you are safe based on the package name alone. Confirm the actual NGINX version and whether your build includes and uses rewrite rules that match the trigger pattern.

What Configuration Pattern Makes This Bug Reachable?

This vulnerability is not “every NGINX install is instantly exploitable.” It is configuration-dependent, and the recurring trigger description centers on specific rewrite usage.

Reports highlight a pattern involving:

• A rewrite directive using unnamed PCRE captures like $1, $2, …
• A replacement string that contains a question mark (?)
• A rewrite directive followed by another directive such as rewrite, if, or set

In practical terms, environments that rely on rewrite chains for routing, canonicalization, or application fronting are more likely to include the risky patterns than minimal reverse-proxy configurations.

How Does Exploitation Work at a High Level?

At a high level, exploitation stems from a mismatch between a size calculation pass and a subsequent write pass during rewrite replacement processing. One pass estimates how large the destination buffer must be, then another pass writes the transformed result. Under certain conditions, characters may be handled differently between these passes, so the code allocates a buffer that is too small, then writes past it.

That write past the allocated heap buffer can corrupt memory in the worker process handling the request. In many cases, that corruption will show up as a crash and worker restart. In more favorable conditions for an attacker, memory corruption bugs can sometimes be shaped into code execution.

What Is the Real-World Impact: DoS vs Potential RCE?

The most consistently described outcome is denial of service via NGINX worker crashes. Because NGINX typically runs a master and multiple workers, a single crash may look like a brief blip, but repeated triggering can cause a crash loop and sustained availability issues.

Several reports also describe potential RCE, with a key caveat: RCE is considered possible when ASLR is disabled. That distinction matters for triage:

• If you run NGINX in an environment with strong exploit mitigations (ASLR enabled, modern heap hardening), impact may trend toward DoS.
• If you run in constrained or non-hardened environments (including some embedded, legacy, or specially configured systems), the risk of RCE increases.

Treat this as more than “just a crash” until you confirm your environment’s mitigations and configuration exposure.

Is There Evidence of Active Exploitation or a Public PoC?

As of the published reporting summarized in the research brief:

• Active exploitation: Unconfirmed
• CISA KEV inclusion: Not indicated
• Public PoC claims: A working proof-of-concept for NGINX Rift, demonstrating unauthenticated RCE, has been published by the researchers at depthfirst alongside their disclosure. The PoC demonstrates full code execution with ASLR disabled. Treat reproduction as straightforward for DoS; RCE requires more conditions to be met.

The absence of confirmed in-the-wild exploitation should not reduce urgency too much. An unauthenticated, remotely reachable NGINX flaw with a clear trigger pattern tends to draw fast attention once reliable reproduction details circulate.

How Can SOCRadar Help?

Security teams today are buried in CVE noise, threat actor activity, and an ever-expanding attack surface. SOCRadar Cyber Threat Intelligence cuts through that noise with actionable alerts on threat actors, malware campaigns, exploit maturity, Dark Web activity, and emerging IOCs – giving your team the context to act fast and prioritize what actually matters. Meanwhile, Attack Surface Management (ASM) continuously maps your internet-facing assets, exposed services, and misconfigurations, so you always know where you’re most at risk.

What Should Defenders Do Right Now?

Patch first where possible

The most direct mitigation is to upgrade to a fixed version:

• NGINX Open Source: upgrade to 1.30.1+ or 1.31.0+
• NGINX Plus: fixes are reported in R32 P6 and R36 P4 (and later)

Prioritize systems that are internet-facing and use complex rewrite logic, especially where rewrites handle authentication boundaries, app routing, or multi-tenant paths.

Reduce exposure if patching is delayed

If you cannot patch immediately, focus on removing the known-risk rewrite pattern:

• Replace unnamed captures ($1, $2, …) with named captures in rewrite rules where feasible.
• Review rewrite chains that include a ? in the replacement string and are followed by rewrite, if, or set.

Even if you cannot fully refactor quickly, you can often isolate risky rules into a safer pattern or reduce chaining until you complete the upgrade.

Operational checks to support triage

• Identify where rewrite rules are defined across included config files and templates.
• Watch for unexplained increases in worker restarts or crash signatures after unusual request spikes.
• If you run any hosts with ASLR disabled (intentionally or due to platform constraints), treat remediation as urgent.

What Key Dates Matter for CVE-2026-42945?

A few timeline points help frame why this is surfacing now:

• 2008: vulnerability introduced (around NGINX 0.6.27 timeframe)
• 2026-04-21: responsible disclosure date
• 2026-05-13: NVD published date (record “Awaiting Enrichment” at publication time)
• 2026-05-14: broader media coverage followed shortly after

If your organization has long-lived NGINX deployments that rarely change rewrite rules, this is a good time to treat the rewrite layer as code that needs periodic security review, not a one-time routing configuration.