Overview -------- CVE-2026-9256, nicknamed 'nginx-poolslip', is a critical heap buffer overflow in NGINX's ngx_http_rewrite_module, the regex-based URL rewriting engine that ships enabled by default in every NGINX Open Source and NGINX Plus build. The bug lives in how the rewrite engine constructs the replacement string after a PCRE match: when a `rewrite` (or `if (...)` condition) directive contains overlapping PCRE capture groups whose backreferences are referenced more than once in the replacement template, the code path miscomputes the destination length and writes past the end of a buffer allocated from the per-request `ngx_pool_t`. The overwrite targets the cleanup-handler singly-linked list (`ngx_pool_cleanup_t`) that lives in the same arena, allowing an attacker to clobber a function-pointer (`handler`) and an arbitrary `data` argument that NGINX invokes during normal request teardown. The minimum impact is a SIGSEGV in the worker; given a partial pointer leak or a non-PIE worker binary, the function-pointer overwrite gives a clean control-flow hijack primitive without ROP gadget hunting.

Vulnerability mechanics ----------------------- The ngx_http_rewrite_module compiles each `rewrite` directive at config-parse time and stores a `ngx_http_rewrite_t` execution program. At request time, NGINX walks the program, calls PCRE2 to match against the URI, then iterates the parsed replacement script to size and emit the new URI into a pool-allocated buffer. The sizing pass and the emission pass share a helper that walks the capture-group offset table returned by PCRE. The bug is a classic time-of-check / time-of-use mismatch between sizing and emission: when a replacement references the same nested capture twice (e.g. `$1$2` with pattern `^/((.*))$`, where group 2 is wholly contained inside group 1), the sizing pass de-duplicates the spans, but the emission pass emits both spans verbatim, producing an output longer than the allocation. The overflow lands in adjacent pool metadata — specifically the `cleanup` list head of the `ngx_pool_t` struct that the same allocation is carved from. Because the cleanup list is walked during `ngx_destroy_pool()` at request close, the corrupted `cleanup->handler(cleanup->data)` call is reached unconditionally, even if the response is already on the wire.

Exploit chain ------------- 1. Reconnaissance — scan for `Server: nginx`, fingerprint the version through `error_log` artifacts or banner; verify the target hosts a rewrite directive that references overlapping captures (configs published in major frameworks — Ghost, MediaWiki, OwnCloud, Bitnami, several K8s ingress charts — ship vulnerable patterns by default). 2. Trigger — issue a single HTTP request whose URI path is crafted to maximise the overlap delta. Public PoC submitted to F5 used `GET /AAAA...A HTTP/1.1` with 7,936 bytes of `A` against a server with `rewrite ^/((.*))$ /backend/$1$2 last;`. This yields a 7,936-byte overflow into the pool arena. 3. DoS path — without any further work the worker process segfaults on `ngx_destroy_pool()`; NGINX master respawns the worker, but a sustained request flood prevents any worker from completing a request, producing a hard service outage at <100 req/s. 4. RCE path — where ASLR is disabled (some embedded appliances, older musl/Alpine builds without `-fPIE`, or after a side-channel info leak), the attacker overwrites `cleanup->handler` with the address of `system` (libc) or `ngx_execute_proc` (NGINX) and points `cleanup->data` at attacker-controlled bytes earlier in the URI buffer. The hijack fires inside the worker's address space with the worker user's privileges (typically `nginx`/`www-data`). 5. Post-exploitation — workers commonly hold TLS private keys in memory for keepalive sessions, upstream credentials in shared zones, and JWT signing keys for proxied APIs; web shells are commonly dropped under `/var/cache/nginx/` because that path is writable by the worker user on default packaging.

Relationship to CVE-2026-42945 (NGINX Rift) ------------------------------------------- The earlier 'NGINX Rift' patch (October 2026) corrected a different overflow in the same module — specifically a length miscalculation in the `set $var` directive when `$var` was referenced in a regex backreference. F5's fix was narrowly scoped to the `set` evaluator and did not audit the shared sizing helper used by both `rewrite` replacement and `set` evaluation. CVE-2026-9256 reaches the identical helper through the `rewrite` replacement path, demonstrating that the original remediation was incomplete. The cleanup-handler corruption primitive is identical, so any tooling, detection, or simulation written for NGINX Rift will also detect nginx-poolslip with minor input changes.

Affected products ----------------- - NGINX Open Source: 0.1.17 through 1.30.1; 1.31.0 (mainline) - NGINX Plus: R32 through R36, plus the 37.x preview series - NGINX Ingress Controller: 4.13.x and earlier (transitively, via base NGINX) - F5 BIG-IP Next CNF (uses NGINX data plane): affected if running NGINX < 1.30.2 - Downstream forks: OpenResty (≤ 1.31.0.1), Tengine (≤ 3.2.5), Angie (≤ 1.10.0) — confirmed by maintainers as affected

Fixed versions: NGINX OSS 1.30.2 (stable) and 1.31.1 (mainline); NGINX Plus R36 P5, R32 P7, R37.0.1.1.

Exposure footprint ------------------ Shodan exposes ~250M reachable NGINX banners at disclosure time, with ~38% on versions vulnerable to CVE-2026-9256. Approximately 78% of Kubernetes clusters indexed by SecurityScorecard run the ingress-nginx controller in a pinned chart that has not received the 1.30.2 base-image refresh. Most-impacted sectors: SaaS application delivery, e-commerce checkout flows, government public services, healthcare patient portals.

Defensive posture ----------------- F5 advisory rates this Critical with CVSS v4.0 9.2 and v3.1 8.1. CISA added CVE-2026-9256 to KEV within 48 hours of disclosure based on credible reports of opportunistic mass-scanning. Immediate action: upgrade to fixed versions; if upgrade is not possible within the window, remove any `rewrite` or `if` directive that uses nested PCRE captures (`((...))` form) and reload. A WAF rule blocking requests where the URI path matches the configured rewrite regex AND exceeds the original directive's largest captured span gives a high-quality compensating control until patching is complete.