Full Report
F5 has shipped fixes for a critical nginx flaw that lets a remote, unauthenticated attacker trigger a heap buffer overflow in the worker process with crafted HTTP requests. CVE-2026-42533 was patched on July 15 in nginx 1.30.4 (stable) and 1.31.3 (mainline), and in NGINX Plus 37.0.3.1; anyone on an earlier build should upgrade. Triggering it can crash or restart the worker, causing a denial of
Analysis Summary
# Vulnerability: Heap Buffer Overflow in NGINX Script Engine
## CVE Details
- **CVE ID:** CVE-2026-42533
- **CVSS Score:** 9.2 (Critical) via CVSS v4 / 8.1 (High) via CVSS v3.1
- **CWE:** CWE-122 (Heap-based Buffer Overflow)
## Affected Systems
- **Products:** NGINX Open Source (Stable and Mainline), NGINX Plus, NGINX Ingress Controller, Gateway Fabric, App Protect WAF, and Instance Manager.
- **Versions:** All versions from 0.9.6 through 1.31.2.
- **Configurations:** Systems using a regex-based `map` directive where the output variable is referenced in a string expression following a numbered capture (e.g., `$1`, `$2`) from a previous regex match.
## Vulnerability Description
The flaw exists in the NGINX script engine’s evaluation of string expressions. When assembling strings, the engine uses a two-pass process: the first pass calculates the required buffer size, and the second pass writes the data.
The vulnerability is triggered when a regex `map` execution occurs between these two passes. This intermediate execution overwrites the shared capture state. Consequently, the first pass calculates a buffer size based on the original capture, but the second pass writes data based on a new, attacker-controlled capture. This discrepancy leads to a heap buffer overflow where both the length and the content of the overrun are determined by the malicious HTTP request.
## Exploitation
- **Status:** PoC exists but is currently withheld by researchers; no confirmed exploitation in the wild reported at time of advisory.
- **Complexity:** High
- **Attack Vector:** Network (Remote, unauthenticated)
## Impact
- **Confidentiality:** High (Potential for heap memory disclosure/leaking uninitialized data).
- **Integrity:** High (Potential for Remote Code Execution if ASLR is bypassed).
- **Availability:** High (Can crash or restart worker processes, leading to Denial of Service).
## Remediation
### Patches
Update to the following versions or later:
- **NGINX Stable:** 1.30.4
- **NGINX Mainline:** 1.31.3
- **NGINX Plus:** 37.0.3.1
### Workarounds
- Transition affected regex maps to use **named captures** instead of numbered captures (e.g., use `(?<name>regex)` instead of `(regex)`).
- *Note:* Researchers warn this workaround may still be bypassable if the `map` defines the exact same named group as the location regex. Upgrading is the only complete fix.
## Detection
- **Indicators of Concern:** Look for NGINX configurations containing a `map` with regexes where the result is used in conjunction with variables like `$1` or `$2`.
- **Detection Methods:** Utilize the configuration scanner provided by the reporting researcher (cyberstan) to identify exploitable code patterns within `nginx.conf` and included files.
## References
- F5 Advisory: [https]://my.f5.com/manage/s/article/K000162097
- NGINX Security Advisories: [https]://nginx.org/en/security_advisories.html
- Researcher Writeup: [https]://cyberstan.co.uk/nginx-rce/
- Config Scanner: [https]://github.com/0xCyberstan/CVE-2026-42533-Config-Scanner