CVE-2026-42945: NGINX Rift Heap Buffer Overflow Hits Ingress NGINX

On May 13, 2026, F5 and security research platform depthfirst jointly disclosed CVE-2026-42945, a Critical heap-based buffer overflow (CWE-122) in NGINX's ngx_http_rewrite_module. The flaw, branded "NGINX Rift" by its discoverer, scores 9.2 on CVSS v4.0 and 8.1 High on CVSS v3.1. 

This vulnerability affects every NGINX build between 0.6.27 and 1.30.0, NGINX Plus R32 through R36, and every downstream that ships the same ngx_http_script.c. The mechanism is a two-pass contract violation in NGINX's script engine: an is_args state flag set during length calculation leaks into the copy phase, causing ngx_escape_uri to write past the allocated buffer when a rewrite rule combines an unnamed PCRE capture with a question mark in its replacement. An unauthenticated attacker triggers it with a single crafted HTTP request. The upstream NGINX project shipped patches in 1.30.1 (stable) and 1.31.0 (mainline). For most NGINX operators, that closes the issue.

For Kubernetes teams running Ingress NGINX, it does not. The Kubernetes project retired Ingress NGINX in March 2026. The last released version, v1.15.1, ships the same vulnerable C code as upstream NGINX, and no upstream patch is coming. CVE-2026-42945 lands as an unauthenticated, network-reachable RCE at the cluster's edge, with no maintainer to fix it. HeroDevs ships NES for Ingress NGINX as a maintained drop-in for v1.15.1, and this post covers both the vulnerability and the remediation path.

‍

What is CVE-2026-42945?

CVE-2026-42945 is a heap-based buffer overflow (CWE-122) in ngx_http_rewrite_module, the module that processes rewrite, if, and set directives. The bug lives in src/http/ngx_http_script.c and has been present since NGINX 0.6.27 shipped in 2008. depthfirst's autonomous vulnerability analysis system flagged it in roughly six hours during an April 2026 scan; F5 confirmed on April 24, 2026, and published the coordinated advisory K000161019 on May 13.

The vulnerable pattern is a memory-safety bug triggered by operator-written configurations that combine three elements: a rewrite directive whose replacement contains a question mark (?), an unnamed PCRE capture ($1 through $9), and a later rewrite, if, or set directive that references the same capture. nginx -t does not flag this pattern; the configuration is syntactically valid.

‍

Why CVE-2026-42945 hits Ingress NGINX harder than upstream NGINX

For a stock NGINX OSS operator, the response is straightforward: upgrade to 1.30.1 or 1.31.0 and restart workers. For NGINX Plus, apply R32 P6, R35 P2, or R36 P4. The upstream maintainers have done the work.

Ingress NGINX is in a different operational position for three reasons:

The project is retired. The Kubernetes ingress-nginx project announced retirement in November 2025 and formally wound down in March 2026. No upstream coordinator will integrate the NGINX fix into a new ingress-nginx release. v1.15.1 is the last upstream build and will remain so.

The vulnerable code is compiled in. Earlier post-retirement Ingress NGINX CVEs lived in dependencies (Go standard library, Helm, gomarkdown) and were remediated by upgrading the module and rebuilding. CVE-2026-42945 lives in the NGINX C source itself, in the ngx_http_script.c that ingress-nginx vendors and compiles into the controller binary. Remediation requires patching the C code, not bumping a module version.

The exposure is at the cluster edge. An ingress controller terminates external traffic and sits in front of every service in the cluster. A compromised worker exposes TLS private keys, every proxied request body, and lateral movement into the cluster's internal network (including the kube-apiserver subject to RBAC).

The result for teams running Ingress NGINX 1.15.1: scanners begin reporting CVE-2026-42945 as an open finding the moment NVD propagates the advisory; no upstream patch resolves it; and the operational risk is unauthenticated RCE at the cluster's most exposed surface.

‍

NES for Ingress NGINX: the maintained remediation path

HeroDevs announced NES for Ingress NGINX in April 2026, immediately after retirement. The product is built for exactly the scenario CVE-2026-42945 creates: a deployment that cannot be migrated to a Gateway API alternative on the timeline a fresh Critical CVE demands.

NES for Ingress NGINX preserves the upstream v1.15.1 controller as a drop-in replacement. Operators swap container image and Helm chart references and continue operating on the v1.15.1 surface they already validated.

What ships with the line:

• Drop-in container image at registry.nes.herodevs.com/neverendingsupport/ingress-nginx-controller, versioned against the upstream v1.15.1 base
• Public Helm chart at HeroDevs/ingress-nginx mirroring the upstream chart structure
• VEX statements in OpenVEX and CycloneDX VEX formats, so scanners report patched findings instead of leaving CVEs as open
• Release notes at docs.herodevs.com/ingress-nginx/release-notes documenting which CVEs each release closes

NES for Ingress NGINX 1.15.2 (April 20, 2026) was the first commercial extended-support release after retirement. It resolved CVE-2026-32282 (Go toolchain), CVE-2026-35204 and CVE-2026-35205 (Helm), CVE-2024-44337 and CVE-2026-40890 (gomarkdown). Coverage for CVE-2026-42945 follows the same engineering pattern: HeroDevs incorporates the upstream NGINX 1.30.1 fix into the controller's NGINX build, ships a new NES point release, and the VEX statement updates so scanners report the finding as resolved.

To talk to HeroDevs about NES coverage scope, version status, and timeline for CVE-2026-42945, contact sales.

The rest of this post covers the vulnerability in technical detail.

‍

Severity and exploit conditions

F5 SIRT scored the vulnerability under both CVSS v3.1 and v4.0. The v4.0 score reaches Critical because the v4.0 vector captures the unauthenticated-network-RCE potential more directly than v3.1 does.

