Kubernetes SIG Network and the Security Response Committee announced that Ingress NGINX maintenance would stop in March 2026, with no further releases, bug fixes or security updates afterward. Check whether you run it, then plan a move to Gateway API or another maintained controller.
What was announced
The Kubernetes blog post of 11 November 2025 says best-effort maintenance would continue until March 2026. After that, there would be no more releases, no bugfixes and no updates for vulnerabilities found later. Existing deployments keep working, and artifacts such as Helm charts and images stay available. The repositories become read-only.
The post gives reasons. It describes flexibility that was once helpful but is now seen as a serious security flaw, naming the ability to add arbitrary NGINX configuration through snippets annotations. It also says the project had only one or two maintainers working in their own time. The planned replacement project, InGate, never matured and will also be retired.
How to check your clusters
The announcement gives a command that works in most cases, run with cluster administrator permissions:
kubectl get pods --all-namespaces --selector app.kubernetes.io/name=ingress-nginx
A result means you run it. An empty result does not prove you do not: some managed platforms package it differently, and labels can be changed. Also check your Helm releases and any cluster add-on lists, and ask platform teams.
Why an unmaintained controller is a risk
An ingress controller sits at the edge and translates routing rules into proxy configuration. It receives traffic from the internet and holds credentials such as TLS keys and access to cluster resources. If a flaw is found after maintenance stops, there is no upstream patch. Earlier controller flaws are well documented; see our ingress controller vulnerability roundup. A component with that position and no patch path is a priority to replace.
A migration plan
- Inventory. Find every cluster, controller and Ingress resource that uses it.
- Find annotation use. List annotations that carry NGINX specific behavior, especially snippets, because they will not translate directly.
- Choose a target. The announcement recommends Gateway API or another Ingress controller from the Kubernetes documentation list.
- Run in parallel. Stand up the new controller beside the old one and route a test hostname through it.
- Move by hostname. Shift traffic gradually with DNS changes and watch error rates.
- Restrict meanwhile. Until you finish, limit who can create or edit Ingress objects and block snippet annotations with admission policy.
- Remove the old controller and its credentials when traffic is gone.
What not to do
Do not treat "it still works" as safe. Do not copy annotations blindly into a new controller without checking what each one does. And do not leave the old controller installed but idle, since an unused exposed component is still attack surface.
Try it yourself
Click through it at your own pace, or open it full screen.
Click through the monitoring demo and look at how a new advisory against a component you already run is surfaced after the original scan.
Quick check
Will my existing Ingress NGINX deployment stop working?
The announcement says existing deployments will not be broken and artifacts stay available. What stops is maintenance, including security fixes.
What does the announcement recommend instead?
It recommends migrating to Gateway API, or to another Ingress controller from the options listed in the Kubernetes documentation.
Why were snippets annotations called out?
The post describes the ability to add arbitrary NGINX configuration directives as an option that is now considered a serious security flaw.
Where Safeguard fits
Safeguard's asset discovery and image scanning help you find controller images in your estate and flag known vulnerable versions, and continuous monitoring keeps checking as new advisories arrive. Start with a free scan.
Sources
Last reviewed: 19 October 2026.
