Ingress NGINX Is Retired: What Replaces It and How to Choose in 2026

Most Kubernetes clusters I have been asked to look at over the past decade had the same thing sitting at the edge: Ingress NGINX, installed from a Helm chart years ago and never thought about again. That controller is now retired. The Kubernetes project stopped maintaining it in March 2026, archived the repository, and will not ship another patch, even for a critical CVE. If you still run it, your edge proxy is unmaintained software holding a service account that can read every Secret in the cluster. This post covers what the Ingress NGINX retirement actually means, why the security history forced it, where Gateway API stands as the replacement in October 2026, and how I would choose between the main implementations. The hands-on steps are in the companion guide, How to Migrate From ingress-nginx to Gateway API.

Is Ingress NGINX really retired, and what does that mean?

Yes. Kubernetes SIG Network and the Security Response Committee announced the retirement on 11 November 2025: best-effort maintenance until March 2026, then "no further releases, no bugfixes, and no updates to resolve any security vulnerabilities". The planned replacement controller, InGate, never matured and was retired alongside it. On 29 January 2026 the Steering Committee and the SRC published an unusually blunt joint statement, citing Datadog research that about 50% of cloud native environments rely on the controller and warning that "you may not know you are affected until you are compromised".

The final releases shipped on 19 March 2026: controller v1.15.1, v1.14.5 and v1.13.9, each carrying a security fix. The GitHub repository is now archived and read-only, and its README opens with a usage warning telling new users not to deploy it.

Three things did not change, and they explain why so many clusters still run it:

• Existing deployments keep working. Nothing stops serving traffic on a date.
• Images and Helm charts remain downloadable from registry.k8s.io and the chart repository.
• The Ingress API itself is not going away. The Kubernetes docs say the Ingress API has been frozen, is still GA, and has no planned removal. Only this one controller is retired.

"Ingress is deprecated" is a common misreading. You can keep Ingress objects with another controller; what you cannot safely keep is this controller.

Ingress NGINX (kubernetes/ingress-nginx) is not F5's NGINX Ingress Controller, as the Kubernetes pre-migration post stresses. F5's product is still maintained.

Check whether you are affected with the command the SRC has published in every advisory, then look at the image tag:

# Find any Ingress NGINX controller pods (needs cluster-admin read access)
kubectl get pods --all-namespaces \
  --selector app.kubernetes.io/name=ingress-nginx \
  -o custom-columns='NS:.metadata.namespace,POD:.metadata.name,IMAGE:.spec.containers[0].image'

# Anything older than controller v1.13.9 / v1.14.5 / v1.15.1 is missing
# at least one published security fix (CVE-2026-4342).

# Count which nginx-specific annotations your Ingresses depend on.
# This list is your real migration scope.
kubectl get ingress -A -o json \
  | jq -r '.items[].metadata.annotations // {} | keys[]
           | select(startswith("nginx.ingress.kubernetes.io/"))' \
  | sort | uniq -c | sort -rn

IngressNightmare and the CVEs that ended the project

The retirement announcement was polite about the reasons: maintenance by "only one or two people", on their own time, and features such as snippet annotations that had turned from "flexibility" into "insurmountable technical debt". The CVE record is less polite.

On 24 March 2025, Wiz disclosed IngressNightmare, a chain of five vulnerabilities. The worst, CVE-2025-1974, was rated CVSS 9.8: the controller's validating admission webhook was an unauthenticated endpoint reachable from the pod network, and combined with annotation injection bugs it let anything on that network run code inside the controller. Because the controller's service account can read Secrets cluster-wide by default, that meant cluster takeover with no credentials. Wiz reported over 6,500 clusters exposing vulnerable admission controllers publicly. The fixes landed in v1.12.1 and v1.11.5.

The pattern did not stop. In the last seven weeks of the project's life, the SRC published seven more ingress-nginx CVEs, each tracked as an issue in the kubernetes/kubernetes repository:

