CVE-2026-42945, also known as NGINX Rift, is a critical heap-based buffer overflow affecting broad NGINX Open Source and NGINX Plus versions. Public PoC exploit code is available, and exploitation attempts have been reported within days of disclosure.
The vulnerability affects configurations using the [ngx_http_rewrite_module], particularly when a rewrite directive uses unnamed captures such as $1 or $2, includes a replacement string containing ?, and is followed by another rewrite, if, or set directive.
Denial-of-Service is currently the most reliable impact. Remote Code Execution has been demonstrated only under constrained conditions, especially where ASLR is disabled or otherwise defeated. The right response is not panic, but rapid patching, configuration auditing, exposure reduction, and layered endpoint controls.
NGINX Rift CVE-2026-42945 is one of the most widely deployed web infrastructure components, used as a reverse proxy, load balancer, API gateway, and Kubernetes ingress layer. That makes CVE-2026-42945 important even though not every NGINX server is exploitable.
The vulnerability affects NGINX Open Source 0.6.27 through 1.30.0 and NGINX Plus R32 through R36. F5 assigned CVE-2026-42945 a CVSS v4.0 score of 9.2 Critical, although nginx.org’s security advisory page lists the issue severity as medium. NVD enrichment remains pending.
However, exploitation depends on a specific configuration pattern. A server is at risk only when vulnerable versions use rewrite rules involving unnamed captures, a replacement string containing ?, and subsequent rewrite, if, or set directives.
That nuance matters. Reports estimate millions of internet-exposed NGINX servers may be running potentially affected versions, but the truly exploitable subset is likely much smaller because the risky rewrite pattern must be present.
The issue sits in NGINX’s rewrite processing logic, specifically around how replacement strings are measured and copied.
NGINX Rift CVE-2026-42945 uses a two-pass flow. First, it calculates the memory needed for the processed rewrite string. Then, it performs the actual substitution and copy operation.
The vulnerability appears when an internal argument-handling state leaks between these steps. If the rewrite logic uses unnamed captures and a trailing question mark, NGINX Rift CVE-2026-42945 may incorrectly treat later replacement data as needing URI escaping during the copy phase.
For example, a character like + may be expanded into %2B. The first pass may allocate memory for one byte, while the second pass writes three bytes. This creates a heap buffer overflow.
Because attacker-controlled URI data can influence the copied content, repeated malicious requests can crash worker processes and create a sustained Denial-of-Service condition. RCE is more difficult and depends on favorable memory-layout conditions, but it remains within the potential impact range under weakened host protections.
Why this matters to enterprise teams
NGINX often sits in front of sensitive systems. It may terminate TLS, route authentication traffic, protect APIs, or direct traffic into internal applications and Kubernetes services. When the ingress layer becomes the weak point, downstream infrastructure can inherit the risk.
Separately, the retirement of the Kubernetes community ingress-nginx controller increases migration pressure for Kubernetes teams. This should not be confused with the NGINX web server itself or F5’s NGINX Ingress Controller, but it reinforces the need to treat ingress components as continuously governed infrastructure.
The key lesson is simple: trusted middleware still needs continuous verification. Network firewalls, WAFs, and perimeter tools can reduce risk, but they should not be the only line of defense. Teams need visibility into versions, configurations, host posture, and suspicious runtime behavior.
How Hexnode helps reduce exposure
Hexnode supports a practical, operations-first response to vulnerabilities like CVE-2026-42945 by helping IT and security teams centralize endpoint visibility, run audits, and enforce access controls.
Hexnode UEM for fleet discovery and configuration audits
During a zero-day event, the first challenge is knowing where vulnerable software exists. Hexnode UEM can help administrators deploy custom scripts across managed systems to identify NGINX versions, installed packages, and risky configuration patterns.
For example, admins can inspect runtime versions using commands such as:
Bash
1
nginx-v
They can also audit NGINX configuration directories for rewrite-related patterns:
Bash
1
grep-RInE'rewrite|set |\$[0-9]|if \('/etc/nginx
This does not replace expert review, but it accelerates triage across distributed environments.
Where immediate patching is not possible, Hexnode UEM can support controlled remediation workflows. For instance, administrators may replace unsafe unnamed captures with named captures where recommended by vendor guidance. These changes should always be tested before production rollout, because rewrite logic is often tied directly to application routing.
Hexnode IdP for identity-aware access control
Reducing unnecessary exposure is one of the strongest compensating controls for ingress-layer vulnerabilities. Hexnode IdP helps organizations tie access decisions to verified users, compliant devices, and security context.
This is especially useful for administrative portals, internal applications, and management interfaces that should not be reachable by unauthenticated internet traffic. By enforcing conditional access, organizations can reduce attack surface while maintaining legitimate access for trusted users and managed devices.
Hexnode XDR for investigation and response
Hexnode XDR can support investigation and remediation on supported endpoints by detecting suspicious process, file, and network activity, and by enabling actions such as process termination, file quarantine, and endpoint isolation.
For NGINX Rift-style incidents, teams should monitor NGINX/server logs and SIEM telemetry for repeated worker crashes, malformed URI traffic, suspicious child processes, and abnormal outbound connections. Hexnode XDR can assist with endpoint investigation and containment on supported platforms.
Featured Resource
Introduction to Hexnode XDR
Upgrade your security stance with the advanced capabilities of Hexnode XDR
Organizations should upgrade affected NGINX versions to fixed releases as soon as possible. In parallel, teams should audit rewrite configurations for the vulnerable pattern. They should also limit direct exposure of sensitive ingress and management systems. Host hardening controls such as ASLR should also be reviewed.
Security teams should monitor for signs of exploitation. These include repeated NGINX worker crashes, malformed URI traffic, unexpected process spawning, and suspicious network activity from NGINX systems.
NGINX is also embedded in related products such as NGINX Ingress Controller, Gateway Fabric, WAF, DoS, and Instance Manager. Teams should verify product-specific exposure and fixed versions using F5 advisories.
Conclusion
CVE-2026-42945 is a reminder that widely deployed infrastructure components can still contain high-impact flaws. The risk is not limited to the web server itself; it extends to the applications, APIs, identities, and internal services behind it.
Enterprises should treat ingress infrastructure as a continuously governed asset. That means knowing where it runs, what version it uses, how it is configured, who can reach it, and how it behaves under attack.
Hexnode helps strengthen that operating model by bringing endpoint visibility, script-driven audits, conditional access, and endpoint response into a unified management workflow. With the right controls in place, organizations can reduce exposure, respond faster, and keep critical infrastructure from depending on implicit trust alone.
Secure Your Endpoints with Hexnode
Gain visibility, control, and faster response across critical systems.
Is every NGINX server vulnerable to CVE-2026-42945?
No. Exploitation requires specific rewrite-module configurations involving unnamed regex captures, trailing question marks, and chained rewrite-related directives.
Why is an ingress-layer vulnerability so serious?
Ingress and reverse proxy systems sit in front of critical applications and APIs, making them high-value targets for outages, traffic interception, and lateral movement attempts.
Content writer at Hexnode. Fueled by good coffee and the occasional cat cuddle, I enjoy crafting content that informs, connects, and resonates. Nothing excites me more than knowing my words have been read, appreciated, and maybe even bookmarked.
