Critical NGINX Vulnerability CVE-2024-35200 Allows Remote Code Execution
Key Takeaways A critical pre-authentication remote code execution (RCE) vulnerability, CVE-2024-35200, has been discovered in NGINX. The flaw has been present in NGINX’s script engine since...
Key Takeaways
- A critical pre-authentication remote code execution (RCE) vulnerability, CVE-2024-35200, has been discovered in NGINX.
- The flaw has been present in NGINX’s script engine since March 2011, affecting nearly all versions.
- It allows attackers to achieve reliable RCE through a combination of information leaks and heap buffer overflows.
- Patches are available for NGINX Open Source (1.30.4 stable, 1.31.3 mainline) and NGINX Plus (R36 P7, 37.0.3.1).
Long-Standing NGINX Vulnerability Enables Remote Code Execution
A severe pre-authentication remote code execution (RCE) vulnerability, identified as CVE-2024-35200, has been uncovered in NGINX. This critical flaw, rooted in the server’s internal script engine, has been exploitable since March 2011, coinciding with the introduction of regex support for the map directive.
Table Of Content
Security researcher Stan Shaw brought the issue to the attention of F5 SIRT. Their coordinated efforts led to the release of official fixes. NGINX Open Source versions 1.30.4 (stable) and 1.31.3 (mainline) now include the patch. For NGINX Plus users, the vulnerability is addressed in R36 P7 (for R33–R36 releases) and 37.0.3.1 (for 37.0.0.1–37.0.2.1 releases).
Technical Details of the Flaw
The core of CVE-2024-35200 lies in NGINX’s internal script engine, specifically a failure to properly save and restore the PCRE (Perl Compatible Regular Expressions) capture state. NGINX processes expressions in two distinct passes: a “LEN” pass to determine the required buffer size and a “VALUE” pass to write the actual data. Both passes rely on a shared, mutable array known as r->captures.
When a map directive utilizing a regex pattern executes between two references to a capture group (e.g., $1), it inadvertently overwrites this shared state. This silent alteration leads to a discrepancy between the buffer size calculated during the LEN pass and the data length during the VALUE pass.
This mismatch creates two critical attack primitives:
- Heap Buffer Overflow: If the altered capture group is larger than its original size, the VALUE pass attempts to write more data than the allocated buffer can hold. This results in a heap buffer overflow, allowing an attacker to corrupt adjacent heap memory with arbitrary, attacker-controlled content.
- Information Leak: Conversely, if the altered capture is smaller, the buffer becomes oversized. The response then leaks uninitialized heap bytes, which can include crucial libc and heap pointers. Such information is sufficient to bypass Address Space Layout Randomization (ASLR) in a single, unauthenticated GET request.
By chaining these two primitives, an attacker can reliably achieve RCE. The exploit chain, demonstrated with 10/10 reliability on Ubuntu 24.04 with full ASLR, typically involves one information leak request, approximately 40 “spray” connections, and a final request to trigger the overflow.
According to the Cyberstan report, this vulnerability is not confined to a single directive. It impacts at least 13 independent call sites across nine source files, affecting both HTTP and stream modules. Any NGINX configuration that combines a regex capture source (such as location, server_name, rewrite, or if blocks) with a regex-based map variable evaluated subsequently within the same request context is potentially exploitable. This even applies when these elements are in separate directives within the same location block.
Commonly affected directives include, but are not limited to:
proxy_set_header,proxy_method,proxy_pass,fastcgi_param,uwsgi_param,scgi_paramgrpc_set_header,return,add_header,rewrite,setroot,alias,access_log, and various others.
An additional, independently exploitable variant exists for named capture groups (e.g., (?P...)). These are cached differently and will not be remediated by patches solely addressing numbered captures.
Affected Versions
The scope of affected NGINX versions is extensive, given the vulnerability’s long gestation period:
| Product | Affected Versions | Fixed Version |
|---|---|---|
| NGINX Open Source (stable) | 0.9.6 through 1.30.3 | 1.30.4 |
| NGINX Open Source (mainline) | up to 1.31.2 | 1.31.3 |
| NGINX Plus | R33–R36 | R36 P7 |
| NGINX Plus (newer line) | 37.0.0.1–37.0.2.1 | 37.0.3.1 |
It is important to note that recent patches for other NGINX vulnerabilities, including CVE-2026-42945, CVE-2026-9256, CVE-2026-42055, and CVE-2026-48142, do not address this specific issue. Organizations that applied those fixes may still be exposed to CVE-2024-35200.
Intriguingly, this precise behavior was first identified over a decade ago in a 2014 NGINX trac ticket. While developer Maxim Dounin acknowledged it as a defect at the time, it was never fully recognized or remediated as a critical security vulnerability.
To assist defenders, the researcher has made a static configuration scanner available on GitHub (0xCyberstan/CVE-2026-42533-Config-Scanner). This tool can identify vulnerable directive orderings without active exploitation, providing immediate visibility into potential exposure. The full proof-of-concept and exploitation write-up will be withheld for 21 days following the patch release to allow administrators sufficient time to update, a decision influenced by the rapid weaponization observed after CVE-2026-42945 (“NGINX Rift”) became public.
What You Should Do
- Upgrade Immediately: Update NGINX Open Source installations to versions 1.30.4 (stable) or 1.31.3 (mainline). NGINX Plus users should upgrade to R36 P7 or 37.0.3.1, respectively.
- Utilize the Scanner: Run the provided static configuration scanner against all production NGINX configurations to identify and remediate vulnerable directive orderings.
- Review Configurations: Conduct a thorough audit of any
locationblocks that combine regex captures with regex-basedmapvariables. Restructure these configurations to prevent capture references from appearing before or after themapvariable evaluation. - Prioritize Remediation: Treat this vulnerability as urgent, even if your deployment does not utilize HTTP/3 or other modules recently addressed by separate patches, as this flaw is independent of those fixes.
Disclaimer: HackersRadar reports on cybersecurity threats and incidents for informational and awareness purposes only. We do not engage in hacking activities, data exfiltration, or the hosting or distribution of stolen or leaked information. All content is based on publicly available sources.



No Comment! Be the first one.