Dora NodaOn January 29, 2026, the Kubernetes Steering Committee and the Security Response Committee published a joint statement containing a sentence you almost never see from a project that size: "Half of you will be affected. You have two months left to prepare." They were talking about ingress-nginx — the ingress controller routing traffic into about half of all cloud-native environments — and they were telling everyone still running it to start migrating immediately, because in March 2026 the project would be retired with no further releases, bugfixes, or security patches of any kind.
That statement was not a CVE, not a deprecation notice, and not a routine end-of-life reminder. It was an institutional warning: two governing bodies of the Kubernetes project jointly telling operators that a component sitting directly in their request path could no longer be kept secure, full stop. If you run a self-hosted PaaS, the question it posed is still the live one months later: do you keep defaulting tenant routing to a controller its own project declared unmaintainable, or do you front-load the Gateway API migration your fleet will need anyway? The statement's own answer was unambiguous, and the months since have only confirmed it. But the more durable lesson is how to read the next warning like it — because ingress-nginx will not be the last request-path component to fail this way.
Anatomy of an escalation ladder
The January statement did not come out of nowhere. It was the second rung of a deliberate, public escalation, and each rung carried a different obligation:
| Date | Signal | What it obligated |
|---|---|---|
| Nov 11, 2025 | SIG Network and the Security Response Committee announce the retirement: best-effort maintenance until March 2026, then nothing | Start evaluating alternatives; stop building new dependencies on ingress-nginx behavior |
| Jan 29, 2026 | The Steering Committee and SRC issue a joint statement: "choosing to remain with Ingress NGINX after its retirement leaves you and your users vulnerable to attack" | Begin migration planning now; treat every week of delay as accepted risk |
| Mar 20, 2026 | SIG Network ships ingress2gateway 1.0, converting 30+ annotations to Gateway API | Execute the migration with tooling instead of hand-rewriting |
| Mar 24, 2026 | The repository is archived read-only; v1.13.9 / v1.14.5 / v1.15.1 are the last releases ever | You are now your own vendor for every future flaw in that codebase |
Note what escalated between November and January: not the facts — the retirement date never moved — but the messenger. A SIG announcing its own project's sunset is routine open-source hygiene. The Steering Committee co-signing a security warning is the project telling you the routine framing no longer applies. When governance speaks instead of maintainers, the message is that the normal mechanisms (find contributors, fund maintenance, fork) have already been considered and exhausted.
The sentence that kills every "wait and see" strategy is the one explaining why: "With the technical debt that has piled up, and fundamental design decisions that exacerbate security flaws, it is no longer reasonable or even possible to continue maintaining the tool even if resources did materialize." Read that carefully. It does not say "we lack maintainers" — a resourcing problem a sponsor could fix. It says the design itself, chiefly the snippet annotations that inject raw nginx directives from Ingress objects, made the tool unmaintainable at any staffing level. No corporate rescue, no community fork, no extended-support contract changes that verdict, because the verdict is about the architecture, not the headcount.
Why a governance warning hits a PaaS harder than a CVE
A single CVE has a bounded blast radius: assess exposure, patch, rotate what leaked, move on. The March 2025 IngressNightmare chain (CVE-2025-1974 and four siblings, CVSS 9.8, unauthenticated remote code execution through the admission webhook, over 6,500 clusters exposed) was about as bad as a CVE gets — and it was still patchable. You upgraded the controller and the incident ended.
A governance warning is unbounded in a way that lands hardest on platforms rather than individual clusters. Three reasons:
Position. An ingress controller terminates every byte of tenant traffic. It parses untrusted input (hostnames, paths, headers, TLS) by design, runs with privileges broad enough to reconfigure the data plane, and in ingress-nginx's case generated its own configuration by string-interpolating annotation values into nginx config files. There is no more exposed seat in the architecture. A PaaS that defaults to a controller the upstream project calls unsecurable has put its weakest-link component exactly where attackers look first.
Multiplication. One team running ingress-nginx on one cluster absorbs one copy of the risk. A PaaS running it as the default across a fleet absorbs that risk once per tenant, and — this is the part operators underestimate — owes the migration to people who never chose the component. Your tenants picked your platform, not your ingress controller. When the retirement countdown started, the engineering work of migrating belonged to you whether or not your tenants had ever heard of ingress-nginx.
You are the vendor now. After March 24, 2026, every new flaw in that codebase is yours to triage, backport, and ship — or to knowingly carry. That is precisely what happened: the annotation-sanitization defect behind CVE-2026-24512 needed two more patches (CVE-2026-3288 and CVE-2026-4342) across the final weeks, and flaws disclosed after archival, like the nginx rewrite-module overflow backported only by Chainguard's EmeritOSS fork, simply have no official fix. We traced that whole timeline in our CVE-2026-3288 post; the short version is that "unmaintained" turned out to mean "patched by whoever volunteers, under no obligation to you."
The decision matrix: what to default to
For a self-hosted PaaS, there are really three routing-layer decisions, not one, and the joint statement answers each differently:
| Situation | Default | Rationale |
|---|---|---|
| Greenfield platform or new fleet | Gateway API from day one | No migration debt; every conformant implementation you might adopt later speaks the same API |
| New tenants on an existing ingress-nginx fleet | Gateway API for new tenants, side-by-side | Stops the growth of the liability while the existing base migrates on its own schedule |
| Existing tenants still on ingress-nginx | Planned migration, not indefinite coexistence | The risk compounds weekly — compliance tooling already flags EOL ingress-nginx — and coexistence doubles the request-path code you must secure |
Two honest objections deserve direct answers.
"Why Gateway API instead of another Ingress controller?" Because the Ingress API is a flat, annotation-driven resource whose expressiveness lives in vendor-specific strings — the exact pattern that made ingress-nginx unsecurable. Gateway API replaces annotations with typed, API-server-validated fields across Gateway, HTTPRoute, and policy attachment, with conformance profiles so implementations are tested against the same bar. It is also where the ecosystem already moved: Gateway API v1.5, released April 2026, promoted ListenerSet, TLSRoute, the HTTPRoute CORS filter, client-certificate validation, and TLS-origination certificate selection to the Standard (GA) channel, and ReferenceGrant graduated to v1. The migration target is not a beta experiment; it is the stable API the controller ecosystem now builds against.
"Which implementation?" That is the right question to ask, and the honest answer is that several are credible — Envoy Gateway, Cilium's Gateway API support, Traefik, and NGINX Gateway Fabric among them — which is itself the point: Gateway API's conformance-tested portability means the choice is reversible in a way the ingress-nginx default never was. Pick the implementation whose data plane and operational model fit your fleet (eBPF-native if you already run Cilium, Envoy-based if you want the reference-adjacent path), run ingress2gateway 1.0 against your live Ingress objects to scope the conversion, and budget real engineering time for the annotations it flags as untranslatable. There is no drop-in replacement — the joint statement said so explicitly — and any plan priced as one is underfunded. For the annotation-by-annotation mechanics, see our ingress2gateway breakdown.
The never-again policy: five checks for request-path dependencies
The deepest lesson of the ingress-nginx retirement is not "migrate to Gateway API." It is that a self-hosted PaaS needs a standing policy for components in its request path, so the next retirement arrives as a tracked risk instead of a two-month fire drill. Five checks, applied to every dependency that parses untrusted traffic:
- Bus factor and funding. How many active maintainers, and who pays them? Ingress-nginx ran for years on one or two unpaid volunteers. A request-path component with a bus factor of one is not a dependency; it is a countdown.
- Governance home. Is the project owned by a SIG with a charter, a vendor with a support contract, or nobody in particular? Know which body would announce its end — and subscribe to that body's announcements, not just its release feed.
- Design auditability. Can you explain how untrusted input becomes data-plane configuration? String-interpolated config generation from user-controlled annotations is the pattern that killed ingress-nginx. Typed, validated APIs are not just ergonomics; they are the security boundary.
- CVE velocity and fix completeness. One critical CVE is an incident. A chain of bypasses across successive patches — the CVE-2026-24512 → 3288 → 4342 sequence — is evidence the flaw is architectural. Track whether fixes close the class or just the instance.
- Exit cost, measured annually. Run the migration tooling (ingress2gateway, or your stack's equivalent) once a year against production state and record what it cannot convert. Exit cost discovered during a retirement countdown is always higher than exit cost tracked as a metric.
None of these checks requires predicting the future. All of them were readable about ingress-nginx by mid-2025: the maintainer warnings were public, the snippet-annotation risk was documented, and IngressNightmare had already demonstrated the blast radius. The operators who migrated calmly were not luckier; they were subscribed to the right signals.
The January 29 statement will read, in retrospect, as the moment the Kubernetes project established a new precedent: when a critical component cannot be secured, leadership says so plainly, names the blast radius, and sets a date. That is a healthier ecosystem behavior than silent decay — but only operators who treat governance signals as operational input get the benefit. Audit your request path against the five checks above, default every new tenant to Gateway API, and put the next retirement on your roadmap before it puts itself there.
Bex.co is the open-source, AI-native Render alternative — push a git repo, get a running HTTPS service on machines you own. Star the repo on GitHub or deploy your first app today.
