A controller half of Kubernetes depended on is gone
On March 24, 2026, the Kubernetes project archived the ingress-nginx repository. No more releases, no more bug fixes, no more security patches, ever. The decision was not sudden. Kubernetes SIG Network and the project's Security Response Committee first announced the plan to retire the controller in November 2025, then reissued a joint statement in January reinforcing the timeline after it became clear adoption of the replacement was moving too slowly. By the time the repository went read-only in March, the project had been sustained for years by what Kubernetes' own steering committee has said was effectively one or two volunteers working through a backlog no single team could keep up with.
The reason this is more than open source housekeeping is scale. Ingress-nginx routes traffic into roughly half of all Kubernetes clusters in production, according to the same Kubernetes security leadership research cited when SiliconANGLE covered the transition in March. That is the default ingress controller for a huge share of the clusters running on EKS, AKS, GKE and self-managed infrastructure alike, not a niche tool.
The bug that landed on the way out the door
Nine days before the archive, on March 19, 2026, the project shipped a fix for CVE-2026-4342, a high-severity configuration injection flaw (CVSS 8.8) that let an attacker chain Ingress annotations to inject arbitrary nginx directives, potentially leading to code execution inside the controller and disclosure of any Kubernetes secrets it could read. The fix landed in versions 1.13.9, 1.14.5 and 1.15.1, and the Kubernetes security team pushed the advisory hard: anyone still on an older version needed to upgrade immediately, because after March 24 there would be no one left to ship a second warning, let alone a second patch.
That is the part worth sitting with. The vulnerability itself got fixed. The problem is what it revealed about the state of adoption: clusters running versions below those fixed releases had exactly one more chance to patch before the safety net came off permanently. Any new vulnerability discovered in ingress-nginx from March 24 onward, and there will be one eventually given the size of the install base, has no upstream owner to file it against.
Hyperscalers are pointing at their own ingress, not a neutral fix
The three major clouds responded with migration guidance rather than a shared alternative, which tells you something about how fragmented this transition actually is. AWS published a guide steering EKS customers toward the AWS Load Balancer Controller, walking through how to move Ingress objects over without a traffic-affecting cutover. Google's Open Source blog framed the retirement as the end of an era and pointed GKE users toward GKE's native Gateway support. None of this is coordinated the way, say, a Kubernetes version bump is: each hyperscaler is migrating customers toward its own managed ingress path, and workloads that move across clouds inherit three different answers to the same question.
The neutral option is the Gateway API, the CNCF-backed successor to the Ingress resource that has been in development for years specifically to replace the annotation sprawl that made ingress-nginx configuration so brittle in the first place. Gateway API v1.5 shipped February 27, 2026, promoting several long-experimental features, including TLSRoute and ListenerSet, to its stable Standard channel. To make the actual migration mechanical rather than manual, Kubernetes SIG Network shipped ingress2gateway 1.0 on March 20, four days before the archive, a command-line tool that converts existing Ingress objects and vendor annotations into Gateway API resources for more than 30 documented annotation patterns.
What ten weeks of runway has actually produced
Two and a half months on, the honest read is that the tooling caught up faster than the clusters did. Gateway API is stable, ingress2gateway exists and covers the common annotation patterns, and every major cloud has published its own migration path. What has not moved at the same pace is actual cluster inventory: platform engineering blogs, vendor guides and conference talks through the spring have all converged on the same warning, that a large share of production clusters are still running an ingress controller with no maintainer, no patch pipeline and no security advisory process behind it. Kubernetes' own Ingress API resource has not been removed and still works, but it is feature-frozen, so anything built on it going forward is building on a dead end.
None of this requires an outage to matter. The risk sits quietly until the next bug shows up in code nobody is watching anymore, at which point it becomes everyone's problem simultaneously, the way it briefly did in the days before March 24.
Why this belongs on a buyer's radar, not just an SRE's
For anyone who owns infrastructure budget rather than infrastructure YAML, the practical takeaway is narrower than the technical story: if your platform team has not confirmed which ingress controller is actually running in production, and whether it is one of the roughly half of clusters that defaulted to ingress-nginx, that is now a security and continuity question, not a backlog item. The migration tooling exists. The unresolved variable is whether it gets used before the next unpatched bug does the asking for you.
Sources: Kubernetes SIG Network statement · Google Open Source Blog · AWS migration guide · CVE-2026-4342 advisory · Kubernetes issue tracker · Gateway API v1.5 release notes · SiliconANGLE · The New Stack