CNCF Ingress Nginx retirement could leave some users at risk
Some industry observers are concerned that users of the Ingress Nginx Kubernetes sub-project might not realize it's vulnerable until their environments are compromised.
A widely used Kubernetes sub-project reached the end of its community support on March 13, potentially leaving some deployments vulnerable unless their owners take immediate action to replace it.
Ingress Nginx is an ingress controller that manages external network traffic routing to services within Kubernetes clusters. As such, it is also often used to enforce security policies on inbound traffic. A January statement by the Cloud Native Computing Foundation (CNCF) said that research by member company Datadog indicated approximately half of cloud-native application deployments still use the project.
The project's final release was on March 13, with updates to support Kubernetes version 1.35 and to patch a critical vulnerability. No further critical vulnerabilities and exploits will be patched by the project's original maintainers, and no bug fixes or feature updates will be added, according to the January statement.
"This cannot be ignored, brushed off or left until the last minute to address," the CNCF's statement said. "We cannot overstate the severity of this situation or the importance of beginning migration to alternatives like Gateway API or one of the many third-party Ingress controllers immediately."
Vulnerable deployments will keep running
The decision to retire Ingress Nginx was officially publicized during KubeCon in November 2025, but one user in a highly regulated environment said he didn't hear the news until last month, leaving him without enough time to swap out the component due to his required change management process. Worse, there is no drop-in replacement for Ingress Nginx; any migration will involve substantial changes to critical network infrastructure.
Heinan Cabouly
"Gateway API is good technology … but [it] is not a new version of the Ingress API. It’s a fundamentally different resource model with different assumptions about how traffic routing should work," according to a February blog post by Heinan Cabouly, DevOps team lead and architect at a medical device company based in Israel and the U.S. that he requested not be named due to policies prohibiting him from representing it in the press.
Cabouly estimated in an interview with Informa TechTarget that the migration in an environment subject to US FDA and EU Medical Device Regulation compliance will take approximately nine months, but it was six months between the CNCF's announcement that it would retire Ingress Nginx and its final release. Cabouly was also critical of CNCF's communication about the change, saying it had not been proactive enough.
"Because we are regulated, our upgrade guidance is a bit slower, so we noticed it quite a bit later, when we upgraded to Kubernetes 1.35," he said in the interview. "The message itself, the content was right. The timing was a bit too late for us."
Other industry experts said cases like Cabouly's are relatively rare, and that many companies had already moved to the Gateway API or another newer project well in advance of the Ingress Nginx retirement.
[Some users] could be told today that something is incredibly insecure, it's likely to be compromised, and ignore that, and say, 'But it still works at the end of the day.' That's a serious problem.
Nigel Douglas, Head of developer relations, Cloudsmith
"I haven’t seen an immediate impact -- systems keep running, so it’s not showing up as an operational issue yet," said Varun Raj, head of private cloud platforms, AI platforms, infrastructure and enterprise workloads for a global consulting firm. "What it’s really exposing is maturity. Teams with strong platform engineering practices are already migrating or testing alternatives. Others are deferring because there’s no immediate pressure."
But the fact that systems still using Ingress Nginx will keep running is exactly what has others in the community worried.
"A lot of organizations aren't going to shift away from it -- even though it's got known vulnerabilities that are being exploited -- for the same reason they didn't shut it off two or three years ago, which is that it worked two or three years ago, and it still works now," said Nigel Douglas, head of developer relations at CNCF member company Cloudsmith and a former contributor to the Falco CNCF project, in an interview this week. "Replacing it with another technology means all your APIs need to communicate correctly. The CRDs [custom resource definitions] there need to be reliable. [Some users] could be told today that something is incredibly insecure, it's likely to be compromised, and ignore that, and say, 'But it still works at the end of the day.' That's a serious problem."
Nginx Ingress case fans open source sustainability fears
Ingress Nginx uses the original Kubernetes Ingress API, which has been replaced by the Gateway API that reached a stable release in 2023; CNCF projects such as Istio have supported the Gateway API since 2022. The Ingress API handles basic application-level HTTP traffic routing, leaving more advanced traffic management to various ingress controllers using separately configured custom extensions. The Gateway API, by contrast, supports more network protocols, such as TCP, UDP and gRPC, and includes a standardized set of definitions for controller capabilities.
Moreover, according to a November 2025 CNCF statement, the Ingress Nginx architecture contains inherent vulnerabilities, namely in the use of arbitrary configuration annotations called "snippets" that could potentially be hijacked by a bad actor to gain control over an environment. The project had also been under-resourced for years, relying on just two unpaid maintainers for patches and bugfixes, according to the statement.
There are workarounds for users such as Cabouly. He is evaluating F5 Networks' commercial version of Ingress Nginx in his company's development and staging Kubernetes clusters, and temporarily switched to the AWS Load Balancer Controller for production Amazon EKS clusters.
Other alternatives include Traefik, HAProxy Ingress, Cilium Gateway, Envoy Gateway and Kong Ingress. Software supply chain security vendor Chainguard is also maintaining a secure open source fork of Ingress Nginx, though it will not be adding feature updates.
But Cabouly said the Ingress Nginx retirement is just the latest in a series of forced migrations among the open source infrastructure projects his company once relied on, mostly in the form of license changes to projects such as MongoDB, HashiCorp Terraform and MinIO.
While the Ingress Nginx retirement played out differently, to Cabouly it raised the same questions about open source sustainability in general, and why the CNCF's top-level member companies hadn't stepped in to contribute more to the project when maintainers were asking for help.
"The default networking component for half of all Kubernetes installations … was maintained by one or two people working nights and weekends. For years," Cabouly wrote in his blog post. "While every major cloud provider built managed Kubernetes services on top of it, charged enterprise customers for it, and generated quarterly earnings reports bragging about Kubernetes adoption numbers."
Chris Aniszczyk
CNCF does not mandate a single development path for projects, maintains a clear separation between foundation leadership and project maintainers, and neither the CNCF Governing Board nor the Technical Oversight Committee directly manages CNCF-hosted projects, according to a statement sent to Informa TechTarget this week by CNCF CTO Chris Aniszczyk.
"What we do provide is a structured maturity framework -- from Sandbox to Graduated -- which acts as a roadmap without the friction of rigid, one-size-fits-all governance," Aniszczyk wrote. "We also provide project health tools via https://insights.linuxfoundation.org, on which we publish transparent data on the health of projects; that data is available to everyone to make judgment calls on what to do."
Cabouly said his company and clients of his consulting firm, HT DevOps Ltd., will be subjecting open source projects to more scrutiny going forward. This actually began with his company's switch from HashiCorp Terraform to OpenTofu after HashiCorp's shift to a business source license.
"We contacted OpenTofu to ask, 'Who are the backers? What is the roadmap?' to make sure that we won't make the switch and then get left in the wild again," he said.
Beth Pariseau, a senior news writer for Informa TechTarget, is an award-winning veteran of IT journalism. Have a tip? Email her.
Heinan Cabouly
Chris Aniszczyk
