Kubernetes leadership warns of Ingress NGINX risks, but has also hastened its deprecation

The Kubernetes Steering and Security Response Committees has warned about the risks of continuing to run Ingress NGINX, which will receive no security patches from March 2026. “We cannot overstate the severity of this situation or the importance of beginning migration to alternatives,” said an official statement on the matter, though despite the severity, recent offers of help have been rejected as coming too late, and the leadership has pushed for a more rapid deprecation than maintainers wanted.

According to the statement, “roughly 50 percent of cloud native environments currently rely on this tool,” accounting for the strength of the warning, and users may not notice since existing deployments will continue to work and “you may not know you are affected until you are compromised.”

The statement also acknowledged that none of the available alternatives are drop-in replacements and that planning and engineering time is required.

Issues with lack of maintainers and contributors for the open-source Ingress NGINX have been known for some time, but came to a head at the KubeCon event in Atlanta, USA in November 2025. At a session titled “To InGate and beyond Ingress-nginx” maintainers James Strong and Marco Ebert announced the cessation of development effort on both Ingress NGINX and InGate, which was originally intended to be its successor. The first slide at the presentation stated, “Not the title you expected.”

The core problem, the maintainers said, was unreasonable pressure on them as volunteers and the lack of others stepping up to help. The InGate project never really got started, they said, with just one developer. “People weren’t as excited about InGate and Gateway API as we thought they would be,” they reported.

Considering the severity of the warning, it was surprising to discover from a discussion on the matter that Kubernetes leadership pushed for development to cease earlier rather than later. “When we talked about the deprecation date, there were some folks who wanted us to do it that week in Atlanta,” said Strong. “We pushed for about a year or so, we were able to reconcile and get the four months.” The last release is now planned to coincide with KubeCon Europe in Amsterdam, 23-26 March.

As so often with Kubernetes, it is a complex situation. Kubernetes is an API, for which there are many implementations. The Ingress API routes network traffic to different backend services based on user configuration. This API is frozen and the project recommends using its successor, the Gateway API, instead, though the Ingress API is stable and will remain. “Gateway API is a much more complete API in the sense of features,” said RedHat’s Ricardo Katz, who is one of its maintainers (and a former Ingress NGINX maintainer). That said, many of the features of Ingress NGINX come in the form of annotations which add things that are not in the Ingress API specification.

“If you are speaking just about the Ingress NGINX without any annotations, Gateway API can do everything,” said Katz, but because of the annotations, “there are a lot of things that Ingress NGINX can do that Gateway API cannot do yet, and some Gateway API will never do.”

The annotation issue means that even migration to another Ingress API implementation is not straightforward. For example, even F5 NGINX Ingress, an alternative which also uses the NGINX engine, has different annotations and a migration guide.

Ingress NGINX was one of the earliest implementations of an ingress controller for Kubernetes and was referenced in documentation, such that it seemed the safe and default choice for a deployment, and built on the popularity of the NGINX web server. With hindsight though, the project “exposed too much of the NGINX config … the big downfall for us was allowing people to inject Lua scripts … any time you allow an end user to run arbitrary code, you’re going to have security issues, and we did,” said Strong.

Pressure on the small maintainer team increased with the discovery of Ingres Nightmare, a remote code execution vulnerability caused by the ability to inject “an arbitrary NGINX configuration remotely,” as reported by Wiz security in March 2025.

“Not having more maintainers ended up burning me out and burning James out, and that’s something we need to speak out on open source,” said Katz.

Following KubeCon Atlanta, there have been offers of help, but a post from Kubernetes steering committee member Benjamin Elder said that “even if the maintainers of this project agreed to hand it over to someone new, the Kubernetes project has decided jointly between the sponsoring SIG [special interest group], Ingress-Nginx Maintainers, the Security Response Committee, and the Steering Committee, that we must wind down this project.”

Building trust to maintain critical software takes time, Elder said, and the offers needed to happen years ago, not at the last minute. “Nobody wanted this outcome and we are all just trying to mitigate the situation, generally in our spare time.”

Asked what users facing migration challenges should do, Strong said, “contribute, get involved. If you have a need for a feature, go to the Gateway API meetings and speak up.”

Options for other controllers include Envoy Gateway (which integrates with Envoy Proxy), Traefik and Cilium. There are also forks of Ingres NGINX to which users can switch at their own risk, and SuSe is offering two years of support for paying customers.