NGINX “Rift” Rewrite Module Flaw Confirmed as CVE-2026-42945

The NGINX vulnerability claim dubbed “Rift” is no longer just an unverified rumor. Public vulnerability records now track the issue as CVE-2026-42945, a heap-based buffer overflow in the ngx_http_rewrite_module module affecting NGINX Open Source and NGINX Plus.

NVD lists the vulnerability with a CVSS v3.1 score of 8.1 High and a CVSS v4.0 score of 9.2 Critical. F5 is listed as the CVE source, and public advisories describe the issue as reachable by an unauthenticated attacker through crafted HTTP requests under specific configuration conditions.

The vulnerability exists in a specific rewrite-module pattern: a rewrite directive followed by a rewrite, if, or set directive, combined with an unnamed PCRE capture such as $1 or $2 and a replacement string that includes a question mark. Under those conditions, crafted requests may trigger a heap buffer overflow in an NGINX worker process.

That detail matters because this is not simply “every NGINX server is instantly exploitable.” Exposure depends on NGINX version, module use, rewrite configuration and runtime hardening. At the same time, NGINX often sits directly at the internet edge as a web server, reverse proxy, load balancer, ingress controller or API gateway. Even a configuration-dependent flaw can become urgent when it affects externally reachable infrastructure.

Affected-version reporting from public advisories includes NGINX Plus releases R32 through R36 and NGINX Open Source versions 1.0.0 through 1.30.0, as well as older 0.6.x to 0.9.x branches. Administrators should validate the exact applicable fixed builds through F5 or their operating-system, container-image or appliance vendor, because downstream packages may backport patches without changing the upstream version number.

A typical exposure path places the edge server at the center of the risk:

External HTTP Request
NGINX Edge Proxy
Rewrite Module
Specific Rewrite Pattern
Heap Buffer Overflow
Worker Restart or Possible Code Execution
Internal Pivot or Secret Exposure

For now, defenders should prioritize discovery and configuration review. Many environments use NGINX not as a standalone package but inside containers, Kubernetes ingress controllers, API gateways, managed hosting stacks, appliance images or developer-built reverse proxies.

Basic Linux host discovery:

nginx -v
nginx -V
pgrep -a nginx
find / -name nginx.conf 2>/dev/null

Container and Kubernetes checks:

docker ps --format "table {{.Names}}\t{{.Image}}\t{{.Ports}}"
docker images | grep -i nginx
kubectl get pods --all-namespaces | grep -i nginx
kubectl get ingress --all-namespaces

Configuration review should focus on rewrite-module usage and capture-based rewrites. Administrators should export the active configuration, search for rewrite, if, and set directives, then review whether replacement strings combine unnamed captures with question marks.

nginx -T > nginx-effective-config.txt 2>&1
grep -RInE "rewrite|if |set " /etc/nginx /usr/local/nginx/conf 2>/dev/null
grep -RInE "\\$[0-9].*\\?|\\?.*\\$[0-9]" /etc/nginx /usr/local/nginx/conf 2>/dev/null

Until patch coverage is confirmed, defenders should reduce unnecessary exposure. That includes limiting inbound access to required ports, restricting administrative interfaces, disabling unused modules where feasible, reviewing custom rewrite rules, preserving logs and ensuring edge servers cannot initiate unnecessary outbound connections.

Monitoring should focus on behavior that is unusual for production NGINX systems. Warning signs may include worker-process crashes, repeated restarts, unexpected child processes, suspicious files in temporary directories, unauthorized configuration changes, modified modules, abnormal outbound connections or unusual requests targeting rewrite-heavy paths.

A practical check is to look for shells, scripting engines or network utilities spawned by NGINX worker processes:

pgrep -a nginx
for p in $(pgrep nginx); do
 ps --ppid "$p" -o pid,ppid,user,comm,args
done

Teams can also review active network connections from web-tier systems:

ss -plant
lsof -i -P -n | grep nginx

If compromise is suspected, organizations should isolate affected servers, preserve volatile evidence, copy relevant logs, collect NGINX binaries and configuration files, and rotate credentials that may have been exposed through proxied applications or local environment variables. Rebuilding from known-good images is generally safer than attempting to clean a potentially compromised edge server in place.

The prudent course is disciplined response rather than panic: inventory NGINX deployments, identify rewrite-module exposure, validate vendor patch status, reduce avoidable edge access, monitor worker-process behavior and prioritize updates for internet-facing systems.

Sources

• NVD, CVE-2026-42945: https://nvd.nist.gov/vuln/detail/CVE-2026-42945
• F5 advisory K000161019: https://my.f5.com/manage/s/article/K000161019
• runZero, "How to find F5 NGINX installations on your network": https://www.runzero.com/blog/nginx/
• Qualys ThreatPROTECT, "F5 Nginx Remote Code Execution Vulnerability (CVE-2026-42945)": https://threatprotect.qualys.com/2026/05/14/f5-nginx-remote-code-execution-vulnerability-cve-2026-42945/