The Financial Industry Regulatory Authority (FINRA) has warned firms of a security vulnerability that poses potentially severe risks to organizations using NGINX products.

On June 27, 2026, the National Vulnerability Database (NVD) updated the severity scores for the NGINX “Rift Chain” Remote Code Execution Vulnerability. Since the vulnerability’s May 2026 disclosure, it has been actively exploited, and FINRA has identified a growing number of potentially affected member firms. This critical heap-based buffer overflow flaw allows unauthenticated attackers to crash processes. On systems where Address Space Layout Randomization (ASLR) is disabled, attackers may also execute malicious code.

Because NGINX commonly protects important backend systems and publicly available exploit codes exist, this vulnerability poses significant risk to firm infrastructure.

Affected Products

The vulnerability exists in the ngx_http_rewrite_module, which is part of every standard NGINX build.

• NGINX Open Source 0.6.27 through 1.30.0 (patch: upgrade to 1.31.0 or 1.30.1)
• NGINX Plus R32 through R36 (patch: R36 P4 or R32 P6)
• NGINX Plus 37.0.0 through 37.0.1 (patch: 37.0.2.1)
• NGINX Instance Manager 2.16.0 through 2.22.0 (patch: 2.22.1)
• F5 WAF for NGINX 5.9.0 through 5.12.1 (patch: 5.13.0)
• NGINX App Protect WAF 4.9.0 through 4.16.0 and 5.1.0 through 5.8.0
• F5 DoS for NGINX 4.8.0 (patch: 4.9.0)
• NGINX App Protect DoS 4.3.0 through 4.7.0
• NGINX Gateway Fabric 1.3.0 through 1.6.2 and 2.0.0 through 2.6.0
• NGINX Ingress Controller 3.5.0 through 3.7.2, 4.0.0 through 4.0.1, and 5.0.0 through 5.4.2

Products not affected: BIG-IP, BIG-IQ, F5 AI Gateway, F5 Distributed Cloud, F5OS, F5 Silverline, NGINX One Console, Traffix SDC.

Additional details and recommended remediation steps can be found on the F5 Security Advisory K000161019.

Member firms and firm vendors using affected NGINX products are strongly encouraged to take the following steps:

• Apply patches immediately – Upgrade to patched versions listed in the F5 Security Advisory. Patch public-facing web servers, API gateways, and third-party appliances running NGINX first. Restart NGINX services after patching to ensure updates take effect.
• Implement temporary protections – Use Web Application Firewall (WAF) rules and access controls to limit exposure to vulnerable systems until patches can be applied. Note: These are temporary measures only; patching is still required.
• Monitor for signs of exploitation – Watch for unexpected crashes, service restarts, or performance degradation, which may indicate exploitation attempts.
• Review NGINX configurations – Examine rewrite rules that use variable references (such as $1, $2) in combination with query strings (?). Where possible, have IT staff or vendors implement safer configuration alternatives, such as named capture groups.
• Verify security features are enabled – Confirm that ASLR and other system-level protections are active on servers running NGINX.
• Check vendor and third-party systems – Verify whether vendors, appliances, or managed services embed vulnerable NGINX versions that may not be obvious from product banners.

This incident demonstrates how threat actors exploit vulnerabilities in widely used open source software. Such exploitation can expose sensitive business and customer data or render firm systems inoperable. Firms using NGINX—particularly for public-facing services—should heighten security vigilance and review configuration practices.