‍Exploit preconditions: A vulnerable build, plus a configuration matching the three-element pattern, plus network reachability to a vulnerable route. depthfirst's published PoC demonstrates unauthenticated RCE with ASLR disabled. With ASLR enabled, the same primitive produces a deterministic worker crash; depthfirst also documents a cross-request heap-shaping technique that progressively defeats ASLR. The PoC is public and the exploit primitive is deterministic, so the window between disclosure and opportunistic scanning is short.

‍

Root cause: the is_args state leak

NGINX's script engine runs rewrite directives in two passes: a length pass that calculates how much memory to allocate, and a copy pass that writes the bytes. Both passes must compute the same length.

CVE-2026-42945 breaks that contract. When a rewrite replacement contains a question mark, ngx_http_script_start_args_code sets e->is_args = 1 on the main script engine and never clears it. A later call to ngx_http_script_complex_value_code (triggered by the capture being re-referenced) allocates a fresh sub-engine to compute length, where is_args is zero, so ngx_http_script_copy_capture_len_code measures the capture as raw bytes. The destination buffer is sized for that raw length. But the copy itself runs on the main engine, where is_args is still 1, so ngx_http_script_copy_capture_code calls ngx_escape_uri with the NGX_ESCAPE_ARGS flag. Every +, %, or & byte in the attacker-controlled capture expands from 1 byte to 3, and the write runs past the allocation.

// Length pass measures: raw_len bytes
// Copy pass writes:    raw_len + 2*N bytes (where N = count of escapable chars)
//                      ^^^^^^^^^^^^^^^^^^^ heap overflow

The corruption lands in the NGINX request pool. The bytes written past the allocation are derived from the attacker's URI, so the overflow content is attacker-shaped rather than random. That is what turns the DoS primitive into an RCE primitive. Named PCRE captures ((?<name>...)) bypass the vulnerable escaping path; the bug is specific to unnamed captures.

‍

Exploit chain

depthfirst's published PoC achieves unauthenticated RCE against builds with ASLR disabled in four stages: (1) a crafted HTTP request triggers the overflow into the request pool; (2) cross-request heap shaping arranges allocations so the overflow lands adjacent to an ngx_pool_cleanup_t structure; (3) the overflow rewrites the cleanup handler function pointer; (4) when the request pool is destroyed, NGINX walks the cleanup list and the rewritten handler calls system() with attacker-controlled arguments.

With ASLR enabled, the exploit requires a separate information leak or the iterative byte-by-byte technique depthfirst documents. Either way, the crash primitive remains a deterministic worker restart, and sustained triggering produces a DoS that worker-level rate limiting cannot mitigate.

‍

What an attacker can do

For Ingress NGINX in particular, the worker is the trust boundary between the public internet and the cluster. Concrete impact:

• Code execution in the worker process on builds with ASLR disabled (still common in some hardened-container and minimal-image scenarios)
• TLS private key disclosure for the lifetime of the worker process
• Proxied request and response tampering, including session cookie and bearer token capture in flight
• Persistent DoS via repeated triggering that crashes workers faster than NGINX restarts them
• Cluster-internal lateral movement to the kube-apiserver (subject to RBAC) and adjacent pods on the same node

The exploit requires the specific rewrite-rule pattern in the operator's configuration, so configuration audit is the first action item for any team running an affected build.

‍

Who is affected?

Note the distinction in the first row: the F5-maintained commercial NGINX Ingress Controller (further down) is a different product from the Kubernetes-community Ingress NGINX controller. F5's product has a patched release. The community project does not.

‍

Mitigation guidance

The configuration workaround is a stopgap, not remediation. For Ingress NGINX 1.15.1 in particular, NES is the maintained path that closes the finding in scanners.

‍

Related CVEs in the May 2026 NGINX release batch

CVE-2026-42945 was not the only fix in the nginx 1.30.1 / 1.31.0 window:

• CVE-2026-42946: Buffer overread in ngx_http_scgi_module and ngx_http_uwsgi_module
• CVE-2026-42934: Buffer overread in ngx_http_charset_module
• CVE-2026-42926: HTTP/2 request injection in ngx_http_proxy_module
• CVE-2026-40460: Address spoofing in HTTP/3
• CVE-2026-40701: Use-after-free in OCSP resolver requests

For NGINX OSS and NGINX Plus operators, the May 2026 upgrade resolves all six at once. For Ingress NGINX 1.15.1 operators, every CVE in this batch lives in the same orphaned C codebase, with no upstream maintainer shipping a patched release. NES for Ingress NGINX is the only maintained line positioned to ship coverage for this batch as a coordinated set.

The HeroDevs vulnerability directory tracks the dependency-side CVEs already resolved in NES for Ingress NGINX 1.15.2: CVE-2026-32282, CVE-2026-35204, CVE-2026-35205, and CVE-2026-40890.

‍

Taking action

CVE-2026-42945 is a Critical, unauthenticated, remotely triggerable heap overflow that sat undiscovered in NGINX's most widely used module for 18 years. For most NGINX deployments, the upstream patches close it. For Kubernetes teams on Ingress NGINX 1.15.1, the upstream patches do not exist, and the question becomes how long the deployment can carry an open Critical at the cluster edge.

NES for Ingress NGINX is the maintained line for v1.15.1. It ships as a drop-in container image and Helm chart, with VEX statements so scanners report the finding as resolved. Adopting it is an artifact swap, not a controller replacement or a Gateway API migration in reverse.

To talk to HeroDevs about NES for Ingress NGINX coverage for CVE-2026-42945, including version status and rollout timeline, get in touch.