Sample of assets impacted by NGINX nginx-poolslip vulnerability, identified by the CyCognito Platform
What is CVE-2026-9256?
CVE-2026-9256, publicly nicknamed "nginx-poolslip," is a heap buffer overflow in the ngx_http_rewrite_module component of NGINX Plus and NGINX Open Source. The flaw is triggered when a rewrite directive uses a regex pattern with distinct, overlapping Perl-Compatible Regular Expression captures (for example, ^/((.*))$) and a replacement string that references multiple such captures (for example, $1$2) in a redirect or arguments context. Under these conditions, NGINX underestimates the length of the output after URI escaping, producing an out-of-bounds write inside the worker process memory pool.
The vulnerability carries a CVSS v3.1 base score of 8.1 (High) and a CVSS v4.0 base score of 9.2 (Critical). Exploitation is pre-authentication: a remote attacker can trigger the condition by sending crafted HTTP requests over plain HTTP. No credentials, user interaction, or prior foothold are required.
The primary impact is a denial-of-service condition caused by repeated worker process crashes. On systems where Address Space Layout Randomization is disabled, or where an attacker can bypass ASLR, the same primitive enables remote code execution in the worker process context. F5 has confirmed the issue affects only the data plane, not the control plane.
CVE-2026-9256 is distinct from CVE-2026-42945, a separate heap overflow disclosed nine days earlier in the same rewrite module. Environments that upgraded to NGINX 1.31.0 or 1.30.1 to patch CVE-2026-42945 remain vulnerable to CVE-2026-9256. Two critical bugs in the same module within nine days is a notable signal about how thoroughly the rewrite engine has been audited.
What assets are affected by CVE-2026-9256?
NGINX Open Source versions 0.1.17 through 1.31.0 are vulnerable. NGINX Plus is affected across R32 through R36, and the 37.x branch. The legacy 0.x branch is end of life and will not receive a fix. Downstream products that embed the affected code path, including NGINX Ingress Controller, NGINX App Protect, NGINX Gateway Fabric, NGINX Instance Manager, and F5 WAF for NGINX, inherit the vulnerability and require updates as patched versions ship. F5 BIG-IP, BIG-IQ, F5OS, and F5 Distributed Cloud Services are not affected.
In practice, affected assets are the workhorses of the modern internet edge: reverse proxies in front of web applications, API gateways, Kubernetes ingress controllers, load balancers, and content-serving frontends. NGINX runs an estimated 30 to 40 percent of all web servers globally, which means most organizations have it deployed somewhere. Often it is running in multiple tiers, managed by different teams, and embedded inside vendor appliances and container images where the underlying version is not actively tracked.
Exploitability hinges on configuration. The flaw is only triggered when a rewrite directive uses overlapping unnamed PCRE captures with multi-capture replacement strings in a redirect or arguments context. That pattern is not universal, but it is far from rare.
Rewrite rules of this shape appear in long-lived configurations for SEO redirects, URL canonicalization, multi-tenant routing, and legacy URL migration. Because these rules are usually written once and rarely audited, the vulnerable configurations tend to sit on the most exposed surfaces in an environment.
A particular concern for Kubernetes operators: the archived kubernetes/ingress-nginx repository, which ships NGINX 1.27.1, will never receive an upstream fix for this CVE. Workloads still routing through that ingress controller are permanently exposed.
What does our data show about exposure patterns?
Exposure in this set is led by Consumer Discretionary at 27.7% of observed assets, with Information Technology contributing 17.2%. Together, the top three named sectors account for over 60% of the externally reachable NGINX instances flagged as potentially vulnerable.
The concentration in Consumer Discretionary reflects how this sector operates online. Retailers, hospitality groups, automotive brands, and durable goods manufacturers run sprawling digital storefronts with high web traffic, complex routing requirements, and frequent campaign-driven URL changes. NGINX sits in front of nearly all of it, and the rewrite rules accumulate over years of redirects, promotions, and brand migrations.
The same configurations that drive customer experience also produce the exact pattern the bug needs to fire. Information Technology and Industrials follow a similar logic at smaller scale: SaaS platforms, vendor portals, and partner-facing applications all rely heavily on NGINX as a reverse proxy and ingress layer.
The cross-sector pattern reveals something more general. Affected assets are not concentrated in any single industry because the vulnerable component is infrastructure, not an application. Anywhere a web service is exposed to the internet, NGINX is likely in the path, and the version inventory is often poorer than the application inventory above it. This is the kind of vulnerability that exposes the gap between knowing what services an organization runs and knowing what software versions actually answer requests at the edge.
Are fixes available?
Yes. F5 released fixed versions on May 22, 2026. NGINX Open Source users should upgrade to 1.31.1 or 1.30.2. NGINX Plus customers on R32 through R36 should move to R36 P5 or R32 P7, and 37.x users should upgrade to R37.0.1.1.
There are two important caveats. First, version 1.31.0 and 1.30.1 do not fix this issue. Those releases patched CVE-2026-42945 only, and organizations that upgraded to them in the previous emergency cycle remain vulnerable to CVE-2026-9256.
Operators should verify the running binary version on each instance, not the installed package version, and confirm it is at least 1.31.1 or 1.30.2. Second, the 0.x branch is past end of technical support and will receive no fix. Any production system still running 0.x should be migrated to a supported branch rather than treated as patchable.
Downstream products built on NGINX, including ingress controllers and WAF distributions, are receiving fixes on their own schedule. Defenders should treat each downstream product as independently vulnerable until the vendor confirms a patched release is available and deployed.
Are there any other recommended actions to take?
Until patching is confirmed, defenders should:
- Inventory all NGINX Plus and NGINX Open Source instances and verify the running binary version on each
- Audit
rewrite,if, andsetdirectives for unnamed PCRE captures combined with multi-capture replacement strings - Replace unnamed captures with named captures in affected rewrite directives as the F5-recommended interim mitigation
- Confirm Address Space Layout Randomization is enabled system-wide on every host running NGINX
- Monitor NGINX error and access logs for repeated worker process restarts or unusual request patterns targeting redirect endpoints
- Prioritize external-facing reverse proxies, API gateways, and ingress controllers ahead of internal-only deployments
How can CyCognito help your organization?
CyCognito published an Emerging Threat Advisory for CVE-2026-9256 in the CyCognito platform and is actively researching enhanced detection capabilities for this vulnerability.
To learn how CyCognito can help your organization reduce external exposure and manage emerging threats more effectively, contact us to request a demo.
