Hackers Actively Exploit ‘Nginx Rift’ Vulnerability Affecting NGINX, F5 Products

Hackers Actively Exploit ‘Nginx Rift’ Vulnerability Affecting NGINX, F5 Products

Hackers are actively exploiting the Nginx Rift vulnerability affecting NGINX and F5 products, exposing servers to denial-of-service attacks.

A newly discovered high-severity security flaw in F5’s NGINX web server software is already being targeted by hackers in the wild, just days after details went public. Tracked as CVE-2026-42945 and dubbed Nginx Rift, it carries a CVSS score of 8.1. Given that NGINX handles a huge chunk of internet traffic as a web server, load balancer, and reverse proxy, this exploitation is a cause of concern for the security community.

How the Nginx Rift Exploit Works

Discovered by researchers at Depthfirst using an AI-assisted detection platform, CVE-2026-42945 is a heap-based buffer overflow (CWE-122) found inside the ngx_http_rewrite_module and affects NGINX Open Source versions 0.6.27 through 1.30.0, NGINX Plus versions R32 through R36, and several tied-in F5 products, including the NGINX Ingress Controller and F5 WAF for NGINX.

Triggering the bug requires a rare combination of settings. A server administrator must have set up a rewrite directive followed immediately by a second rewrite, if or set directive, and the rule must use an unnamed regular expression capture group ($1 or $2) pointing to a replacement string with a literal question mark (?).

With this exact setup, an unauthenticated attacker can send a heavily manipulated web request to a server with a crafted Uniform Resource Identifier (URI) to confuse NGINX so that it makes a mistake in calculating the memory space needed for the request.

It would then use one set of rules for the size and another to write the data, forcing the system to write data past the edge of its allocated memory block, and if sent repeatedly, hackers can easily force the NGINX worker processes to crash over and over, eventually crashing the website in a denial-of-service (DoS) attack.

A Race Against Time

The situation escalated rapidly. Following the release of F5’s official security advisory alongside a public GitHub attack script on 13 May 2026, it took only three days for threat actors to respond. By 16 May, network honeypots and canary systems managed by cybersecurity firm VulnCheck flagged the first real-world attacks.

VulnCheck’s vulnerability researcher Patrick Garrity reported on social media, stating, “We’re seeing active exploitation of CVE-2026-42945 in F5 NGINX… on VulnCheck Canaries just days after the CVE was published.”

Exploitation timeline (source: Vulncheck)

Sizing Up the Actual Risk

A Censys query run by VulnCheck shows roughly 5.7 million web servers running potentially vulnerable NGINX versions, but the truly exploitable population is likely a tiny fraction of that.

To go beyond just crashing a site and achieve remote code execution (RCE), the device’s Address Space Layout Randomization (ASLR), a basic defence feature enabled by default in almost every OS, must be disabled.

“Our Censys query surfaces roughly 5.7M internet-exposed NGINX servers running a potentially vulnerable version, though the truly exploitable population is likely to be a much smaller subset of those. A public PoC is available, but the VulnCheck team classified it as a DoS given that ASLR must be disabled for the PoC to work,” VulnCheck’s team reports.

Security researcher Kevin Beaumont also shared a reality check on Mastodon, explaining that the public GitHub exploit code only works because it uses a command tool (setarch -R) to force ASLR off in a controlled lab environment.

“So, cool, sweet technical vuln – it’s valid – but the RCE apocalypse ain’t coming.”

Consequently, VulnCheck considers the recent exploitation mainly a DoS threat. So far, no specific malware families or known hacking groups have been linked to these attacks, either.

Reportedly, F5 has fixed the issue in NGINX Open Source versions 1.31.0 and 1.30.1, and NGINX Plus versions R36 P4 and R32 P6. Linux distributors for Ubuntu, Debian, and AlmaLinux have also started releasing fixes. For systems that cannot be updated immediately, F5 advises mitigating the flaw by changing configurations to use named captures instead of unnamed ones.

Experts’ Perspectives:

Several cybersecurity experts shared their insights on the situation with Hackread.com, offering guidance for defending networks against the flaw.

David Brumley, Chief AI and Science Officer at Bugcrowd, warned against relying too heavily on operating system defenses, calling it “a very serious vulnerability in an often publicly-exposed piece of software”. Brumley stated that the right security stance is to “assume it’s only a matter of time before a weaponized exploit appears” and advised businesses to “patch right away.”

He also criticized the NIST CVE overview as “essentially misleading” for stating the flaw is only exploitable without ASLR, noting that “defenses like ASLR only mean it takes more time and effort to create a weaponized exploit, not that it cannot be done.”

Providing a technical look at the target area, Mayuresh Dani, Security Research Manager at Qualys Threat Research Unit, noted that the impacted module “lets you rewrite or redirect URIs on the fly using regular expressions.”

Dani clarified that while code execution requires specific settings, “a denial-of-service is trivial in such conditions and a single crafted request has the potential to reliably crash the targeted worker process.” He recommended that organizations immediately “audit all NGINX instances, including Kubernetes ingress controllers, containers, etc., for vulnerable versions.”

Jason Soroko, Senior Fellow at Sectigo, agreed that the immediate threat is operational. “The primary threat from CVE-2026-42945 involves a heap buffer overflow in the rewrite module, which allows attackers to crash worker processes through manipulated HTTP requests,” Soroko said.

He concluded that “the actual danger for most organizations is a denial of service condition that halts web traffic rather than a full server compromise,” urging security teams to treat the DoS risk with high priority and apply updates.

Deeba is a veteran cybersecurity reporter at Hackread.com with over a decade of experience covering cybercrime, vulnerabilities, and security events. Her expertise and in-depth analysis make her a key contributor to the platform’s trusted coverage.
Leave a Reply

Your email address will not be published. Required fields are marked *

Related Posts