ingress-nginx's EOL Didn't Stop CVE-2026-3288: What Patching a Dead Project Means for Your Routing Layer

On March 24, 2026, the Kubernetes project archived kubernetes/ingress-nginx and made it read-only. No more releases, no more bugfixes, no more security patches — official, final, end of life. Two months later, on May 22, someone patched a CVSS 9.2 pre-authentication remote-code-execution bug into it anyway.

That patch, for CVE-2026-9256, didn't come from the Kubernetes project — the repository can't accept it anymore. It came from a corporate fork nobody voted on. And it's not even the strangest part of the story: the more direct answer to "did EOL stop the bleeding" is CVE-2026-3288, a CVSS 8.8 remote-code-execution and secrets-disclosure bug that was patched on March 9, 2026 — after the retirement was announced, weeks before the archive date, and as an incomplete fix for a bug patched five weeks earlier still. If you run ingress-nginx anywhere in your fleet — and roughly half of Kubernetes clusters still do — "unmaintained" turned out to mean something much messier than "stopped getting patches."

The Timeline That Doesn't Add Up the Way "EOL" Implies​

Here's the sequence, with every date and version tied to a public advisory:

Read that top to bottom and the phrase "no further releases, no bugfixes, no security patches" turns out to describe only one specific repository's commit access — not the fate of the software actually running in production. The code kept getting patched. Who was doing the patching, and under what obligation to you, changed completely.

Why One Bug Needed Three Patches​

CVE-2026-24512, CVE-2026-3288, and CVE-2026-4342 aren't three unrelated vulnerabilities that happened to land in the same quarter. They're three attempts to close the same hole: ingress-nginx builds its nginx configuration by string-interpolating values from Ingress annotations — rewrite-target chief among them — directly into a generated config file. Sanitize the input incompletely, and an attacker who can create or modify an Ingress object can smuggle raw nginx directives into the controller's own configuration. That's not a narrow parsing slip; it's an entire class of injection that requires anticipating every way nginx's config grammar can be broken out of.

The project's own maintainers had already reached this conclusion before the CVEs forced the point: "snippet" annotations — the family of features that let an Ingress author drop raw nginx configuration inline — had gone from a power-user convenience to what the retirement announcement itself called an unfixable security liability. CVE-2026-24512's fix addressed one interpolation path. CVE-2026-3288 found another. CVE-2026-4342 found a third, via comments.

Each fix was a legitimate, complete patch for the specific bypass it addressed. But each one left the underlying architecture — string-building nginx config from untrusted annotation values — fully intact for the next researcher to find another way through it.

The Part the Retirement Announcement Didn't Warn You About​

Here's the gap between the plan and what happened. The Nov 2025 announcement gave everyone running ingress-nginx a five-month runway to migrate before support ended. What it didn't — couldn't — predict was that the project's last four months of life would produce three of its most severe RCE disclosures ever, arriving in a steady drumbeat right up to the literal archive date.

CVE-2026-3288 landed with the EOL clock already running. CVE-2026-4342 landed five days before the repository went read-only. If either bug had been found five days later, there would have been no official fix, ever — just a CVSS 8.8 pre-auth-adjacent RCE sitting unpatched in the most widely deployed Ingress controller in Kubernetes, with the only recourse being whatever a third party chose to do about it.

That's exactly what happened two months later with CVE-2026-9256. Chainguard's EmeritOSS program — a paid stewardship service for orphaned open-source projects — picked up the maintenance burden the official project no longer could. Its fork applies "best-effort" fixes for vulnerabilities that can be patched safely; it explicitly will not backport fixes requiring deeper refactoring.

It ships no free prebuilt container images — you build your own from source. There's no SLA, no security response committee, no guarantee the fork outlives Chainguard's business interest in maintaining it. That's not a worse version of what the Kubernetes project provided; it's a fundamentally different thing wearing the same package name.

Auditing Your Fleet: Are You Actually Patched?​

This is where "EOL" stops being a headline and starts being a question about your specific clusters. Run this in order.

1. Find every ingress-nginx controller you're running, across every namespace and every tenant cluster:

kubectl get pods --all-namespaces \
  --selector app.kubernetes.io/name=ingress-nginx -o wide

2. Pull the image tag for each controller deployment — don't trust a dashboard or an inventory spreadsheet, read it off the live object:

kubectl get deploy --all-namespaces \
  -l app.kubernetes.io/name=ingress-nginx \
  -o jsonpath='{range .items[*]}{.metadata.namespace}{"\t"}{.metadata.name}{"\t"}{.spec.template.spec.containers[0].image}{"\n"}{end}'

3. Confirm the running binary version directly — image tags can be mutable, overridden, or stale relative to what's actually deployed:

kubectl exec -it <pod-name> -n <namespace> -- /nginx-ingress-controller --version