Disclosed	CVE	Issue	CVSS 3.1	Fixed in
24 Mar 2025	CVE-2025-1974 (plus 4 related)	Admission webhook config injection, RCE	9.8	v1.11.5, v1.12.1
2 Feb 2026	CVE-2026-1580	auth-method config injection	8.8	v1.13.7, v1.14.3
2 Feb 2026	CVE-2026-24512	path config injection	8.8	v1.13.7, v1.14.3
2 Feb 2026	CVE-2026-24513	auth-url protection bypass	3.1	v1.13.7, v1.14.3
2 Feb 2026	CVE-2026-24514	Admission controller DoS	6.5	v1.13.7, v1.14.3
6 Feb 2026	CVE-2025-15566	auth-proxy-set-headers injection	8.8	v1.12.5, v1.13.1
9 Mar 2026	CVE-2026-3288	rewrite-target config injection	8.8	v1.13.8, v1.14.4, v1.15.0
19 Mar 2026	CVE-2026-4342	Comment-based config injection	8.8	v1.13.9, v1.14.5, v1.15.1

Almost every row is the same bug class: an annotation string lands inside a generated nginx.conf and someone escapes it. Templating user input into a configuration language makes this permanent whack-a-mole, and the next one found will not be fixed upstream.

Gateway API vs Ingress: what actually changes

Gateway API is the replacement the Kubernetes project recommends. The short version of the difference: Ingress is one object with a thin spec, and every controller bolted features on with annotations. Gateway API splits the job into roles and puts the common features into the spec.

• A GatewayClass names the implementation, usually installed by the platform team once.
• A Gateway declares listeners (ports, protocols, hostnames, TLS certificates). Infrastructure owners manage it.
• HTTPRoute (and GRPCRoute, TLSRoute, TCPRoute, UDPRoute) attach to a Gateway and hold the routing rules. App teams own these in their own namespaces.
• ReferenceGrant controls cross-namespace references, for example a route in one namespace pointing at a Service in another.

Things that needed nginx annotations are now typed fields: header matching, weighted backends for canaries, redirects, URL rewrites, request mirroring, timeouts, and since v1.5, CORS. The security benefit is structural. An app team cannot paste raw proxy configuration into a route, and a route only attaches to a listener that allows it. That is what killed snippet annotations, and it is simply not expressible here.

The trade-off is verbosity and some semantics that will bite you. The Kubernetes blog's five surprising behaviours post is required reading: ingress-nginx regex paths are case-insensitive prefix matches, use-regex and rewrite-target silently switch every path on the same host to regex, missing trailing slashes get a 301, and URLs are normalised before matching. A faithful translation of your YAML can still produce 404s where users used to get 200s.

Where Gateway API stands in October 2026

The project moves on a roughly quarterly cadence, and 2026 has been busy:

• v1.5.0 (27 February) graduated ListenerSet, the HTTPRoute CORS filter, client certificate validation, and TLSRoute v1 to the Standard channel, and moved ReferenceGrant to v1. It also added a safe-upgrades ValidatingAdmissionPolicy that blocks installing Experimental CRDs over Standard ones and blocks downgrades below 1.5. That policy surprises people during installs; the guide covers it.
• v1.6.0 (29 June) graduated TCPRoute and UDPRoute to GA and allowed BackendTLSPolicy with any route type.
• The current stable patch is v1.6.3 (6 October), and v1.7.0-rc.1 was tagged on 8 October.

ListenerSet is the one I care about most for ingress-nginx refugees. With plain Gateways, every hostname's TLS listener lives on a shared object owned by the platform team, which was awkward compared with Ingress, where each team brought its own tls: block. ListenerSet lets app teams attach their own listeners to a shared Gateway. cert-manager supports it, with feature gates in 1.20 and later.

The migration tool also grew up. ingress2gateway 1.0 shipped on 20 March with support for over 30 ingress-nginx annotations (up from three), integration tests that compare live controller behaviour rather than YAML, and pluggable "emitters" that can output implementation-specific policies for Envoy Gateway, kgateway and agentgateway. It is at v1.2.0 now. It is explicitly a migration assistant, not a converter you trust blindly: it warns you about everything it could not translate, and you should read every warning.

Gateway API implementations compared: which ingress-nginx alternative?

Every implementation listed below submitted a conformance report against Gateway API v1.6 to the upstream conformance directory, and all passed the core HTTP profile in that report. Conformance says the basics behave identically; it says nothing about the extension policies for rate limits, auth or body size, which is where the products differ.

