CVE-2026-42533

What it actually does

This is a data-plane heap buffer overflow in NGINX worker processes triggered during request processing when specific configuration patterns are present. The vulnerable condition involves a map directive using regular-expression matching where a string expression references the map regex capture variables before referencing the map output variable, or comparable behavior involving non-cacheable variables in string expressions. A crafted unauthenticated HTTP request can corrupt heap memory in a worker process, typically causing the worker to crash and restart. Under stronger exploitation conditions, especially where ASLR is disabled or bypassed, the memory corruption could potentially be used for remote code execution in the context of the NGINX worker process.

Why it matters to the business

An exposed NGINX instance using the affected configuration pattern can be remotely crashed by unauthenticated traffic, potentially causing service disruption, degraded availability, failed transactions, or instability in applications fronted by NGINX. Although exploitation requires configuration-specific conditions and the CVSS attack complexity is high, the affected component is commonly internet-facing and sits on critical request paths, so successful exploitation could have outsized operational impact. Code execution is less likely than denial of service but would be severe if achieved, because an attacker could gain a foothold on a reverse proxy or edge service. This issue is not currently listed in CISA KEV and no ransomware use is indicated, but it should still be prioritized for internet-facing NGINX deployments matching the vulnerable configuration pattern.

How an attack unfolds

An attacker first identifies an NGINX service reachable over HTTP or HTTPS and attempts to infer whether the server uses request-dependent routing, rewriting, proxying, or header logic backed by map directives. Exploitation depends on the target configuration: the vulnerable code path is reached when regex capture variables from a map are referenced in a string expression before the map output variable is referenced, or when similar behavior is induced through non-cacheable variables. The attacker sends crafted HTTP requests with values in the relevant request component, such as URI, host, header, cookie, query string, or other mapped variable, designed to trigger the vulnerable regex capture and evaluation order. If the condition is met, NGINX mishandles heap memory in the worker process. In the common outcome, the worker process terminates abnormally and the master process starts a replacement, causing connection resets, intermittent 5xx responses, or degraded service. In a more advanced scenario, if memory protections such as ASLR are disabled or bypassed, the same corruption primitive could potentially be shaped into code execution as the NGINX worker user.

How to fix it

Upgrade affected NGINX packages to a fixed release. For the listed Red Hat nginx-main package, update to nginx-main 1.30.4-2.hum1 or later as provided by RHSA-2026:46012. After upgrading, reload or restart NGINX so all worker processes are running the fixed binary. As an immediate mitigation where upgrade cannot be completed quickly, review NGINX configuration for map directives using regex captures and string expressions that reference capture variables before the map output variable; refactor those expressions so the map output variable is evaluated first, avoid relying on map regex capture variables in later string expressions, or replace regex-based maps with safer exact-match logic where practical. Also review uses of non-cacheable variables in string expressions. Ensure ASLR is enabled at the operating-system level to reduce the likelihood of code execution. For internet-facing deployments, consider temporary request filtering for suspicious high-variance headers, cookies, and query strings targeting mapped variables, but do not rely on filtering as a substitute for patching.

How to confirm the fix worked

Confirm the installed NGINX package version is fixed, for example by checking package manager output and verifying the running binary version after restart or reload. On Red Hat-based systems, validate that nginx-main is at 1.30.4-2.hum1 or later and that the applicable RHSA-2026:46012 advisory is installed. Confirm no old NGINX worker processes remain after the update by checking process start times and binary mappings. Review NGINX configuration with `nginx -T` and search for `map` blocks using regex patterns and capture references such as `$1`, `$2`, or named captures; verify vulnerable evaluation order has been removed or the server is patched. Validate ASLR is enabled, for example by checking that `/proc/sys/kernel/randomize_va_space` is set to `2` on Linux. For exposure testing, prefer configuration review and version verification over exploit testing, because active proof-of-concept attempts may crash workers.

Typical attack path

1. Scan for internet-facing NGINX services and identify likely NGINX Plus or NGINX Open Source deployments.
2. Send benign probing requests to understand routing behavior, virtual hosts, redirects, error responses, and application paths likely governed by NGINX variables or map directives.
3. Craft HTTP requests that place attacker-controlled strings into values commonly used by map directives, such as Host, URI, query parameters, cookies, or custom headers.
4. Trigger regex map matching and the vulnerable variable evaluation order in a susceptible configuration.
5. Cause heap corruption in an NGINX worker process.
6. Observe service effects such as worker crashes, connection resets, intermittent 502/503/504 responses, or error-log crash messages.
7. If attempting higher-impact exploitation, iterate payloads to bypass ASLR or target systems where ASLR is disabled, with the goal of executing code in the NGINX worker process context.

How to detect it

Look for evidence of abnormal NGINX worker termination correlated with unusual HTTP requests. Primary log sources include NGINX error logs, NGINX access logs, systemd journal, syslog, kernel logs, crash dump tooling, container runtime logs, and endpoint detection telemetry. In NGINX error logs and system logs, search for worker processes exiting on fatal signals, segmentation faults, malloc or heap corruption messages, repeated worker restarts, and bursts of upstream 502/503/504 errors. In access logs, pivot around the seconds before each crash and look for repeated requests with unusual or oversized Host headers, cookies, query strings, URI components, or custom headers that may feed map directives. If core dumps are enabled, collect core files for NGINX worker processes and inspect crash time, signal, faulting module, and request correlation. Because there are no public exploit indicators provided and exploit maturity is listed as none, detection should focus on behavioral evidence: crash loops, memory-corruption artifacts, and suspicious request patterns immediately preceding worker crashes. If named threat intelligence later emerges, add actor-specific infrastructure, user agents, and payload patterns to searches.

• worker process exited on signal 11
• worker process exited on signal 6
• segmentation fault
• segfault at
• core dumped
• nginx: worker process
• kernel: nginx
• systemd-coredump
• malloc(): corrupted
• malloc(): invalid
• free(): invalid pointer
• corrupted double-linked list
• /var/log/nginx/error.log
• /var/log/nginx/access.log
• /var/lib/systemd/coredump/
• /var/crash/
• /proc/sys/kernel/randomize_va_space
• 502 Bad Gateway
• 503 Service Temporarily Unavailable
• 504 Gateway Time-out

What your security team should do

• Prioritize patching internet-facing NGINX instances and any NGINX systems handling critical traffic, even though exploitation is configuration-dependent and not currently known to be exploited in KEV.
• Upgrade Red Hat nginx-main to 1.30.4-2.hum1 or later under RHSA-2026:46012, then restart or reload NGINX and confirm all workers are running the fixed version.
• Inventory NGINX configurations using `map` directives with regex captures, especially where request-controlled inputs such as Host, URI, headers, cookies, or query strings are mapped.
• Refactor risky map usage as a defense-in-depth measure, particularly where regex capture variables are consumed in string expressions before the map output variable.
• Verify ASLR is enabled on all NGINX hosts and investigate any hardened-production exceptions where ASLR is disabled.
• Monitor NGINX error logs, system logs, and crash reporting for worker segmentation faults or repeated abnormal exits, especially following unusual HTTP request bursts.
• Add temporary alerting for repeated NGINX worker crashes, spikes in 502/503/504 responses, and core dumps associated with NGINX.
• If crashes are observed, preserve NGINX access logs, error logs, core dumps, package versions, and full rendered configuration before restarting repeatedly or rotating logs.