CVE-2026-42945 has moved from fresh disclosure to active exploitation in days, which is exactly why defenders should treat it as an immediate NGINX exposure review rather than a routine web stack update. The flaw, also dubbed NGINX Rift, affects the ngx_http_rewrite_module and can let an unauthenticated attacker crash worker processes with crafted HTTP requests.
The remote code execution path is narrower than the denial-of-service path because it depends on both a vulnerable rewrite pattern and ASLR being disabled. Still, that is not a reason to relax. NGINX sits in front of a huge share of internet-facing applications, and the easier crash path alone is enough to make this a meaningful vulnerability management problem for exposed environments.
What happened
NGINX lists CVE-2026-42945 as a buffer overflow in the ngx_http_rewrite_module, with vulnerable versions spanning 0.6.27 through 1.30.0 and fixed versions starting at 1.30.1 and 1.31.0. DepthFirst’s disclosure says the bug has been present for roughly 18 years, while NVD describes the trigger as a rewrite chain where an unnamed PCRE capture such as $1 or $2 is used in a replacement string containing a ?, followed by another rewrite, if, or set directive.
That combination creates a size mismatch between the length calculation and the actual copy operation. In practical terms, attacker-controlled URI data can overflow the destination buffer in the NGINX worker process. On many systems that means a crash and worker restart. On systems where ASLR is disabled, code execution becomes possible.
Over the weekend, VulnCheck reported in-the-wild exploitation against its canary infrastructure. SecurityWeek says the observed attacks began only days after public disclosure and public proof-of-concept release, which fits the pattern defenders keep seeing with high-visibility infrastructure bugs: once the trigger conditions are understood, scanning and opportunistic weaponization follow quickly.
Why this matters operationally
This is not a generic “all NGINX servers are instantly RCE’d” story, and pretending otherwise would be sloppy. Exploitability depends on configuration. But the operational risk is still serious for three reasons.
1. The bug is internet-reachable and unauthenticated
Attackers do not need credentials or prior foothold to test exposed targets. If a vulnerable rewrite chain is present, a single crafted request can trigger the overflow path.
2. The easier impact is still disruptive
Even when reliable remote code execution is not available, the worker-crash path can cause a denial-of-service condition. For public applications, login flows, APIs, and reverse proxies, that alone can become an incident response problem.
3. NGINX often protects higher-value backends
NGINX is rarely the crown jewel by itself. It usually fronts applications, identity paths, API gateways, PHP backends, and internal services. That means any successful exploit against the edge can create a route toward deeper application compromise, log tampering, credential capture, or lateral movement.
What defenders should check now
1. Identify affected versions first
Start by finding internet-facing NGINX assets running versions in the affected range. NGINX says fixed releases begin at 1.30.1 and 1.31.0. If you run NGINX Plus or platform products built on NGINX, validate the relevant vendor guidance as well.
2. Review rewrite rules, not just package versions
The dangerous pattern is not “NGINX exists.” It is a specific rewrite configuration. Pay special attention to:
- unnamed captures like
$1,$2, and similar - replacement strings containing
? - chained
rewrite,if, orsetdirectives in the same scope - older front-controller patterns used by PHP apps, CMS platforms, and custom routing logic
AlmaLinux notes that the vulnerable pattern is common enough in real-world configurations to justify patching even if you have not yet confirmed a bad rule.
3. Patch and restart workers
Upgrading the package is not enough if workers are still running the old binary. Make sure the deployment path includes a clean NGINX restart or controlled reload that actually puts the fixed version into service.
4. Hunt for crash patterns and odd HTTP probing
The most practical detection path is sudden worker crashes, restarts, or repeated malformed requests aimed at rewrite-heavy routes. Example log sources to check:
error.logfor worker exits, signal events, or abnormal restarts- reverse proxy access logs for repeated crafted URIs with unusual metacharacters
- container or orchestrator logs for restart spikes
- WAF and edge telemetry for concentrated probing against dynamic route patterns
Example Splunk pattern:
splindex=nginx sourcetype=nginx:error ("worker process" AND (exited OR crashed OR restart)) | bin _time span=15m | stats count by host, _time | where count > 3
Example Sentinel KQL pattern:
kqlSyslog | where ProcessName has "nginx" | where SyslogMessage has_any ("worker process", "signal", "exited", "segfault", "restart") | summarize Events=count() by Computer, bin(TimeGenerated, 15m) | where Events > 3
Temporary mitigation if patching is delayed
If a production constraint blocks immediate patching, the best short-term mitigation is to rewrite vulnerable rules so they stop using unnamed captures in the affected pattern. DepthFirst and AlmaLinux both highlight the same safer direction: replace $1, $2, and similar constructs with named captures.
Vulnerable pattern:
nginxrewrite ^/users/([0-9]+)/profile/(.*)$ /profile.php?id=$1&tab=$2 last;
Safer pattern:
nginxrewrite ^/users/(?<user_id>[0-9]+)/profile/(?<section>.*)$ /profile.php?id=$user_id&tab=$section last;
That should be treated as a bridge, not a substitute for a real update.
Strategic takeaway
CVE-2026-42945 deserves priority because it combines internet reachability, public technical detail, public PoC coverage, and confirmed exploitation activity. Even if your environment is not an easy RCE target, the crash path is simple enough to matter and the affected software footprint is broad enough to justify urgent review.
For defenders, the right response is straightforward:
- patch to a fixed NGINX release
- validate whether rewrite chains expose the vulnerable pattern
- restart services cleanly after upgrade
- monitor for worker crashes and hostile URI probing
- treat exposed edge systems as higher-priority than ordinary middleware
What is CVE-2026-42945?
It is a heap buffer overflow in NGINX’s ngx_http_rewrite_module. Under the right rewrite-chain conditions, an unauthenticated attacker can crash worker processes and, in less common hardening states, potentially achieve remote code execution.
Which NGINX versions are affected?
NGINX says affected open source versions span 0.6.27 through 1.30.0. Fixed versions start at 1.30.1 and 1.31.0.
Is the bug being exploited in the wild?
Yes. VulnCheck reported observing exploitation activity against canary infrastructure, and SecurityWeek says those attacks started over the weekend following disclosure.
Does every exposed NGINX server have the same risk?
No. The vulnerable path depends on a specific rewrite configuration. But that does not reduce the urgency of exposure review because the crash path is still serious and the risky rewrite style is common.
What should defenders do first?
Identify affected NGINX versions, patch quickly, review rewrite rules for the vulnerable pattern, restart services cleanly, and investigate crash or probing telemetry around exposed web assets.