Implementation	Data plane	Version in v1.6 report	Latest release (Oct 2026)	Pick it when
Envoy Gateway	Envoy	v1.9.0	v1.9.2	You want a standalone, vendor-neutral Envoy edge with rich policy CRDs
Cilium	Envoy, managed by Cilium	v1.20.0	v1.20.3	Cilium is already your CNI and you want one fewer component
Istio	Envoy	1.31	1.31.2	You run a mesh, or you are on AKS (its Gateway API add-on is Istio based)
NGINX Gateway Fabric	NGINX	v2.8.0	v2.8.0	Your team knows NGINX and wants that data plane behind a typed API
Traefik	Traefik	v3.7.10	v3.7.15	You need a bridge: it also reads ingress-nginx annotations
kgateway	Envoy	v2.4.5	v2.4.7	You want Envoy plus API gateway features (and its AI-traffic sibling, agentgateway)
GKE Gateway	Google Cloud load balancers	1.36.2-gke	managed	You are on GKE and want a managed edge

A few notes that do not fit a table. Traefik's Kubernetes Ingress NGINX provider lets you swap controllers while keeping your existing Ingress objects and many nginx.ingress.kubernetes.io annotations. Its own docs list the gaps: no session caching for forward auth, round-robin load balancing only, a token bucket rate limiter that returns 429 rather than 503, and opt-in request buffering. It is a reasonable bridge, not a way to avoid the migration.

On Azure, Microsoft says it will provide critical security patches for the AKS application routing add-on's NGINX resources only through November 2026, and points users at an Istio-based Gateway API implementation (class approuting-istio) or Application Gateway for Containers. If you are on AKS, your deadline is next month, not last March.

If you must stay on the Ingress API for organisational reasons, the Kubernetes docs keep a list of other Ingress controllers, and Traefik, Cilium and Istio from the table above also implement Ingress. I would still treat that as buying time.

How I would choose, in order

Here is the decision path I use, roughly in order of how much it constrains you:

1. Follow your platform. On AKS, GKE or EKS, check the provider's supported path first. A managed implementation means someone else patches the data plane, which is the whole lesson of this retirement.
2. Follow your CNI or mesh. If Cilium or Istio is already in the cluster, its Gateway API support removes a component, a Helm release and a CVE feed from your life.
3. Otherwise pick by data plane familiarity. Most of the field is Envoy. If your on-call engineers can read Envoy access logs and admin output, Envoy Gateway or kgateway are natural. If they think in NGINX, NGINX Gateway Fabric keeps that, minus the annotation-templating design that caused all those CVEs.
4. Audit your annotations before you shortlist. Run the jq inventory above. If you depend on configuration-snippet, server-snippet, Lua, or custom auth flows, find out how each candidate handles them in its policy CRDs. That is where implementations differ and where the migration effort really lives.

Whatever you choose, give the new controller the same discipline the old one lacked: pin versions, subscribe to its security announcements, run it with least-privilege RBAC, and test upgrades in CI. Doing that for the one component every request touches is the boring work that still matters in a year when most of the conversation is about AI. An unpatched ingress controller is also only the most visible item on this year's list of cluster threats.

FAQ

When was Ingress NGINX retired?

Best-effort maintenance ended in March 2026. The last releases, controller v1.15.1, v1.14.5 and v1.13.9, shipped on 19 March 2026 with a fix for CVE-2026-4342, and the GitHub repository was then archived. There will be no further releases or security patches.

Is the Kubernetes Ingress API deprecated?

No. The Ingress API is frozen but remains generally available, and Kubernetes has no plans to remove it. Only the community ingress-nginx controller was retired. You can keep using Ingress objects with another maintained controller, though new features land in Gateway API only.

Does my ingress-nginx keep working after retirement?

Yes, existing deployments keep serving traffic and the images remain available. The risk is that any vulnerability found from now on stays unpatched, and the controller's default service account can read Secrets across the cluster, so a single bug can become a cluster compromise.

What is the best replacement for ingress-nginx?

There is no single drop-in replacement. For most teams it is a Gateway API implementation: the one your cloud or CNI already provides, or Envoy Gateway, NGINX Gateway Fabric, kgateway or Traefik if you run your own. Traefik's ingress-nginx provider is the closest thing to a drop-in if you need to keep Ingress objects temporarily.

This quarter, I would run the detection command on every cluster, including the forgotten staging ones, and treat any hit as an open security finding with an owner and a date. Then I would inventory annotations, pick the implementation your platform or CNI already gives you, run ingress2gateway in a dev cluster, and cut over with DNS while the old controller is still running as a rollback path. For the step-by-step version with commands, status conditions and a troubleshooting table, see How to Migrate From ingress-nginx to Gateway API.

Related: Kubernetes Security in 2026, Kubernetes as the Agent Control Plane in 2026 and Policy as Code for AI Agents in 2026.