Hackers are exploiting critical NGINX flaw CVE-2026-42945 in the wild

Attackers have started exploiting CVE-2026-42945, a critical heap buffer overflow vulnerability in NGINX Plus and NGINX Open Source, only days after public disclosure.

The flaw affects the ngx_http_rewrite_module and can be triggered by specially crafted HTTP requests when a server uses a vulnerable rewrite configuration. Successful exploitation can crash NGINX worker processes and cause denial of service.

Remote code execution is also possible in limited conditions, but it is harder to achieve on modern systems because ASLR is usually enabled by default. Security teams should still treat the bug as urgent because exploit attempts are already hitting exposed systems.

What is CVE-2026-42945?

CVE-2026-42945 is a heap-based buffer overflow in NGINX’s rewrite module. The bug appears when NGINX processes certain rewrite rules that use unnamed regular expression captures, such as $1 or $2, with a replacement string that contains a question mark.

The issue was publicly disclosed on May 13, 2026, alongside patches from F5 and NGINX. The vulnerability received a CVSS 4.0 score of 9.2 from F5, which places it in the critical range.

Depthfirst, the company credited with finding the issue, says the bug was introduced in NGINX 0.6.27 in 2008. That means the flaw remained in the codebase for roughly 18 years before discovery.

Detail	Information
CVE	CVE-2026-42945
Nickname	NGINX Rift
Affected component	ngx_http_rewrite_module
Bug class	Heap-based buffer overflow
Main impact	Worker-process crash and denial of service
Possible impact	Remote code execution under specific conditions
Authentication required	No

Active exploitation has already started

VulnCheck researcher Patrick Garrity said the company observed active exploitation of CVE-2026-42945 against VulnCheck canaries just days after the CVE was published.

The public activity shows how quickly attackers move after a serious web server flaw becomes known. NGINX sits at the edge of many websites, reverse proxies, application platforms, and cloud environments, which makes it an attractive target.

The exact goal of the observed exploitation is not fully clear. Based on the available technical details, defenders should expect scanning, crash attempts, and experiments against vulnerable rewrite configurations.

Why not every NGINX server is exploitable

The vulnerability does not affect every NGINX deployment simply because NGINX is installed. Attackers also need the target to use a specific rewrite configuration pattern.

The risky pattern involves an unnamed PCRE capture such as $1 or $2, a replacement string that contains a question mark, and a follow-up rewrite, if, or set directive in the same scope.

That limits the practical attack surface. However, VulnCheck said a Censys query found about 5.7 million internet-facing NGINX servers running potentially vulnerable versions, even though the truly exploitable number is likely much smaller.

• NGINX must run an affected version.
• The rewrite module must process a vulnerable rule pattern.
• The attacker must reach the vulnerable HTTP route.
• Denial of service is more realistic than reliable RCE on most systems.
• RCE becomes more realistic when ASLR is disabled or other weaknesses help bypass memory protections.

Affected and fixed NGINX versions

NGINX Open Source versions from 0.6.27 through 1.30.0 are listed as vulnerable. Fixed open-source versions are 1.30.1 and 1.31.0.

NGINX Plus releases R32 through R36 are also affected. F5 has released patched builds for supported NGINX Plus branches.

Several F5 and NGINX products built around NGINX may also need vendor-specific updates. Administrators should check F5’s advisory for NGINX Plus, NGINX Ingress Controller, NGINX Gateway Fabric, NGINX App Protect, and related products.

Product	Affected versions	Fixed versions
NGINX Open Source	0.6.27 through 1.30.0	1.30.1 or 1.31.0
NGINX Plus	R32 through R36	Patched builds from F5 for supported branches
NGINX Ingress Controller and related F5 products	Varies by product and branch	Check F5 product guidance

How the NGINX flaw works

The root problem sits in how NGINX calculates and copies rewritten URI data. In the vulnerable path, NGINX estimates the destination buffer using one set of escaping assumptions, then copies data using a different set.

When a crafted HTTP request reaches a vulnerable rewrite rule, attacker-controlled URI data can expand during copying and overflow the allocated heap buffer in the worker process.

In common scenarios, that crash restarts the worker and creates a denial-of-service condition. Turning the same bug into stable code execution requires more precise memory control and depends on the target environment.

Why ASLR changes the risk

Address Space Layout Randomization makes memory exploitation harder by changing where code and data live in memory. Most modern Linux distributions enable ASLR by default.

VulnCheck classified the public exploit path as denial of service because ASLR must be disabled for the available PoC to work as remote code execution.

That does not make the flaw safe to ignore. A reliable worker crash can still disrupt websites, APIs, reverse proxies, and application delivery systems. Attackers may also combine this bug with another weakness that leaks memory addresses.

What administrators should do now

Administrators should patch first. NGINX Open Source users should upgrade to 1.30.1 or 1.31.0 and restart NGINX so all workers load the patched binary.

Teams using NGINX Plus or F5 products should follow the product-specific guidance from F5. Environments running ingress controllers, API gateways, or load balancers based on NGINX should not assume they are safe until their vendor confirms the fix.

If patching cannot happen immediately, administrators should review rewrite rules and replace unnamed captures with named captures where the vulnerable pattern appears. They should also confirm ASLR remains enabled on all affected hosts.

1. Inventory NGINX Open Source, NGINX Plus, ingress, gateway, and WAF deployments.
2. Upgrade NGINX Open Source to 1.30.1 or 1.31.0.
3. Apply the relevant F5 patches for NGINX Plus and related products.
4. Restart or reload services so patched workers run.
5. Search configurations for risky rewrite patterns using $1, $2, and question marks.
6. Replace unnamed captures with named captures where needed.
7. Verify ASLR is enabled on Linux hosts.
8. Watch logs for unexpected worker crashes or repeated suspicious requests.

Why this matters for internet-facing infrastructure

NGINX often runs at the front of production infrastructure. It handles traffic before requests reach applications, APIs, Kubernetes services, and backend systems.

That position makes any unauthenticated NGINX bug especially important. Even when the immediate impact is denial of service, attackers can disrupt availability at the edge of a company’s network.

The rapid exploitation also shows how small the patching window has become. Once a public PoC and technical write-up appear, opportunistic attackers can start scanning within days.

FAQ