CVE-2026-42945 is a newly disclosed heap buffer overflow in the NGINX ngx_http_rewrite_module. The bug is serious because NGINX often sits at the public edge, but the practical exposure is narrower than a generic “all NGINX servers are exploitable” headline: the risky path requires an affected NGINX version and a specific rewrite-rule pattern using unnamed PCRE captures such as $1 or $2 with a replacement that contains a question mark [1].
DepthFirst, which reported the flaw, says the issue can let an unauthenticated attacker corrupt heap memory in a worker process with crafted HTTP requests. Its write-up lists NGINX Open Source 0.6.27 through 1.30.0, NGINX Plus R32 through R36, and several F5/NGINX-adjacent products as affected, with fixed Open Source releases at 1.30.1 and 1.31.0 [2]. NVD records F5’s CVSS v4.0 score as 9.2 and CVSS v3.1 as 8.1, while noting that the bug can restart workers and that code execution is possible on systems where ASLR is disabled [1].
How to Triage the Risk
The useful first check is not only nginx -v. Admins should also inspect whether the active configuration contains vulnerable rewrite rules. Plesk’s advisory gives the practical shape: versions below the fixed releases are risky when rewrite rules reference unnamed captures, and Linux systems should confirm ASLR with cat /proc/sys/kernel/randomize_va_space. A value of 2 means ASLR is enabled; 0 leaves the system closer to the RCE case [3].
For self-hosted sites, hosting panels, reverse proxies, and ingress deployments, the response sequence is: inventory exposed NGINX instances, update to a fixed build where available, restart workers after patching, and search configs for rewrite rules that combine numbered captures with query-string replacements. Where immediate patching is blocked, replacing numbered captures with named captures reduces the known trigger path. This is the same edge-service risk pattern Gridinsoft has covered in recent vulnerability stories such as Fortinet authentication-service RCE fixes, Cisco SD-WAN exploitation, and Linux root-access bugs: the vulnerable component is valuable because it sits close to traffic, credentials, or privileged infrastructure.
DepthFirst says it was not aware of in-the-wild exploitation at disclosure time [2]. That matters for prioritization: this is a patch-and-audit item, not evidence of an ongoing campaign. Still, public technical details and the commonness of NGINX make the configuration audit worth doing quickly, especially on shared hosting, reverse-proxy, CDN-adjacent, and Kubernetes ingress systems.
