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

CVE-2026-9256 is a heap-based buffer overflow in NGINX ngx_http_rewrite_module triggered when a rewrite directive combines *overlapping PCRE captures* with a replacement string that references multiple captures in a redirect or arguments context. Upstream marks Open Source NGINX 0.1.17 through 1.31.0 as vulnerable and 1.31.1+ / 1.30.2+ as fixed; the same bug also affects corresponding NGINX Plus builds, with vendor-fixed releases at R32 P7, R36 P5, and 37.0.1.1.

The vendor's HIGH rating is technically understandable because the bug is unauthenticated and sits on the data plane, but it overshoots most enterprise reality. The decisive friction is *configuration specificity*: an attacker only gets leverage if your live config contains the exact rewrite pattern shape, and even then the common result on modern Linux is worker crash/restart, while true RCE needs ASLR disabled or a separate ASLR bypass.

Why this verdict

• Downgraded for config-specific reachability: the attacker needs a narrow rewrite pattern with overlapping captures plus multiple backreferences; most NGINX installs will not meet that prerequisite.
• Downgraded for exploitation reliability: vendor text itself conditions code execution on ASLR being disabled or bypassed, which cuts against broad internet-scale RCE in modern fleets.
• Upward pressure remains because it is unauthenticated and edge-facing: if the bad rewrite exists on a public route, the attacker does not need credentials or user interaction to hit it.
• No exploitation pressure today: no KEV listing, no primary-source campaign reporting, and the user-supplied EPSS is extremely low.
• Worker-process blast radius is usually bounded: the common operational failure mode is a worker restart or crash, which matters for availability but is not the same as durable host takeover.

Why not higher?

This is not a straight-line unauthenticated RCE against every exposed NGINX server. A vulnerable binary is only part of the story; the exploit path also needs a precise rewrite configuration shape and, for the worst-case outcome, weak or bypassed memory-randomization defenses.

Why not lower?

The bug still lives in a public request-processing path on one of the most widely deployed edge servers in enterprise estates. If your config does contain the bad rewrite pattern, an unauthenticated remote party can trigger memory corruption with no foothold, so this is not backlog trivia.

1. Audit live rewrite rules — Run nginx -T across internet-facing NGINX and search for nested capture groups combined with multiple backreferences in rewrite replacements, especially redirects and query-string rewrites. For a MEDIUM finding there is no mitigation SLA — go straight to the 365-day remediation window, but this audit should happen in the next normal engineering cycle because it determines whether the bug is actually reachable in your fleet.
2. Prefer simple rewrites or non-capturing groups — Where business logic allows, replace overlapping capture designs with simpler regex or non-capturing groups so that a vulnerable version loses the dangerous trigger condition. There is no mitigation SLA for this bucket, so treat it as a normal-change hardening task while you work through patching.
3. Keep ASLR fully enabled — Validate kernel.randomize_va_space=2 and avoid local hardening exceptions that weaken user-space randomization. This does not remove the bug, but it materially degrades the path from crash to code execution; for MEDIUM, do it in ordinary platform hygiene work rather than as an emergency change.
4. Watch for worker crash patterns — Alert on NGINX worker restarts, segfaults, coredumps, and URI-specific 5xx spikes so you can distinguish opportunistic fuzzing from normal traffic anomalies. This is the most useful near-term detective control when version-only asset data cannot tell you whether the vulnerable rewrite exists.

Run this on the target NGINX host or inside the container image that actually serves traffic. Invoke it as sudo bash ./check-cve-2026-9256.sh because it needs nginx -v and ideally nginx -T access to the loaded config; it prints PATCHED, VULNERABLE, or UNKNOWN and exits 0, 1, or 2 respectively.

#!/usr/bin/env bash
# check-cve-2026-9256.sh
# Detect likely exposure to CVE-2026-9256 (NGINX ngx_http_rewrite_module overlapping captures)
# Exit codes:
#   0 = PATCHED
#   1 = VULNERABLE
#   2 = UNKNOWN

set -u

patched_mainline_min="1.31.1"
patched_stable_min="1.30.2"
mainline_floor="1.31.0"

have_cmd() { command -v "$1" >/dev/null 2>&1; }

ver_ge() {
  # returns 0 if $1 >= $2
  [ "$(printf '%s\n%s\n' "$2" "$1" | sort -V | head -n1)" = "$2" ]
}

ver_lt() {
  # returns 0 if $1 < $2
  ! ver_ge "$1" "$2"
}

extract_version() {
  local raw
  raw="$(nginx -v 2>&1)" || return 1
  printf '%s' "$raw" | sed -n 's#.*nginx/\([0-9][0-9.]*\).*#\1#p'
}

if ! have_cmd nginx; then
  echo "UNKNOWN: nginx binary not found in PATH"
  exit 2
fi

version="$(extract_version)"
if [ -z "${version:-}" ]; then
  echo "UNKNOWN: could not parse nginx version"
  exit 2
fi

# Patched version logic:
# - mainline fixed at 1.31.1+
# - stable fixed at 1.30.2+ and < 1.31.0
if ver_ge "$version" "$patched_mainline_min"; then
  echo "PATCHED: nginx version $version is >= $patched_mainline_min"
  exit 0
fi

if ver_ge "$version" "$patched_stable_min" && ver_lt "$version" "$mainline_floor"; then
  echo "PATCHED: nginx version $version is in the fixed stable range >= $patched_stable_min and < $mainline_floor"
  exit 0
fi

# Vulnerable code train. Now check whether config appears to contain the risky rewrite pattern.
config_dump="$(nginx -T 2>&1)"
nginx_t_rc=$?
if [ $nginx_t_rc -ne 0 ] || [ -z "$config_dump" ]; then
  echo "UNKNOWN: nginx version $version is vulnerable-by-version, but 'nginx -T' could not be read"
  exit 2
fi

# Heuristic checks only. We look for rewrite lines with:
# - nested capture groups like ((...))
# - multiple backreferences in replacement like $1$2
# - redirect or query-string usage, which upstream says are relevant contexts
suspicious_lines="$(printf '%s\n' "$config_dump" | awk '
  BEGIN { IGNORECASE=1 }
  /^[[:space:]]*rewrite[[:space:]]+/ {
    line=$0
    nested = (line ~ /\(\([^)]*\*[^)]*\)\)/ || line ~ /\(\(.*\)\)/)
    multibackref = (line ~ /\$[0-9].*\$[0-9]/)
    redirectish = (line ~ /redirect[[:space:]]*;/ || line ~ /\?.*\$[0-9]/)
    if (nested && multibackref && redirectish) print line
  }
')"

if [ -n "$suspicious_lines" ]; then
  echo "VULNERABLE: nginx version $version is vulnerable and suspicious rewrite directives were found"
  printf '%s\n' "$suspicious_lines" | sed 's/^/MATCH: /'
  exit 1
fi

echo "UNKNOWN: nginx version $version is vulnerable-by-version, but no obvious matching rewrite directives were found by heuristic scan"
exit 2

Sources

1. NVD CVE-2026-9256
2. NGINX security advisories
3. NGINX CHANGES
4. NGINX fix commit 3f135ae
5. Openwall disclosure thread
6. Ubuntu CVE tracker
7. Debian security tracker
8. OpenResty 1.29.2.5 release