A new high-severity NGINX vulnerability, CVE-2026-42945, has been disclosed in the ngx_http_rewrite_module, the module responsible for handling rewrite logic in NGINX configurations.
The issue is a heap buffer overflow that can be triggered remotely under specific configuration conditions. The most likely impact is an NGINX worker crash and restart, which can lead to denial of service. Possible remote code execution, or RCE, has also been noted for systems where Address Space Layout Randomization, or ASLR, is disabled.
F5, the CNA for this vulnerability, rates it CVSS 3.1: 8.1 High. The issue affects both NGINX Open Source and NGINX Plus, making it a high-priority item for security and infrastructure teams.
Why This Matters
NGINX is widely deployed as a web server, reverse proxy, load balancer, API gateway component, Kubernetes ingress controller, and front door for application traffic.
That broad deployment footprint makes any remotely reachable NGINX vulnerability worth immediate attention. However, CVE-2026-42945 is not a universal "every NGINX server is exploitable" issue. Exploitation appears to depend on specific rewrite-module configurations.
That distinction matters. The risk is serious, but it is also configuration-dependent.
What Triggers the Vulnerability
The vulnerable condition involves certain rewrite-module rules that use unnamed regular-expression captures, such as $1 or $2, together with replacement strings that contain a question mark.
The issue can occur when a rewrite directive is followed by another rewrite, if, or set directive, and the rewrite logic processes those unnamed captures in the affected way.
In plain English, the risky pattern involves rewrite logic that captures part of a request URL using regular expressions, then reuses those captured values through numbered references like $1 or $2, while also handling a replacement target that includes a question mark.
Not every rewrite rule is vulnerable. Not every use of $1 or $2 is automatically dangerous. The concern is the specific combination of rewrite processing, unnamed captures, and question-mark handling.
What an Attacker Can Do
An unauthenticated attacker may be able to send crafted HTTP requests that hit the vulnerable rewrite path.
If the server configuration matches the vulnerable pattern, this can cause a heap buffer overflow in the NGINX worker process. In practical terms, that may cause the worker process to crash and restart.
Repeated crashes can create a denial-of-service condition, especially on busy internet-facing systems. In environments where ASLR is disabled, the same memory-corruption issue may also allow remote code execution.
That possible RCE angle is important, but it should be described carefully. Based on the current disclosure, RCE is not presented as the default outcome for all affected systems. It depends on both vulnerable configuration conditions and weakened memory-protection settings.
Who Should Be Concerned
Security teams should prioritize review of internet-facing NGINX servers, reverse proxies, load balancers, Kubernetes ingress controllers, and NGINX Plus deployments.
Application stacks that include NGINX as a bundled or embedded component should also be checked. This includes platforms, appliances, container images, and ingress components that may not be managed like a traditional standalone web server.
Legacy systems deserve extra attention, especially if hardening settings have been weakened over time or if ASLR status is unknown.
Immediate Action Items
Start by inventorying all public-facing NGINX deployments. Include production, staging, disaster recovery, cloud, containerized, and appliance-based deployments.
Then audit rewrite-module usage. Look for rewrite logic that uses unnamed captures such as $1, $2, and similar numbered references, especially when the replacement behavior includes query-string handling with a question mark.
Verify that ASLR is enabled on the underlying systems. ASLR is not a substitute for patching, but it is an important mitigation against memory-corruption exploitation.
Finally, upgrade affected NGINX Open Source and NGINX Plus deployments to patched versions as soon as possible. Systems that are internet-facing or process untrusted traffic should be treated as the highest priority.
Detection and Monitoring
While patching should be the main response, monitoring can help identify suspicious activity or possible exploitation attempts.
Watch for unexpected NGINX worker crashes, frequent restarts, abnormal spikes in 5xx errors, and unusual request patterns targeting rewritten URLs. Pay special attention to endpoints that rely on complex rewrite behavior or legacy URL routing.
Teams using centralized logging should review recent traffic to paths handled by rewrite-heavy server blocks. Infrastructure teams should also check process supervision logs, container restart counts, system logs, and ingress-controller health events.
What Not to Rely On
Do not rely only on perimeter filtering. Because this issue is tied to normal HTTP request processing, a crafted request may look like regular web traffic.
Do not assume internal NGINX instances are safe if they receive traffic from untrusted users, partner networks, internal apps, or compromised systems.
Do not treat ASLR as a complete fix. ASLR reduces exploitability, especially for code execution, but it does not remove the underlying heap buffer overflow.
Do not delay patching just because exploitation is configuration-dependent. Configuration-dependent vulnerabilities can still be highly impactful when they affect widely deployed software.
Bottom Line
CVE-2026-42945 is a serious NGINX rewrite-module vulnerability affecting both NGINX Open Source and NGINX Plus. The most likely impact is denial of service through worker crashes and restarts. Possible RCE is also a concern on systems where ASLR is disabled.
The vulnerability appears to require specific rewrite-rule patterns, so not every deployment is equally exposed. Still, because NGINX is so widely used and often internet-facing, teams should treat this as urgent.
Audit exposed NGINX instances, review rewrite rules, confirm ASLR, and upgrade to patched versions as soon as possible.
Sources: - NVD: CVE-2026-42945