A critical vulnerability in one of the world’s most deployed web servers is already drawing fire from threat actors, and defenders are running out of time to respond.
Tracked as CVE-2026-42945, the newly disclosed flaw affects both NGINX Open Source and NGINX Plus, enabling unauthenticated attackers to crash server worker processes or, under specific conditions, achieve remote code execution (RCE).
Security researcher Patrick Garrity of VulnCheck confirmed that exploitation attempts surfaced within days of the vulnerability’s public disclosure, a timeline that underscores how rapidly threat actors are now operationalizing newly released CVE data.
According to VulnCheck’s Initial Access team, attackers are delivering specially crafted HTTP requests designed to trigger a heap buffer overflow in the NGINX worker process. This class of memory corruption vulnerability can destabilize active services and, in edge cases, provide a foothold for full remote code execution.
Critically, no authentication is required to trigger the crash. “An unauthenticated attacker can crash the NGINX worker process,” VulnCheck noted in its advisory, making exposed deployments particularly attractive targets for opportunistic scanning campaigns.
Full RCE, however, is conditional. Successful code execution requires the target system to be running with Address Space Layout Randomization (ASLR) disabled, a configuration that, while uncommon in hardened environments, still exists in legacy and misconfigured deployments.
Additionally, exploitation depends on a specific rewrite rule configuration being active on the target server, which narrows the pool of truly exploitable systems.
Despite those constraints, the potential attack surface remains alarming. VulnCheck’s analysis, corroborated by Censys internet scanning data, identified approximately 5.7 million internet-facing NGINX servers running potentially affected versions.
Even if only a fraction of those meet the precise exploitation criteria, ASLR disabled and the vulnerable rewrite configuration enabled, the absolute number of at-risk systems could still reach into the hundreds of thousands.
Security experts emphasize that identifying exactly which servers are exploitable at scale is a significant challenge, both for defenders auditing their own assets and for attackers conducting mass reconnaissance.
Automated scanning tools have historically made that challenge easier for threat actors than for the organizations they target.
Mitigation
Organizations running NGINX should treat this vulnerability as a high-priority remediation item. Key steps include:
- Apply available patches immediately – updates for both NGINX Open Source and NGINX Plus have been released
- Audit rewrite rules in active configurations to identify and remove or harden any rules that could trigger the vulnerable code path
- Enable ASLR across all systems where it is not already active, as a critical mitigation layer.
- Monitor HTTP request logs for anomalous or malformed request patterns indicative of exploitation attempts
- Segment or restrict external access to NGINX instances that cannot be immediately patched
This incident is a textbook example of a recurring dynamic in modern cybersecurity: even vulnerabilities with narrow exploitation requirements carry outsized risk when the affected software underpins global infrastructure.
NGINX powers a significant portion of the world’s web traffic, and threat actors are well aware of its value as an initial access vector.
With active exploitation already confirmed and attacker automation continuing to accelerate, the window between vulnerability disclosure and weaponized attacks has effectively collapsed.
Rapid patching, continuous configuration auditing, and real-time traffic monitoring are no longer optional; they are the minimum standard for operational resilience.
No Comment! Be the first one.