18-Year-Old NGINX Flaw Now Targeted After PoC Release

Attackers have started targeting CVE-2026-42945, an 18-year-old NGINX vulnerability that can crash vulnerable servers and may allow remote code execution in certain environments.

The flaw affects the NGINX rewrite module and sits in code introduced in 2008. It impacts NGINX Open Source versions 0.6.27 through 1.30.0 and NGINX Plus R32 through R36.

F5 and NGINX fixed the issue in NGINX Open Source 1.30.1 and 1.31.0. Administrators should patch quickly, restart NGINX workers, and check whether their configurations use the risky rewrite pattern.

What CVE-2026-42945 is

CVE-2026-42945 is a heap buffer overflow in ngx_http_rewrite_module, the NGINX module used for URL rewrites, conditional routing, and variable handling.

The issue occurs when a rewrite directive uses an unnamed PCRE capture, such as $1 or $2, with a replacement string that includes a question mark. The risky pattern also requires a following rewrite, if, or set directive in the same context.

An unauthenticated attacker can trigger the flaw by sending crafted HTTP requests to a vulnerable NGINX route. In practical terms, the most reliable impact is denial of service through worker process crashes. Code execution is possible when ASLR is disabled.

Item	Details
CVE	CVE-2026-42945
Nickname	NGINX Rift
Component	ngx_http_rewrite_module
Weakness type	Heap-based buffer overflow
CVSS v4.0	9.2 Critical
CVSS v3.1	8.1 High
Main impact	Worker crash, denial of service, and possible code execution when ASLR is disabled
Patched Open Source versions	NGINX 1.30.1 and 1.31.0

Why this NGINX flaw matters

NGINX often sits at the public edge of websites, APIs, reverse proxies, Kubernetes ingress setups, and load-balancing environments. That makes any remotely reachable memory corruption issue a high-priority patching concern.

The vulnerable code path does not affect every NGINX configuration equally. Servers need a specific rewrite pattern before an attacker can trigger the bug.

However, that condition does not make the issue safe to ignore. URL rewriting is common in API gateways, application routing, migration rules, and reverse proxy setups.

How the bug works

The vulnerability comes from a mismatch in how NGINX calculates buffer size and later writes rewritten URI data into memory.

When the vulnerable rewrite pattern appears, NGINX can calculate a destination buffer using one set of assumptions, then copy data using another. That can cause attacker-controlled URI data to write beyond the allocated heap buffer.

Repeated requests can crash worker processes and degrade availability. Depthfirst researchers also released a proof-of-concept showing remote code execution under controlled conditions with ASLR disabled.

• The attacker does not need authentication.
• The attacker sends crafted HTTP requests to a vulnerable route.
• The server must use the affected rewrite configuration pattern.
• Denial of service is the clearest real-world risk.
• Remote code execution depends on additional conditions, including ASLR being disabled.

Exploitation attempts have started

The risk increased after technical details and proof-of-concept exploit code became public. Security reporting now says exploitation attempts began on May 16, 2026, shortly after disclosure.

That does not mean every vulnerable NGINX server can be exploited for code execution. Attackers still need the right configuration and environment.

Even so, public exploit activity changes the urgency. Organizations should move from assessment to patching and detection, especially for internet-facing servers.

Affected and fixed versions

The main affected range is broad because the vulnerable code has existed for years. NGINX’s advisory page lists NGINX Open Source 0.6.27 through 1.30.0 as vulnerable and 1.30.1 or 1.31.0 as fixed.

NGINX Plus R32 through R36 are also affected. F5 fixed the issue in supported NGINX Plus updates, including R36 P4 and R32 P6.

F5 products that embed NGINX may also need updates. These include NGINX Ingress Controller, F5 WAF for NGINX, F5 DoS for NGINX, and related NGINX application delivery products.

