NGINX Plus and NGINX Open Source have a vulnerability in the ngx_http_rewrite_module module

CVE-2026-42945 is a heap buffer overflow in NGINX's ngx_http_rewrite_module affecting 0.6.27 through 1.30.0. The trigger is not just 'NGINX is installed': the vulnerable path needs a rewrite replacement string containing ?, followed by a rewrite, if, or set that reuses an unnamed PCRE capture such as $1 or $2. A crafted HTTP request can then desynchronize length calculation from copy behavior and crash a worker; code execution is possible if ASLR is disabled or bypassed.

The vendor's HIGH 8.1 baseline is directionally fair, but the raw score overstates how many real deployments are actually exploitable. This is *unauthenticated remote* on a very common edge service, which keeps it important, yet the reachable population is materially reduced by the configuration precondition and by the fact that the scary RCE outcome is not the default outcome on modern hardened hosts. Net: keep it HIGH, but not CRITICAL.

Why this verdict

• Unauthenticated remote, but not universal: no creds or user action are needed, yet the reachable population is limited to requests that traverse a vulnerable rewrite-rule chain.
• Configuration precondition is the real brake: you need rewrite with ? followed by rewrite/if/set reusing unnamed captures like $1, which many NGINX installs simply do not have.
• RCE is conditional, DoS is easier: the public research shows worker crash is the default practical impact, while reliable code execution needs ASLR disabled or bypassed.

Why not higher?

This is not a clean all-default internet RCE across every exposed NGINX listener. The exploit chain narrows materially at two points: first on configuration shape, then again on host hardening for the RCE outcome. Those are meaningful brakes in a 10,000-host estate.

Why not lower?

Even with the config gating, this still lands on unauthenticated edge infrastructure that often fronts business-critical applications. A public PoC exists, vulnerable versions span a huge historical window, and worker-crash impact is operationally real even where RCE is blocked.

1. Hunt risky rewrite chains — Search nginx -T output and config management repos for a rewrite replacement containing ? followed by rewrite, if, or set reusing $1..$9. Do this first on internet-facing reverse proxies and ingress tiers, and complete it within 30 days.
2. Remove or refactor vulnerable rule patterns — Where you cannot patch immediately, rewrite rules to avoid the exact stateful sequence described in the advisory, especially unnamed captures reused after a rewrite ... ?.... Treat this as the temporary risk reduction step and deploy it within 30 days.
3. Keep platform hardening on — Verify ASLR and standard distro hardening remain enabled on NGINX hosts. This does not stop the bug, but it materially blocks the public RCE path and should be validated within 30 days.
4. Alert on worker crash loops — Add or tune detections for abnormal NGINX worker exits, rapid respawns, and path-heavy request bursts against rewrite-heavy locations. This gives you a chance to catch exploitation attempts while patch rollout completes, and should be in place within 30 days.

Run this on the target NGINX host as root or with sufficient privileges to execute nginx -T and read included configs. Save it as check-cve-2026-42945.sh and run sudo bash check-cve-2026-42945.sh; it outputs VULNERABLE, PATCHED, or UNKNOWN and exits with 0, 1, or 2 respectively.

#!/usr/bin/env bash
# check-cve-2026-42945.sh
# Defensive verifier for CVE-2026-42945 (NGINX rewrite-module heap overflow)
# Exit codes:
#   0 = VULNERABLE
#   1 = PATCHED
#   2 = UNKNOWN

set -u

TMPFILE="$(mktemp /tmp/nginx42945.XXXXXX 2>/dev/null || echo /tmp/nginx42945.$$)"
cleanup() {
  rm -f "$TMPFILE" 2>/dev/null || true
}
trap cleanup EXIT

ver_lt() {
  # returns 0 if $1 < $2
  [ "$(printf '%s\n%s\n' "$1" "$2" | sort -V | head -n1)" != "$2" ] && return 1
  [ "$1" = "$2" ] && return 1
  return 0
}

ver_ge() {
  # returns 0 if $1 >= $2
  ver_lt "$1" "$2" && return 1
  return 0
}

if ! command -v nginx >/dev/null 2>&1; then
  echo "UNKNOWN: nginx binary not found"
  exit 2
fi

VER_RAW="$(nginx -v 2>&1 || true)"
VER="$(printf '%s' "$VER_RAW" | sed -n 's#.*nginx/\([0-9][0-9.]*\).*#\1#p')"

if [ -z "$VER" ]; then
  echo "UNKNOWN: could not parse nginx version from: $VER_RAW"
  exit 2
fi

# Fixed upstream in 1.30.1 stable / 1.31.0 mainline. For practical sorting,
# any version >= 1.30.1 is considered fixed upstream for this CVE.
if ver_ge "$VER" "1.30.1"; then
  echo "PATCHED: nginx version $VER is at or above upstream fix boundary"
  exit 1
fi

# Ancient versions before 0.6.27 are outside the published affected range.
if ver_lt "$VER" "0.6.27"; then
  echo "PATCHED: nginx version $VER is below published affected range"
  exit 1
fi

if ! nginx -T >"$TMPFILE" 2>&1; then
  echo "UNKNOWN: nginx -T failed; version $VER is vulnerable range but config could not be inspected"
  exit 2
fi

# Heuristic config checks:
# 1) any rewrite replacement containing '?'
# 2) any later rewrite/if/set use of unnamed capture vars $1..$9
# This is intentionally conservative; absence of a match is UNKNOWN, not PATCHED.
HAS_Q_REWRITE=0
HAS_CAPTURE_REUSE=0

if grep -En '^[[:space:]]*rewrite[[:space:]].*\?.*;' "$TMPFILE" >/dev/null 2>&1; then
  HAS_Q_REWRITE=1
fi

if grep -En '^[[:space:]]*(rewrite|if|set)[[:space:]].*\$[1-9]' "$TMPFILE" >/dev/null 2>&1; then
  HAS_CAPTURE_REUSE=1
fi

if [ "$HAS_Q_REWRITE" -eq 1 ] && [ "$HAS_CAPTURE_REUSE" -eq 1 ]; then
  echo "VULNERABLE: nginx $VER is in affected range and config shows likely risky rewrite/capture pattern"
  exit 0
fi

# Optional stronger hint: show whether rewrite module appears in active config.
if grep -En '^[[:space:]]*(rewrite|if|set)[[:space:]]' "$TMPFILE" >/dev/null 2>&1; then
  echo "UNKNOWN: nginx $VER is in affected range and rewrite logic exists, but the risky pattern was not confirmed by this heuristic"
  exit 2
fi

echo "UNKNOWN: nginx $VER is in affected range, but no rewrite usage was detected by this heuristic; verify templates/includes and packaged backports manually"
exit 2

Sources

1. NGINX security advisories
2. NGINX news release for 1.30.1 / 1.31.0
3. NVD CVE-2026-42945
4. NGINX rewrite module documentation
5. DepthFirst public PoC repository
6. DepthFirst technical write-up
7. CISA Known Exploited Vulnerabilities catalog
8. FIRST EPSS overview