NGINX administrators are facing back-to-back emergency patch cycles. Within days of each other, two critical heap buffer overflow vulnerabilities were disclosed in the same NGINX component, both capable of crashing worker processes and enabling remote code execution on systems without ASLR. If your organization runs NGINX in any capacity, these need immediate attention.
CVE-2026-42945: NGINX Rift
Risk Analysis
Severity: High
CVSS v3x Score: 8.1
Attack Vector: CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H
Exploit Publicly Available: Yes
Exploitation Complexity: High
Researchers discovered CVE-2026-42945, dubbed NGINX Rift, during an AI-assisted security audit. The vulnerability had been sitting undetected in the NGINX codebase for nearly 18 years.
The vulnerability lives in ngx_http_rewrite_module. It triggers when a rewrite directive uses unnamed PCRE capture groups (like $1 or $2) in a replacement string containing a question mark, followed immediately by another rewrite, if, or set directive in the same scope. The root cause is an escaping logic mismatch: NGINX calculates the required buffer size under one set of assumptions, then performs the actual copy under different ones. The result is attacker-controlled bytes written past the end of the heap buffer.
Affected versions: NGINX Open Source 0.6.27 through 1.30.0; NGINX Plus R32 through R36.
Fixed versions: NGINX Open Source 1.28.1 (stable) and 1.29.1 (mainline); updated NGINX Plus and Kubernetes-related releases.
CVE-2026-9256: NGINX Poolslip
Risk Analysis
Severity: High
CVSS v3x Score: 8.1
Attack Vector: CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H
Exploit Publicly Available: Yes
Exploitation Complexity: High
Before organizations had fully patched NGINX Rift, a second vulnerability emerged from the same attack surface. CVE-2026-9256, nicknamed nginx-poolslip, affects the same ngx_http_rewrite_module component.
Poolslip triggers when a rewrite directive uses regex patterns with distinct, overlapping PCRE capture groups, such as ^/((.*))$, paired with a replacement string referencing multiple captures like $1$2. Where NGINX Rift abused a buffer-size calculation error, poolslip triggers a controlled pointer slip across adjacent linked structures in the same memory pool, via a different code path to the same corruption target. Critically, the patch for NGINX Rift did not remediate the underlying memory pool attack surface, leaving this path open in the updated codebase.
Affected versions:
| Product | Vulnerable Versions | Fixed Versions |
|---|---|---|
| NGINX Open Source | 0.1.17 through 1.30.1 and 1.31.0 | 1.30.2 / 1.31.1 |
| NGINX Plus | R32 through R36; 37.0.0 | R36 P5, R32 P7, 37.0.1.1 |
| NGINX Instance Manager | 2.17.0 through 2.22.0 | No fix available yet |
| NGINX App Protect WAF | 4.10.0 through 4.16.0; 5.2.0 through 5.8.0 | No fix available yet |
| NGINX Gateway Fabric | 1.3.0 through 2.6.1 | No fix available yet |
| NGINX Ingress Controller | 3.5.0 through 5.4.2 | No fix available yet |
What Is at Risk
A successful exploit does not affect one application in isolation. NGINX commonly sits at the infrastructure edge serving multiple virtual hosts, acting as a reverse proxy for internal services, or running as a Kubernetes ingress controller. A crashing worker takes everything behind it offline simultaneously, not just a single site or endpoint.
In reverse proxy and API gateway deployments, a crash-restart loop creates sustained downtime across every backend service sitting behind the affected NGINX instance. For organizations running NGINX as a Kubernetes ingress controller, the exposure reaches the entire cluster edge, leaving all routed services unreachable during active exploitation.
In environments where ASLR is disabled, the consequences go beyond availability. A compromised NGINX worker sits at the network edge with visibility into internal backend traffic, giving an attacker a foothold to move laterally into internal infrastructure. Given that NGINX handles roughly a third of all web server traffic globally, the potential blast radius across internet-facing deployments is significant.
What Both Vulnerabilities Have in Common
Both CVEs share the same underlying module (ngx_http_rewrite_module), the same trigger class (unnamed PCRE capture groups in rewrite directives), the same impact profile (DoS guaranteed, RCE conditional on ASLR state), and the same real-world exposure pattern. Rewrite configurations using unnamed captures appear routinely in WordPress deployments, reverse proxy setups, and API gateway configurations. Organizations that patched NGINX Rift without reviewing their configurations for the poolslip pattern remain exposed.
How to Mitigate CVE-2026-42945 and CVE-2026-9256 in NGINX
Organizations running NGINX Open Source or NGINX Plus need to act immediately. Both CVE-2026-42945 (NGINX Rift) and CVE-2026-9256 (nginx-poolslip) are under active exploitation, and the steps below cover everything from emergency patching to configuration hardening.
1. Apply the Latest NGINX Security Patches
The fastest way to remediate CVE-2026-42945 and CVE-2026-9256 is to upgrade to a fixed NGINX release. Upgrade to NGINX Open Source 1.30.2 or 1.31.1, or the appropriate NGINX Plus release as listed in the affected versions table above. For downstream products where patches are not yet available, move to configuration mitigations immediately while you wait for vendor fixes.
2. Audit Your NGINX Rewrite Configuration
Both vulnerabilities are only exploitable when a specific rewrite configuration pattern is present. Review nginx.conf and all included configuration files for rewrite directives using unnamed capture references ($1, $2) with question marks in replacement strings, followed by additional rewrite-related directives in the same location block. Replace unnamed groups with named captures, for example (?<user_id>…) referenced by name in the replacement string. This single configuration change eliminates the attack surface for both CVEs if immediate patching is not possible.
3. Verify ASLR Is Enabled on All NGINX Hosts
Address Space Layout Randomization (ASLR) is the primary control separating a denial-of-service outcome from remote code execution for both CVE-2026-42945 and CVE-2026-9256. On Linux systems, confirm /proc/sys/kernel/randomize_va_space is set to 2. Any NGINX host running without ASLR faces a significantly higher risk of full compromise.
4. Monitor for Abnormal NGINX Worker Restarts
Active exploitation of both vulnerabilities causes NGINX worker processes to crash and restart in a loop. Set up alerting on abnormal worker restart frequency as an early indicator of ongoing exploitation attempts targeting CVE-2026-42945 or CVE-2026-9256 in your environment.
5. Deploy WAF Protection for NGINX Rift and Poolslip
A WAF deployed in front of your NGINX infrastructure can inspect and block malicious HTTP requests carrying CVE-2026-42945 and CVE-2026-9256 exploit payloads before they reach the vulnerable worker process. This is especially important for environments where patching or configuration changes cannot be completed immediately.
AppTrana Coverage
AppTrana sits as a reverse proxy in front of your application, inspecting and filtering all inbound HTTP traffic before it reaches your backend infrastructure. For both CVE-2026-42945 (NGINX Rift) and CVE-2026-9256 (nginx-poolslip), the exploit is delivered via a single crafted HTTP request targeting a vulnerable NGINX instance. AppTrana can inspect and block these malicious requests at the edge before they reach a vulnerable NGINX backend, preventing the heap corruption from being triggered in the first place.
Stay tuned for more relevant and interesting security articles. Follow Indusface on Facebook, Twitter, and LinkedIn.