What Is the NGINX ngx_http_rewrite_module Heap Overflow — and How Should You Respond?

# What Is the NGINX ngx_http_rewrite_module Heap Overflow — and How Should You Respond?

CVE-2026-42945 is a critical (CVSS v4 9.2) heap-based buffer overflow in NGINX’s ngx_http_rewrite_module that can crash worker processes (DoS) and, in some environments, be exploited for remote code execution (RCE). The practical response is straightforward: patch NGINX (Open Source or Plus) as your primary fix, then audit rewrite/set configurations for the specific trigger pattern while you monitor for worker crashes and suspicious request sequences.

What CVE-2026-42945 is (in plain terms)

At a high level, this bug lives inside the rewrite module’s script evaluation framework, which NGINX uses to evaluate directives such as rewrite, set, and related constructs that build output strings from variables and regex capture groups. CVE-2026-42945 is classified as a heap-based buffer overflow (CWE-122).

Two aspects make it unusually concerning:

• It affects both NGINX Open Source and NGINX Plus, and it has apparently been present since at least NGINX 0.6.27 (2008)—hence the “18-year-old bug” framing in coverage.
• It’s remotely reachable without authentication, but only when a server’s configuration matches a specific pattern involving rewrite targets and capture groups.

If you want background on the module itself (directives, syntax, common usage), NGINX’s documentation is the canonical reference—but for vulnerability-specific detail, keep reading. (We also track related writeups and guidance here: nginx / heap overflow / ngx_http_rewrite_module.)

How the bug works: a two-pass mismatch becomes a heap overflow

The core technical idea is that the rewrite module’s “script engine” evaluates expressions in two passes:

1. Length-calculation pass: compute how many bytes are needed for the final expanded string.
2. Copy pass: allocate a buffer based on that size and then copy/expand the computed content into it.

CVE-2026-42945 occurs because these two passes can disagree about the internal state they’re using and—critically—about how many bytes expansion will require.

Per the CVE report summary, “The vulnerability resides within this script evaluation framework and specifically affects how the engine handles state flags during multi-phase execution.” In the described trigger, an internal flag (referred to as is_args/state) flips when a query-string delimiter (?) is encountered in a rewrite target during the first pass. But later calculations don’t remain consistent across the two phases.

The overflow comes from a classic pattern: in the copy pass, escaping can expand the number of bytes written compared to what the length pass predicted. The brief specifically calls out escaping behavior akin to NGX_ESCAPE_ARGS being applied during the copy pass but omitted during the length pass, so the engine allocates an undersized heap buffer—and then writes past it when the expanded bytes are copied.

That is the essence of the bug: a state mismatch causes a size mismatch, and the result is heap memory corruption in an NGINX worker process.

When rewrite/set directives trigger it (the vulnerable pattern)

Not every server running NGINX is exploitable. The brief is explicit that exploitation depends on an uncommon combination of configuration and request inputs—not a generic flaw in request parsing.

The risky configuration pattern is:

• A rewrite directive whose target includes a ?, and then
• A following directive that references unnamed capture groups like $1, $2, ....

In this scenario, the ? changes internal state in the evaluation engine in a way that sets up the later mismatch when capture groups are expanded and copied. A remote attacker then supplies crafted HTTP requests (including URIs that interact with those rewrite rules) to drive the vulnerable execution path.

If your deployment relies heavily on rewrite logic, it’s worth treating this as both a security and an availability issue, because the most consistent outcome is repeated worker crashes and restarts.

Why it can be DoS—and under certain conditions, RCE

The most reliable outcome is Denial of Service: memory corruption causes the worker to crash/restart. The CVE report describes this as “severe memory corruption within the NGINX worker process,” and notes that while DoS is the consistent impact, “precise heap manipulation permits remote code execution.”

RCE is not promised in every environment. The sources emphasize it’s more feasible when exploit mitigations are weak—an advisory summary highlights that “for systems with ASLR disabled, code execution is possible.” The practical takeaway: even if you assume “just a crash,” the bug is still critical because memory corruption vulnerabilities can move from stability issues to compromise when conditions allow.

Who and what is affected

You should consider yourself at risk if you have:

• NGINX Open Source or NGINX Plus
• Using ngx_http_rewrite_module
• With rewrite/set/if usage matching the vulnerable pattern (rewrite target includes ?, followed by directives referencing $1, $2, etc.)
• Exposed to untrusted traffic (especially internet-facing)

The attacker needs no authentication, but they do need your configuration and request path to line up with the vulnerable behavior. That nuance matters for triage: you can prioritize patching everywhere, but focus emergency response on systems most likely to match the pattern.

Detection: what ops teams should look for

Because the most common manifestation is instability, detection starts with availability signals and then pivots to request forensics:

• Worker crashes/restarts that you can correlate to unusual request spikes.
• Access log patterns suggesting deliberate attempts to trigger rewrite rules—especially requests containing query delimiters (?) and sequences that appear designed to interact with capture group expansion.
• Signs of public PoC-driven activity. A proof of concept is publicly available in DepthFirstDisclosures’ nginx-rift repository, and scanning campaigns often mirror public exploit structure.

If you suspect exploitation, preserve what you can: access logs around the crash window and any crash artifacts (for example, core dumps if enabled and retained in your environment).

Mitigation and response: the practical playbook

1) Patch first (the real fix).

Both NGINX Open Source and NGINX Plus have issued fixes; follow their advisories and ensure you’re on a patched version.

2) Apply configuration stopgaps only as temporary controls.

While you roll patches, audit for the vulnerable pattern and remove or avoid rewrite/set constructs involving ? paired with unnamed captures. Where feasible, disable ngx_http_rewrite_module to reduce attack surface—but expect operational impact if your routing depends on it.

3) Hardening and exposure reduction.

Enable standard exploit mitigations (the sources explicitly call out ASLR), and use WAF/ingress filtering to reduce exposure to suspicious crafted requests. This won’t “fix” the bug, but it can lower the chance of successful triggering from hostile traffic.

4) Incident response hygiene.

If crashes suggest active probing, preserve logs, collect crash evidence, and investigate for signs of post-exploitation artifacts consistent with heap manipulation.

Why It Matters Now

This issue became more urgent because it’s no longer theoretical: it was publicly disclosed with proof-of-concept exploit code (“nginx-rift”), and multiple security outlets amplified it as an “18-year-old” flaw. That combination—a critical CVSS (9.2), unauthenticated remote reachability under certain configs, and PoC availability—is exactly what tends to accelerate real-world scanning and opportunistic exploitation, especially against internet-facing NGINX instances that haven’t audited rewrite rules in years.

What to Watch

• Official NGINX advisories and release notes: confirm the fixed versions and compare them to what you actually run (Open Source vs Plus).
• PoC-driven scanning activity: watch threat feeds and your own logs for traffic patterns consistent with public exploit attempts (notably those associated with DepthFirstDisclosures’ PoC).
• Operational signals: unexplained worker crashes/restarts and correlated spikes in suspicious requests that appear designed to tickle rewrite/capture-group behavior.

Sources: cvereports.com • my.f5.com • thehackernews.com • github.com • cybersecuritynews.com • nginx.org