The sibling who showed up late to the same party — same root cause, new trigger, no bouncer yet
CVE-2026-93479 is a heap-based buffer overflow (CWE-122) in the NGINX map directive's regex-matching engine. When a map block uses regex capture variables ($1, $2, etc.) and the root directive or access_log format references those captures *before* the map's output variable is evaluated, an unauthenticated attacker can send a crafted HTTP request that overflows a heap buffer in the worker process. The reliable outcome is a worker crash and restart (DoS). On systems with ASLR disabled — or where the attacker chains an info leak to bypass it — arbitrary code execution is theoretically possible. Affected ranges are NGINX Open Source 1.30.0–1.30.5 and 1.31.2–1.31.6, plus NGINX Plus R33 through 37.1.0 (unpatched). Fixed in Open Source 1.31.7 / 1.30.6 and Plus 37.1.0.1 / 37.0.5.1. The NGINX Ingress Controller (multiple ranges) and Gateway Fabric (2.1.0–2.7.2, 1.5.0–1.6.2) are also affected.
F5's vendor rating diverges sharply from nginx.org's own assessment. F5 stamps it CVSS 3.1 8.1 HIGH and CVSS 4.0 9.2 Critical; the nginx.org project rates the same bug Medium. The truth is closer to nginx.org's read than to the CVSS 4.0 headline. The vulnerability requires a *specific, non-default configuration pattern* — unnamed regex captures in a map block, referenced by root or access_log before the map output variable — and RCE depends on defeating ASLR, which no public PoC has demonstrated for this CVE. Its sibling, CVE-2026-42533 (patched July 2026), shares the same root cause in a slightly different trigger context and *does* have a weaponized ASLR-bypass exploit chain by 0xCyberstan. That makes the RCE path plausible but unproven here. The DoS is real and reliable for affected configs, and NGINX's canonical role at the network edge keeps this firmly in HIGH territory — but calling it Critical overstates the current risk.
4 steps from start to impact.
Identify NGINX target with vulnerable map-regex config
Server header or response timing). The vulnerable configuration requires a map block with regex matching where root or access_log references unnamed capture variables ($1, $2) before the map output variable is evaluated. This is a non-default pattern typically seen in multi-tenant setups, dynamic document-root routing, or custom access logging. The attacker cannot remotely determine the exact config, but can spray requests to probe for crash behavior.- Target runs NGINX Open Source 1.30.0–1.30.5 or 1.31.2–1.31.6, or NGINX Plus R33–37.1.0 (unpatched)
- NGINX configuration uses map directive with regex and captures referenced in root/access_log before map output
- Configuration pattern is non-default — estimated 5–15% of NGINX deployments use map-regex captures in root/access_log
- Attacker cannot confirm vulnerable config remotely without triggering the bug
- Organizations that patched for CVE-2026-42533 in July may have already moved to 1.30.4+/1.31.3+, but those versions are *still* in the affected range for 93479
nginx -v or HTTP Server header. Config audit for the pattern is scriptable (see verification). Qualys QID and Tenable plugins expected within days of disclosure.Send crafted HTTP request to trigger heap overflow
- Network reachability to NGINX data plane (typically port 80/443)
- Request must match the map regex pattern to trigger capture variable evaluation
- Attacker needs to guess or discover what the map regex expects — blind exploitation is possible but noisy
- WAFs with deep request inspection may flag anomalous URI patterns, though the request itself looks syntactically valid
worker process exited on signal 11). GreyNoise has not reported scanning activity as of 2026-10-20. No Nuclei template for this specific CVE yet (one exists for the sibling CVE-2026-42533).Worker crash and restart (DoS achieved)
- Steps 1 and 2 succeeded
- NGINX master process restarts workers quickly (sub-second), so sustained DoS requires continuous attack traffic
- Multiple worker processes mean only one worker crashes per request — attacker must maintain request rate exceeding worker restart rate
- Rate limiting or connection limits on upstream load balancer can throttle the attack
(Conditional) Chain ASLR bypass for code execution
ngx_pool_cleanup_s handlers to system(). The technique *may* transfer to 93479 since the same PCRE capture-clobbering mechanism is involved, but no public PoC confirms this for 93479 specifically.- ASLR disabled (rare on modern Linux) OR attacker can adapt the CVE-2026-42533 info-leak technique to the root/access_log trigger path
- Attacker has the exploit chain tooling — currently only demonstrated for 42533
- ASLR is enabled by default on all modern Linux distributions (Ubuntu, RHEL, Debian, Alpine)
- No public exploit code exists for 93479's RCE path
- The info-leak primitive from 42533 may not directly apply to the root/access_log evaluation context
- PIE + stack canaries + RELRO on distro-compiled NGINX binaries add further hardening
$1, $2) in map blocks with named captures ($name) and ensure they are referenced only within the regex match scope. This eliminates the vulnerable variable-evaluation ordering. Deploy within 30 days per the noisgate mitigation SLA for HIGH. Run grep -rn 'map.*~' /etc/nginx/ | grep -v '#' to find map blocks with regex, then audit each for unnamed capture usage in root or access_log directives.apt-cache policy nginx or rpm -q nginx rather than relying on upstream version numbers.limit_req_zone in NGINX itself, or upstream L4/L7 rate limits) reduces an attacker's ability to sustain a crash loop. This does not prevent the overflow but limits the operational impact. Configure limit_req with a burst value aligned to your normal traffic profile and a nodelay policy for excess requests.worker_processes auto with worker_rlimit_core 0 (disable core dumps to prevent info leakage) and use cgroup or systemd resource limits to contain worker crash impact. This limits the blast radius of a crash but does not prevent it. Also ensure NGINX is compiled with PIE, stack canaries, and full RELRO (default on modern distro packages).- Generic WAF rules — the trigger is a syntactically valid HTTP request whose URI/headers match the map regex. There is no malformed syntax or known payload signature to match against. The request looks like normal traffic.
- ModSecurity / OWASP CRS — same limitation. The overflow is triggered by the internal variable-evaluation order, not by request content that violates HTTP grammar or matches known attack patterns.
- Disabling ASLR checks — some hardening guides suggest verifying ASLR is enabled. While ASLR prevents RCE, it does nothing for the DoS path, which is the primary reliable impact. Do not treat ASLR as a sufficient mitigation.
- Upgrading only to 1.30.4/1.31.3 (the CVE-2026-42533 fix) — those versions are *still in the affected range* for CVE-2026-93479. The July patch was incomplete for the root/access_log trigger path. You must go to 1.30.6+/1.31.7+.
The supporting signals.
| In-the-Wild Exploitation | None reported. Not on CISA KEV. No campaigns attributed. F5 PSIRT confirms no evidence of active exploitation as of disclosure (2026-10-14). |
|---|---|
| Proof-of-Concept | No public PoC for CVE-2026-93479. No repos on GitHub named after this CVE. No entries found on pocindex.io. However, the sibling CVE-2026-42533 has a full-chain PoC by Stan Shaw (0xCyberstan) with ASLR bypass, and a Nuclei detection template from Sn1per. Adaptation to 93479 is plausible but undemonstrated. |
| EPSS | 0.00554 (0.55%) — low exploitation probability. Reflects no PoC, no exploitation, and the configuration dependency. Expect this to rise if a PoC emerges or the 42533 technique is confirmed transferable. |
| CVSS Vectors | CVSS 3.1: AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H = 8.1 HIGH — AC:H reflects conditions beyond attacker control (config dependency). CVSS 4.0: 9.2 Critical — inflated; does not adequately weight the config prerequisite. nginx.org rating: Medium — more conservative, reflecting their view of the config rarity. |
| Affected Versions | Open Source: 1.30.0–1.30.5, 1.31.2–1.31.6. Plus: R33–R36, 37.0.0–37.0.4, 37.1.0. Ingress Controller: multiple ranges. Gateway Fabric: 2.1.0–2.7.2, 1.5.0–1.6.2. |
| Fixed Versions | Open Source: 1.30.6 (stable), 1.31.7 (mainline). Plus: 37.0.5.1, 37.1.0.1. No fix for Plus R33–R36 — F5 recommends upgrading to a supported release. Distro backports: Debian bookworm/trixie patches in progress; check dpkg -l nginx for distro-specific versioning. |
| Internet Exposure | Shodan indexes ~58.5M NGINX instances globally; ZoomEye reports ~312M. NGINX is the world's most popular web server/reverse proxy. However, the vulnerable *configuration pattern* (map-regex captures in root/access_log) is a small subset. No GreyNoise tags or Censys scanning campaigns specific to this CVE as of 2026-10-20. |
| Reporting Researchers | Matt Suiche (Tolmo, Inc.) and Mateusz Gierblinski — credited by F5 in advisory K000162607. |
| Disclosure Timeline | 2026-10-14: F5 advisory published, NGINX 1.30.6 and 1.31.7 released. Sibling CVE-2026-42533 was patched 2026-07-09 in NGINX 1.30.4/1.31.3, meaning the 93479-affected range (1.30.0–1.30.5) overlaps with post-42533-patch versions. |
| Related Vulnerabilities | CVE-2026-42533 — same root cause (map-regex capture clobbering), different trigger context (generic string expression vs. root/access_log). Has a weaponized PoC with ASLR bypass since 2026-07-27. Patched in 1.30.4/1.31.3 — but 93479 was found in the *same code after that patch*, confirming the July fix was incomplete for the root/access_log path. |
Sources.
- F5 Security Advisory K000162607
- nginx.org Security Advisories
- SecurityOnline — F5 Patches Three NGINX Vulnerabilities
- 0xCyberstan CVE-2026-42533 PoC (sibling exploit chain)
- NGINX GitHub Release 1.30.6 (stable fix)
- NGINX GitHub Release 1.31.7 (mainline fix)
- Feedly CVE Intelligence — CVE-2026-93479
- Microsoft Azure Linux autopatcher PR (distro backport)
Why this verdict
- Configuration dependency narrows reachable population: The bug requires a non-default NGINX configuration — a
mapblock with regex captures referenced byrootoraccess_logbefore the map output variable. This is a multi-tenant / dynamic-routing pattern used by an estimated 5–15% of NGINX deployments. The CVSS 3.1 AC:H partially captures this, but the real-world narrowing is more severe than a single AC:H toggle implies. - No public PoC and no exploitation in the wild: Despite the sibling CVE-2026-42533 having a full exploit chain since July 2026, no researcher has published a PoC adapting that technique to 93479's trigger path. EPSS at 0.55% reflects this. The exploitation window is currently theoretical.
- RCE requires unproven ASLR bypass for this variant: Code execution demands ASLR be disabled (rare) or bypassed. The sibling's info-leak technique *may* transfer, but the root/access_log evaluation context differs from the generic string-expression context where the leak was demonstrated. Modern distro-compiled NGINX also has PIE, stack canaries, and full RELRO.
- nginx.org itself rates this Medium: The project maintainers — who understand the code path and config prevalence better than any CVSS calculator — rate this Medium. F5's CVSS 4.0 9.2 Critical reflects worst-case math, not operational reality.
- Role multiplier: NGINX is a canonical network edge appliance — reverse proxy, load balancer, API gateway, Kubernetes ingress controller. Over 50% of NGINX installs occupy this high-value role. If the chain succeeds on an edge instance, the blast radius is *all services behind that proxy* (DoS) or *network perimeter breach* (RCE). For Kubernetes Ingress Controller deployments, a compromise could affect cluster-wide traffic routing. This floors the verdict at HIGH regardless of other friction. However, the config prerequisite means only a subset of edge deployments are reachable, and RCE is unproven — preventing escalation to CRITICAL.
- Sibling CVE creates urgency context: CVE-2026-42533's weaponized exploit demonstrates the code path is exploitable in principle. The existence of 93479 proves the July patch was incomplete. Researchers are actively probing this code — a PoC for 93479 is a matter of time, not possibility. This prevents downgrade below HIGH.
Why not higher?
CRITICAL would require either confirmed RCE with ASLR bypass for this specific variant, active exploitation in the wild, or a default-configuration trigger. None of these conditions are met. The configuration prerequisite is a genuine narrowing factor that limits the reachable population to a fraction of NGINX installs. The CVSS 4.0 score of 9.2 does not reflect that most NGINX deployments will never encounter the vulnerable code path. nginx.org's own Medium rating and EPSS at 0.55% further support restraint.
Why not lower?
MEDIUM would underweight NGINX's canonical role at the network perimeter where DoS impact is service-wide, the unauthenticated remote attack vector with no user interaction, and the demonstrated exploitability of the shared code path via CVE-2026-42533's full chain. The sibling's ASLR bypass technique makes RCE *plausible* even if unproven for this trigger, and the research community is actively working the code path. Dropping below HIGH would be negligent given the edge-appliance deployment reality and the incomplete-patch narrative.
Crowdsourced verification payload.
Run this script on each NGINX host as root (or a user with read access to the NGINX binary and config files). Invoke with: sudo bash check_cve_2026_93479.sh. It checks the installed NGINX version against the vulnerable range and scans the active configuration for the dangerous map-regex-capture-in-root/access_log pattern. No network access required.
#!/usr/bin/env bash
# check_cve_2026_93479.sh — Detect CVE-2026-93479 exposure
# Checks NGINX version + configuration for vulnerable pattern
# Exit codes: 0=PATCHED, 1=VULNERABLE, 2=UNKNOWN
set -euo pipefail
RED='\033[0;31m'; GREEN='\033[0;32m'; YELLOW='\033[1;33m'; NC='\033[0m'
# --- Step 1: Find NGINX binary ---
NGINX_BIN=$(command -v nginx 2>/dev/null || echo "")
if [[ -z "$NGINX_BIN" ]]; then
echo -e "${YELLOW}[UNKNOWN]${NC} nginx binary not found in PATH."
exit 2
fi
# --- Step 2: Extract version ---
VERSION_RAW=$($NGINX_BIN -v 2>&1 | grep -oP 'nginx/\K[0-9]+\.[0-9]+\.[0-9]+')
if [[ -z "$VERSION_RAW" ]]; then
echo -e "${YELLOW}[UNKNOWN]${NC} Could not parse nginx version."
exit 2
fi
echo "Detected NGINX version: $VERSION_RAW"
# --- Step 3: Version comparison ---
version_gte() {
printf '%s\n%s' "$1" "$2" | sort -V | head -n1 | grep -qx "$2"
}
version_gt() {
[[ "$1" != "$2" ]] && version_gte "$1" "$2"
}
VULN_VERSION=false
# Stable branch: 1.30.0 <= v <= 1.30.5
if version_gte "$VERSION_RAW" "1.30.0" && ! version_gt "$VERSION_RAW" "1.30.5"; then
VULN_VERSION=true
echo "Version $VERSION_RAW is in vulnerable stable range (1.30.0-1.30.5)."
fi
# Mainline branch: 1.31.2 <= v <= 1.31.6
if version_gte "$VERSION_RAW" "1.31.2" && ! version_gt "$VERSION_RAW" "1.31.6"; then
VULN_VERSION=true
echo "Version $VERSION_RAW is in vulnerable mainline range (1.31.2-1.31.6)."
fi
if [[ "$VULN_VERSION" == false ]]; then
echo -e "${GREEN}[PATCHED]${NC} NGINX $VERSION_RAW is outside the vulnerable range."
exit 0
fi
# --- Step 4: Check configuration for vulnerable pattern ---
echo "Scanning NGINX configuration for vulnerable map-regex pattern..."
CONF_FILE=$($NGINX_BIN -T 2>/dev/null) || {
echo -e "${YELLOW}[UNKNOWN]${NC} Cannot dump NGINX config (run as root?)."
echo -e "${RED}[VULNERABLE]${NC} Version is in affected range but config check failed."
exit 1
}
# Look for map blocks with regex (~) that have capture groups
MAP_REGEX=$(echo "$CONF_FILE" | grep -cP '^\s*map\s+.*~' 2>/dev/null || echo "0")
if [[ "$MAP_REGEX" -eq 0 ]]; then
echo "No map directives with regex matching found in active config."
echo -e "${GREEN}[PATCHED]${NC} Version is vulnerable but config does not use map-regex. Low risk."
# Still report as vulnerable since a config change could introduce the pattern
echo "(Note: version is still in affected range — upgrade recommended.)"
exit 0
fi
# Check if root or access_log references numbered captures ($1, $2, etc.)
ROOT_CAPTURE=$(echo "$CONF_FILE" | grep -cP '^\s*(root|access_log)\s+.*\$[0-9]+' 2>/dev/null || echo "0")
if [[ "$ROOT_CAPTURE" -gt 0 ]]; then
echo -e "${RED}[VULNERABLE]${NC} NGINX $VERSION_RAW with map-regex AND root/access_log"
echo " referencing numbered capture variables (\$1, \$2, etc.)."
echo " This matches the CVE-2026-93479 trigger pattern."
echo " ACTION: Patch immediately or rewrite captures to named variables."
exit 1
else
echo "Map-regex found but root/access_log does not reference numbered captures."
echo -e "${YELLOW}[VULNERABLE]${NC} Version in affected range. Config appears safe but"
echo " upgrade to 1.30.6+/1.31.7+ is still recommended as a defense-in-depth measure."
exit 1
fi