4. Cross-check against the version table above. Anything below v1.13.9 / v1.14.5 / v1.15.1 is exposed to at least CVE-2026-3288 or CVE-2026-4342 — an RCE and Secret-disclosure bug with a public exploitation writeup already circulating. Anything on the official kubernetes/ingress-nginx lineage, including the final v1.15.1, has no path to CVE-2026-9256 coverage — that fix exists only on Chainguard's fork, starting at controller-v1.15.6.

5. If you're multi-tenant, check who can create Ingress objects — that's the actual attacker in this vulnerability class, not a cluster-admin:

kubectl auth can-i create ingresses \
  --as=system:serviceaccount:<tenant-namespace>:<tenant-service-account> \
  -n <tenant-namespace>

Any principal that answers "yes" — including a tenant's own deploy pipeline, if your platform auto-provisions Ingress objects on their behalf — is a principal that could have popped an unpatched controller and read every Secret it had RBAC access to.

Why This Cuts Deeper on a Self-Hosted PaaS​

A single-tenant cluster with one team's traffic behind ingress-nginx has one blast radius to worry about. A platform that auto-provisions an Ingress object per deployed app — which is exactly what a self-hosted PaaS does every time a git push produces a new HTTPS route — has as many blast radii as it has tenants, and the controller sits with RBAC visibility across all of them. CVE-2026-3288 and CVE-2026-4342 don't require compromising the platform's control plane at all; they require nothing more than the ability to set an annotation on an Ingress object your own build pipeline is going to create for a tenant's app. If your provisioning path lets tenant-supplied values reach that annotation unfiltered, the "attacker" is just a customer's deploy, and the payoff is every Secret your ingress controller's service account can read — not just that tenant's.

That's the concrete reason "patch to the latest tag and move on" isn't the whole answer here. The fix has to be paired with a real answer to "whose controller instance, provisioned when, running which tag, patchable by whom" across every tenant namespace — not just the platform team's own. If your PaaS is bex.co, that auditing surface is a single owned Kubernetes fleet with predictable, script-able provisioning — the four commands above are meant to run as a fleet sweep, not a one-off check, and a platform built to run on infrastructure you actually control is exactly where that sweep is tractable instead of aspirational.

What to Actually Do About It​

Patch to a fixed tag today — that's non-negotiable and doesn't wait for a migration plan. If you need coverage for vulnerabilities disclosed after March 24, 2026 (CVE-2026-9256 among them, with more certain to follow given the annotation-injection pattern isn't fully closed), that means moving to Chainguard's fork or another maintained distribution, because the official lineage stops at v1.15.1 forever.

But treat that as a bridge, not a destination. A best-effort fork with no SLA and no free images is a reasonable stopgap for a quarter, not a permanent security posture for infrastructure sitting in front of every tenant's Secrets.

Put a real date on migrating to the Gateway API — the sanctioned long-term replacement — or to an actively maintained controller like F5's NGINX Ingress Controller, Traefik, or an Envoy Gateway implementation. ingress2gateway exists specifically to make that migration mechanical rather than a rewrite. The point of a deadline is that "we'll get to it" is exactly the decision process that turned a five-month retirement notice into three RCEs disclosed in its final six weeks.

The Actual Lesson Isn't "Patch Faster"​

The uncomfortable finding here isn't that ingress-nginx had bugs — every piece of software this size does. It's that "the maintainers stopped" and "the security work stopped" turned out to be two different claims, and the gap between them didn't close, it just changed who was responsible and under what terms. For roughly half the Kubernetes ecosystem still running this controller, the actual security posture right now is: patched by a fork with no obligation to keep going, for a vulnerability class the original maintainers themselves called unfixable. That's worth knowing before the next CVE in this family shows up — not after.

Bex.co is the open-source, AI-native Render alternative — push a git repo, get a running HTTPS service on machines you own, with Ingress provisioning you can actually audit end to end. Star the repo on GitHub or deploy your first app today.

Sources​

• CVE-2026-3288: ingress-nginx rewrite-target nginx configuration injection — Kubernetes Issue #137560
• Detecting CVE-2026-3288 & CVE-2026-24512 — Sysdig
• CVE-2026-3288 Detail — NVD
• CVE-2026-24512: ingress-nginx rules.http.paths.path nginx configuration injection — Kubernetes Issue #136678
• CVE-2026-4342: ingress-nginx comment-based nginx configuration injection — Kubernetes Issue #137893
• Ingress NGINX Retirement: What You Need to Know — Kubernetes Blog
• The End of an Era: Transitioning Away from Ingress NGINX — Google Open Source Blog
• Fork Yeah: We're keeping ingress-nginx alive — Chainguard
• Introducing Chainguard EmeritOSS — Chainguard
• Release controller-v1.15.6 — chainguard-forks/ingress-nginx
• CVE-2026-9256 — NVD
• Emerging Threat: CVE-2026-9256 NGINX Heap Buffer Overflow via Rewrite Module — CyCognito