By Guests: Kat Cosgrove | Tabitha Sable
Organization: CNCF
Show: KubeStruck
Topic: Kubernetes
The Kubernetes community is executing an emergency shutdown of one of its most widely deployed components—and the clock is ticking. Ingress NGINX, a critical networking component used by roughly 50% of production Kubernetes environments, is being retired at the end of March 2026 due to an unsustainable maintenance deficit. No more security patches, no more bug fixes, nothing. For organizations that don’t migrate before the deadline, this isn’t just an inconvenience—it’s a serious security vulnerability waiting to be exploited.
📹 Going on record for 2026? We're recording the TFiR Prediction Series through mid-February. If you have a bold take on where AI Infrastructure, Cloud Native, or Enterprise IT is heading—we want to hear it. [Reserve your slot
Kat Cosgrove from the Kubernetes Steering Committee and Tabitha Sable from the Kubernetes Security Response Committee sat down with TFiR to explain what went wrong, what’s at stake, and how organizations can protect themselves before time runs out.
The Maintenance Crisis That Couldn’t Be Solved
The shutdown was first announced at KubeCon Atlanta in November 2025, giving the community roughly six months to migrate. The problem? Years of publicly asking for maintainers from the community and from vendors whose services depend on Ingress NGINX went unheeded.
“For several years, the project has publicly shared that it has a significant maintenance deficit and has been trying to attract maintainers from the community—or from the numerous vendors who host services that depend on Ingress NGINX,” Tabitha Sable explains. “Unfortunately, all of those calls have gone unheeded.”
Ingress NGINX serves a fundamental purpose in Kubernetes environments: it routes external traffic to application workloads running inside clusters. As Sable describes it, you need some way to get traffic from the outside world into workloads that are supposed to be exposed outside the cluster. Ingress NGINX became popular precisely because it’s flexible and works in almost any environment, unlike solutions requiring specific cloud providers or load balancer brands.
But that flexibility became its fatal flaw.
Why More Maintainers Wouldn’t Fix the Problem
Even if every vendor suddenly contributed full-time engineers, it wouldn’t solve the fundamental issue: Ingress NGINX has outgrown its own architecture.
“The way Ingress NGINX was designed—with all of that flexibility—was a really good thing a decade ago. It’s not now,” Cosgrove says. “Now it’s a mountain of technical debt. It’s an enormous security problem. The way the alternatives are built makes them easier to maintain, at least for now.”
The core issue is architectural. Ingress NGINX wraps the powerful nginx web server and attempts to provide a safe subset of its configuration capabilities to Kubernetes administrators. But as Sable points out, that’s a theoretically impossible problem to solve perfectly: “Nginx is an extremely powerful piece of software, built around a security model that assumes the configuration is always completely controlled by a trusted global administrator. Ingress NGINX’s job is to take that and provide a safe subset to a mostly trusted set of administrators. In a mathematical sense, that problem is impossible.”
The project managed to keep it “close enough to being safe” through constant vigilance and rapid patching. But that requires continuous maintenance—which is exactly what’s disappearing.
The Security Risk: Not If, But When
The danger isn’t in the software dependencies you can update with a container rebuild. It’s in vulnerabilities within Ingress NGINX’s own code that won’t have anyone to patch them.
“After we are no longer maintaining it, the biggest concern is with the possibility of vulnerabilities in the Ingress NGINX code itself being discovered and there not being anyone to patch them,” Sable warns. “As long as somebody hasn’t found any new vulnerabilities in Ingress NGINX, you’re fine. But if two years from now, somebody finds another terrible thing, then that’s going to be a mad scramble.”
The CVEs released just before this interview demonstrate how severe the consequences can be. CVE-2025-1974, for example, could give attackers anywhere from access to secrets in a single namespace to full cluster administrator permissions—depending on how the deployment was configured. “Most cloud native companies would struggle to come back from an attacker who escalated to cloud admin privileges and deleted their entire prod environment,” Sable notes.
Migration Options: Gateway API and Beyond
The recommended path forward is Gateway API, a more modern implementation of the same traffic routing functionality. It’s more secure by design and addresses the architectural problems that made Ingress NGINX unmaintainable.
“Start switching to Gateway API,” Cosgrove urges. “It’s a more modern implementation. It may take more work to migrate over to Gateway API—it’s not as clean cut, it’s not just a drop-in replacement—but it is a more modern way to do what Ingress NGINX was trying to do.”
For organizations with complex deployments using dozens of custom annotations, the migration could be challenging. The community has developed tools like Ingress2Gateway to automate basic migrations, but highly customized implementations will require engineering work.
There are also numerous third-party ingress controllers available—every cloud provider and load balancer vendor offers one, along with several vendor-neutral software options. The key is choosing something that’s actively maintained.
The Broader Wake-Up Call
Beyond the immediate crisis, this shutdown exposes a critical gap in how the industry thinks about open source sustainability.
“For a long time, we’ve considered big companies or end user companies that rely on open source not contributing back to be a moral issue,” Cosgrove says. “But now, I think it’s very easy to make the argument that not contributing back to open source is, in fact, a security issue. You have to start considering open source contributions as part of your security plan. We are an attack surface, so you have to take care of us too.”
The Ingress NGINX shutdown is performing what Sable calls “an emergency landing.” Organizations have until the end of March to exit the project in an orderly fashion. After that, any newly discovered vulnerability will leave affected systems exposed with no upstream fix available.
For technical leadership teams, the message is clear: if you rely on critical open source infrastructure, passive consumption is no longer an option. You either contribute to maintaining it, or you accept the security risk of eventual abandonment.
