What happened
Active exploitation of a critical NGINX vulnerability tracked as CVE-2026-42945 and dubbed Nginx Rift has been confirmed by VulnCheck, just days after F5 released patches and PoC code was published. The vulnerability, a heap buffer overflow in the ngx_http_rewrite_module component, carries a CVSS score of 9.2 and had been present in NGINX code for 16 years.
The flaw exists because NGINX’s script engine uses a two-pass process to calculate buffer size and copy data, and the internal engine state changes between these passes. In certain conditions, an unpropagated flag results in attacker-supplied data being written past the heap boundary. Exploitation requires no authentication and can be triggered remotely via crafted HTTP requests, but does require a specific rewrite configuration to be exploitable.
On default deployments with ASLR enabled, successful exploitation crashes the NGINX worker process and triggers a server restart, causing a denial-of-service condition. If ASLR is disabled, the vulnerability enables remote code execution. Security researchers have warned that public PoC code can be used to disable ASLR and achieve RCE, raising concern about broader exploitation capability. VulnCheck identified approximately 5.7 million internet-exposed NGINX servers running potentially vulnerable versions through Censys, though the truly exploitable population is assessed as a smaller subset given the rewrite configuration requirement.
Who is affected
Organizations running NGINX Plus and NGINX Open Source on vulnerable versions with internet-exposed instances and rewrite configurations are directly exposed. The 5.7 million potentially vulnerable instances identified by VulnCheck represents a broad attack surface across web servers, reverse proxies, and load balancers running NGINX globally.
Why CISOs should care
Nginx Rift follows the now-familiar pattern of rapid exploitation following PoC publication. The flaw sat undetected for 16 years, was patched, had PoC code published within days, and exploitation began almost immediately. The DoS impact on default configurations is immediately relevant for any organization where NGINX availability is business-critical, while the RCE potential on systems with ASLR disabled represents a higher-severity risk for legacy or misconfigured deployments.
With 5.7 million potentially vulnerable internet-exposed instances and active exploitation already confirmed, the window for proactive patching ahead of broad opportunistic attacks is narrow.
3 practical actions
- Patch NGINX Plus and NGINX Open Source immediately to the versions released by F5 last week: Active exploitation is confirmed and PoC code is public. Treat this as an emergency patch regardless of whether your rewrite configuration is currently known to be exploitable, as configuration audits should not delay patching.
- Audit NGINX rewrite configurations across your environment to assess exploitability: The vulnerability requires a specific rewrite configuration to trigger. Identify all NGINX instances using ngx_http_rewrite_module directives and prioritize those for immediate patching, while ensuring all instances receive the patch regardless of current configuration.
- Confirm ASLR is enabled on all systems running NGINX: ASLR is the primary mitigation against RCE escalation from this vulnerability. Verify that ASLR is enabled at the operating system level on all servers running NGINX, and treat any instance with ASLR disabled as a critical patching priority given the confirmed RCE potential in that configuration.
John Kevin Hao is a news and feature writer covering cybersecurity, technology, and business targeted for professional audiences.