Product area	Affected versions or scope	Fixed version or action
NGINX Open Source	0.6.27 through 1.30.0	Upgrade to 1.30.1 or 1.31.0
NGINX Plus	R32 through R36	Apply the relevant fixed Plus release or patch
F5 WAF for NGINX	Versions using affected NGINX code	Upgrade to a fixed F5 release
F5 DoS for NGINX	Versions using affected NGINX code	Upgrade to a fixed F5 release
NGINX Ingress Controller	Versions using affected NGINX code	Apply vendor guidance and patched builds

Other NGINX flaws fixed in the same release wave

CVE-2026-42945 was not the only NGINX memory safety issue disclosed in the same period. Depthfirst said its analysis also helped identify several additional flaws.

Security teams should patch and triage these together because they affect NGINX request handling, upstream handling, SSL behavior, and response processing.

Administrators should not focus only on the rewrite module. A complete update cycle reduces exposure to the wider set of NGINX security fixes released in the same window.

CVE	Component	Impact
CVE-2026-42945	ngx_http_rewrite_module	Heap buffer overflow, worker crash, possible code execution with ASLR disabled
CVE-2026-42946	ngx_http_scgi_module and ngx_http_uwsgi_module	Excessive memory allocation or over-read in certain upstream response conditions
CVE-2026-40701	ngx_http_ssl_module	Heap use-after-free when specific client certificate and OCSP settings are enabled
CVE-2026-42934	ngx_http_charset_module	Heap buffer over-read that can disclose limited memory or restart the worker process

What administrators should do now

The safest response is to upgrade NGINX to a fixed version through an approved package source or vendor release. After upgrading, restart NGINX so running worker processes load the patched binary.

Teams should also review rewrite rules. The highest-risk pattern includes unnamed captures, a replacement string containing a question mark, and another rewrite, if, or set directive that follows in the same context.

Where immediate patching is not possible, administrators should replace unnamed captures with named captures where applicable and reduce exposure for affected routes until updates can be applied.

1. Inventory all internet-facing NGINX and NGINX-based products.
2. Check the running version with nginx -v or your package manager.
3. Upgrade NGINX Open Source to 1.30.1 or 1.31.0 where applicable.
4. Apply the relevant NGINX Plus or F5 product patch.
5. Restart NGINX after patching to reload worker processes.
6. Export the full configuration with nginx -T for review.
7. Search for rewrite rules that use $1, $2, or other unnamed captures.
8. Look for rewrite replacements that include a question mark.
9. Replace risky unnamed capture patterns with safer named captures when needed.
10. Monitor for repeated worker crashes or suspicious HTTP requests hitting rewrite-heavy routes.

Detection and monitoring guidance

Security teams should review error logs, access logs, reverse proxy logs, and endpoint telemetry for unusual worker crashes after crafted HTTP requests.

Repeated crashes from similar request paths can signal probing or denial-of-service attempts. Since proof-of-concept code is public, scanning and opportunistic exploitation can increase quickly.

Network defenders should also watch for sudden traffic spikes against rewrite-heavy endpoints, API migration routes, and legacy URL forwarding paths.

• Unexpected NGINX worker restarts after external requests.
• Repeated requests containing long or unusual URI padding.
• Traffic targeting routes with rewrite rules and unnamed captures.
• Crash loops affecting one virtual host or one application route.
• New scanner traffic following public PoC publication.

Why ASLR matters for code execution

ASLR makes memory exploitation harder by randomizing where key process memory regions live. F5 and NVD note that code execution is possible when ASLR is disabled.

Most modern Linux distributions enable ASLR by default, which reduces the likelihood of reliable remote code execution. It does not remove the denial-of-service risk.

Administrators should still patch even when ASLR is enabled. Memory corruption bugs can evolve as researchers and attackers find new exploitation methods.

The bigger lesson for edge infrastructure

CVE-2026-42945 shows how long-lived infrastructure code can carry serious memory bugs for years. NGINX is heavily audited and widely deployed, yet this issue remained present for nearly two decades.

The vulnerability also shows why configuration context matters. The affected version range is broad, but real exploitability depends on the server’s rewrite rules and runtime protections.

Organizations should combine fast patching with configuration review. For edge servers, version checks alone do not always show the full risk.

FAQ