PatchDay Alert
Subscribe →
Analysis · 6 min read · 1,296 words By Colten Anderson · Commentary

Ingress-nginx got archived in March. The first critical CVE arrived in May.

The Kubernetes community archived ingress-nginx seven weeks before an 18-year-old heap overflow dropped in the NGINX core it ships. The fix path is now a migration project, not a patch.

Ingress-nginx got archived in March. The first critical CVE arrived in May.

The Kubernetes community archived ingress-nginx on March 24, 2026. Seven weeks later, on May 13, a heap buffer overflow that’s been sitting in NGINX since 2008 shipped a patch for everyone except the people running the archived controller. The vulnerable code is compiled into the controller binary. No maintainer remains to integrate the fix. The resolution path F5 posted on the GitHub issue is “use our commercial NGINX Ingress Controller.”

That is the story. The CVE is the occasion.

What landed

CVE-2026-42945, branded “NGINX Rift,” is a state-management bug in ngx_http_script.c, the file that runs NGINX’s rewrite-rule script engine. The trigger is narrow enough that it survived eighteen years of fuzzing and review: a rewrite whose replacement contains a ?, an unnamed PCRE capture ($1, $2) in that replacement, and another rewrite, if, or set directive in the same scope. Under those conditions the length-calculation pass and the copy pass disagree about the size of the output buffer, and the copy walks off the end of the heap allocation with attacker-controlled bytes. The discoverer’s writeup walks through the heap feng shui that turns the overflow into RCE on ASLR-disabled hosts.

The AlmaLinux advisory is honest about what that means on a modern 64-bit Linux host: reliable RCE against ASLR is not straightforward, but reliable worker-crash DoS is. Take the DoS as the floor. Don’t bet on the ASLR ceiling holding for any specific deployment.

VulnCheck’s honeypot network logged the first in-the-wild exploitation on May 16, 2026, three days after disclosure. Caitlin Condon attributed the traffic to a single Chinese IP running a customized build of Vulnhuntr to scan for the trigger pattern, dropping PHP web shells on hosts that confirmed vulnerable. Censys banner counts surfaced approximately 5.7 million servers advertising a vulnerable NGINX version. That number is the population, not the attack surface; it doesn’t filter for configs that actually use the rewrite trigger, and no published methodology has narrowed it. The exploitable subset is meaningfully smaller. Nobody knows how much smaller.

CVE-2026-42945 was not on CISA’s KEV catalog as of this writing. Worth watching.

The host-side fix is the easy part

If you run NGINX on a host you patch, you’re fine. NGINX OSS 1.30.1 and 1.31.0 shipped on disclosure day. F5 published K000161019 with NGINX Plus R36 P4, R32 P6, and R37.0.0. Canonical’s USN-8271-1 backported the day after upstream across the 22.04 LTS, 24.04 LTS, and 25.10 package lines. Debian followed with DSA-6278-1 on May 16. AlmaLinux pushed packages for AL8, AL9, AL10, and Kitten 10 on disclosure day.

The named-capture workaround is also mechanical: swap $1 and $2 for (?<name>pattern) and $name in any rewrite, if, or set that uses them, or strip the ? from replacement strings, or disable the rewrite module if you’re not using it. All three are reload-on-config. Distros and config audits cover the long tail of bare-metal and VM deployments.

That is not where the operational problem lives.

Where the problem lives

The community ingress-nginx controller is distinct from F5’s commercial NGINX Ingress Controller, and it has been the default ingress on hundreds of thousands of clusters for years. controller-v1.15.1 shipped March 19. The project was archived March 24. The vulnerable ngx_http_script.c is compiled into the controller image. There is no module to swap, no maintainer to release a v1.15.2, no upstream branch to pull a backport from.

The GitHub issue opened May 14 was closed by pointing operators at F5’s commercial NGINX Ingress Controller as the resolution path. That is a fair answer from F5. It is also a migration project, not a kubectl rollout restart. The replacements on the table are F5’s commercial controller, Gateway API plus a different implementation, or a service-mesh ingress like Istio or Cilium. None of those is a same-day swap on a cluster that’s been running community ingress-nginx for three years with hand-built annotations and templated Helm values.

The named-capture workaround works at the controller level, but it has to be applied cluster-wide and re-enforced against every Ingress resource that templates a rewrite annotation. On a multi-tenant cluster with dozens of teams pushing manifests, that’s a policy problem, not a one-time patch.

HeroDevs is selling a Never-Ending Support drop-in image with VEX statements so scanners report the finding resolved. That is a real option for orgs that need to buy time. It is also exactly what “archived” was supposed to make unnecessary.

Why this keeps happening

If the bug had landed in March 2025 instead of May 2026, the upstream project would have shipped a controller-v1.15.2, scanners would have flagged it, and most operators would have caught it in the next quarterly upgrade window. The same bug seven weeks after archival is a procurement decision.

Critical OSS infrastructure gets archived on schedules that assume the migration is mostly done by the time the lights go off. The schedule is reasonable on paper. Maintainers announce, the community is told, sunset dates are published, and a migration window of months or quarters is offered. The assumption underneath the schedule is that no serious bug will arrive during the wind-down tail, because if one does, the entire premise of the migration window collapses. The window assumed there would be time. The bug doesn’t care.

The first post-archival CVE is always the one that exposes the gap between announced sunset and actual migration. It’s not a maintainer failure. The maintainers did the announced work. It’s a structural mismatch between how OSS projects retire and how enterprises adopt them. Adoption is measured in years and quiet defaults. Retirement is measured in release notes nobody reads until something breaks. The bridge between those two timelines is a commercial vendor or a paid drop-in or a scramble, and which one you get depends on whether your platform team had budget and runway.

What to actually expect

Most clusters running community ingress-nginx today have not finished a migration. The honest planning posture:

  • Apply the named-capture workaround as a stopgap. It’s a cluster-wide audit of every rewrite annotation in every namespace, and it has to hold against future manifests. Build the policy check before you build the report.
  • Treat the migration as a quarter of work, not a sprint. Gateway API with a different controller is the cleanest exit if your workloads tolerate the annotation rewrite. F5’s commercial controller is the lowest-friction swap if the budget exists. HeroDevs’ paid image buys the calendar to choose between them.
  • Don’t wait for a community fork. The community telegraphed this retirement for months. A rescue fork big enough to maintain ngx_http_script.c safely is not going to materialize from a CVE-driven panic.
  • Confirm ASLR is on at the host or node level. That’s the difference between a worker-crash DoS and something worse on the days when the workaround hasn’t propagated yet.

The 5.7M Censys number will keep getting cited. The number that matters to your cluster is one: are you running community ingress-nginx in production. If yes, the patch isn’t a patch. It’s a project.

NGINX Rift will get patched everywhere there’s a maintainer to patch it. PatchDay Alert tracks the host-side rollouts as they land. The places it won’t get patched are the places that already got the announcement.

Sources

Share

X LinkedIn Facebook Email
Tags #kubernetes #nginx #open-source

Related field notes

Get the free CVE triage cheat sheet

Subscribe and we'll email you the one-page triage flow for fresh CVEs. Plus the weekday digest.

Subscribe