NGINX Rift: four places apt upgrade doesn't reach

If App Protect WAF is your compensating control in front of NGINX, that control is in scope for CVE-2026-42945. App Protect WAF 4.9.0 through 4.16.0 and 5.1.0 through 5.8.0 carry the same vulnerable rewrite engine the core server does, so a “patched NGINX, WAF in front” posture is currently trusting a vulnerable layer to protect a patched one. Update App Protect before treating it as a control. That order matters more than the headline patch number.

CVE-2026-42945 is the heap buffer overflow in ngx_http_script.c that’s been sitting in NGINX since 0.6.27. NGINX 1.30.1 and 1.31.0 shipped on May 13; distro backports landed within 24 to 72 hours. VulnCheck’s honeypot network logged exploitation three days after disclosure, so this is not a “monitor and patch” CVE.

Four queues the host patch leaves open

apt upgrade nginx and dnf update nginx close the bug on bare metal and on VMs. The other half of the population lives in container images you didn’t author, in commercial NGINX products on a separate release train, in downstream forks compiled from the same source file, and in config patterns that survive a binary swap. Each is its own queue.

Container images

Every base image with FROM nginx:1.30.0 or any earlier pin in its inheritance chain ships the vulnerable binary. The host-side package upgrade does nothing about that binary. Neither does an nginx -v on the host where the container runs. The image carries its own copy.

The rebuild queue is what fixes this, and the container-aware scanners are how you find it. Trivy, Grype, Wiz, and Orca will all flag CVE-2026-42945 against the bundled NGINX version once their feeds catch up. Run them across the registry, not just on build. The interesting findings are images nobody on your team explicitly authored: a Bitnami chart that pulls a vendored NGINX, an internal proxy image that inherited two levels up from nginx:1.27, a sidecar baked into a vendor Helm package.

Expect the scanner result to keep firing for weeks. Image rebuilds propagate at the speed of CI pipelines, registry pushes, and rolling deployments, and none of those are same-day for most environments. The right mental model is a burndown, not a deadline. Tag the open findings, sort by image pull count, and work top-down.

For Kubernetes, kubectl get pod -A -o jsonpath='{range .items[*]}{.spec.containers[*].image}{"\n"}{end}' | sort -u is faster than a registry scan for “what’s actually running right now.” Cross-reference against the scanner output to find the gap between “image scanned” and “image deployed.”

The F5 surface above the core

The NGINX core in /etc/nginx is the smallest part of the F5 product family that’s in scope. F5’s K000161019 advisory lists seven other product lines that need separate attention, each with its own version-to-fix mapping:

• NGINX Plus R32 through R36. Fix points are R36 P4, R32 P6, and R37.0.0. A host that reports “Plus R36” without the patch level is not patched.
• NGINX App Protect WAF 4.9.0 through 4.16.0 and 5.1.0 through 5.8.0. The compensating-control trap mentioned at the top lives here.
• NGINX App Protect DoS 4.3.0 through 4.7.0.
• F5 WAF for NGINX 5.9.0 through 5.12.1.
• F5 NGINX Ingress Controller 3.5.0 through 5.4.1, across three sub-ranges. This is F5’s commercial product, distinct from the archived community ingress-nginx.
• NGINX Gateway Fabric 1.3.0 through 1.6.2 and 2.0.0 through 2.5.1.
• NGINX Instance Manager 2.16.0 through 2.21.1.

Each of those is a separately versioned asset with its own change window. If you have a paid F5 footprint, the inventory step is a query against the F5 portal license file, not a Linux package manager. NGINX Plus customers should check /etc/nginx/license.jwt or the portal directly; the patch level is in the JWT.

The sequencing point worth repeating: update App Protect WAF before relying on it as the layer that catches exploitation attempts against the core. Both Akamai and SOCRadar recommend WAF rules targeting anomalously long URI segments aimed at rewrite paths, which is reasonable posture if the WAF itself is on a fixed build. If it’s not, you’re filtering attacker traffic through a vulnerable filter.

Downstream forks

OpenResty, Tengine, Angie, FreeNGINX, Kong, and APISIX all compile the same ngx_http_script.c. One bug shipped in six packagings. As of this writing, none of those projects had a discoverable advisory or release announcement with the CVE-2026-42945 patch backported.

That doesn’t mean they’re unpatched; it means you need to track each upstream individually. Kong and APISIX gate their NGINX layer behind their own release cadence, and OpenResty has historically taken weeks to roll up upstream NGINX patches into a tagged release. If you run any of these at the edge or as an API gateway, subscribe to the project’s release feed and treat the gap as an open finding until the maintainer ships. The host package manager won’t help; OpenResty isn’t apt upgrade openresty on most installs, and Kong’s official containers pin their NGINX layer.

Forks are also where the scanner story gets weaker. Trivy and Grype track CVE-to-package mappings based on CPE data, and the fork projects don’t always populate that cleanly. Expect to do the version check by hand.

Audit configs even on patched hosts

A patched binary does not mean a safe host forever. The bug needs a vulnerable version and a specific config pattern: an unnamed PCRE capture ($1, $2) in a rewrite replacement that contains a ?, followed by another rewrite, if, or set in the same scope. A future config change rolled out by someone who doesn’t know the history can reintroduce the trigger pattern across the fleet, and a rollback to an older binary on a host with that pattern present is suddenly exploitable again.

Two open-source scanners surfaced in the first two weeks. realityone/cve-2026-42945-scan is a no-dependency Python tool. Point it at /etc/nginx and it reports file:line for every vulnerable pattern. sibersan/web-server-audit_CVE-2026-42945 is broader: it classifies hosts as Active (vulnerable version plus trigger pattern present), Latent (vulnerable version, no trigger pattern, safe until the config changes), or Unverified (config unreadable). It also parses ASLR state and worker-crash logs.

The Active / Latent split is the part worth keeping after the immediate cleanup. Active hosts are the patch queue’s top priority. Latent hosts are safe today and exposed only if someone introduces the trigger pattern via a config change, so they go in the slower remediation queue with monitoring on the config files. Add the named-capture audit to whatever linter or pre-commit hook your nginx configs already pass through.

The week’s order of operations

Inventory before you touch anything. Map the host packages, the container images, the F5 product footprint, and the forks. Run the config audit on what you have. Then in parallel: patch hosts via distro updates (the cheapest move), update App Protect WAF and the rest of the F5 surface before treating any of them as compensating controls, start the image rebuild burndown and expect it open for weeks, apply the named-capture workaround anywhere the pattern shows up including on patched hosts, and track the forks against their own release feeds.

The host patch is the easy job because the package manager does it for you. Everything else is operational discipline. PatchDay Alert flags the F5 sub-product releases and the fork rebuilds as they land, so the cleanup queue stays visible past the day-one headline. Three weeks from now, “done” looks like a zero-finding scanner run across the registry, every F5 product on a fixed build, and the named-capture audit wired into config review — not a closed ticket on the host package.