Ingress NGINX End of Life (March 2026): Risks, Migration Paths, and Support Options

In March 2026, the Kubernetes community retired Ingress NGINX, the controller that routes traffic into roughly half of all Kubernetes clusters. There will be no further releases, no bug fixes, and no security patches. If you operate clusters that depend on it, this page is the complete reference: what is actually end of life (and what is not), the real risks of staying put, a comparison of every path forward, and the one option that lets you keep running Ingress NGINX with full security support while you migrate on your own schedule.

The short version

• What is EOL: The community-maintained kubernetes/ingress-nginx controller. Best-effort maintenance ended in March 2026 and the repository is archived and read-only.
• What is not EOL: The Kubernetes Ingress API itself (still supported, but feature-frozen), the NGINX web server, and F5/NGINX Inc.'s separate nginxinc/kubernetes-ingress controller, which remains actively maintained.
• The risk: Any vulnerability discovered after EOL will never be patched upstream. Auditors are already flagging EOL software in the request path against SOC 2, PCI DSS, HIPAA, and ISO 27001.
• Your options: Migrate to Gateway API or another controller (Traefik, HAProxy, F5 NGINX, Envoy), or stay on Ingress NGINX with commercial security support and migrate when you are ready.

Each of these points is worth understanding in detail, because the right decision depends on which of them applies to your environment. The rest of this page walks through them in turn.

What "end of life" actually means here

The single biggest source of confusion in this transition is the name. There are two distinct projects that people loosely call "NGINX Ingress," and only one of them is retiring.

• Ingress NGINX (repository kubernetes/ingress-nginx) is the community-maintained controller governed by Kubernetes SIG Network. This is the project that reached end of life in March 2026.
• NGINX Ingress Controller (repository nginxinc/kubernetes-ingress) is maintained by F5/NGINX Inc. in both open-source and commercial editions. It is a different codebase and is not affected by this retirement.

Two further distinctions matter for accuracy. First, the underlying Kubernetes Ingress API is not being removed. It remains generally available, but it is feature-frozen, with active development having moved to the Gateway API. Second, the NGINX web server that powers a large share of the internet is entirely unaffected. The retirement is narrowly about one Kubernetes controller, not the broader NGINX ecosystem.

The timeline

On November 11, 2025, Kubernetes SIG Network and the Security Response Committee announced the retirement. A follow-up joint statement from the Kubernetes Steering Committee and Security Response Committee in January 2026 reinforced the urgency, and best-effort maintenance ended as scheduled in March 2026. The retirement was the result of years of structural strain rather than a sudden decision.

• Maintainer burnout. For years the project was effectively sustained by one or two volunteers working in their spare time against an endless backlog of bugs and feature requests.
• Technical debt. The flexibility that made Ingress NGINX popular, especially arbitrary NGINX configuration injected through configuration-snippet annotations, became both a maintenance burden and a security liability.
• A failed successor. The planned replacement controller, InGate, never matured and was also retired.

The earlier IngressNightmare disclosure (CVE-2025-1974) made the sustainability problem impossible to ignore: a critical, cluster-wide vulnerability in a component that almost no one was resourced to maintain.

The risks of staying on Ingress NGINX after EOL

Existing deployments do not stop working the moment maintenance ends. Installation artifacts remain available and your clusters keep serving traffic. The risk is not immediate breakage; it is the steady, compounding accumulation of exposure over time.

Security

This is the headline risk. Ingress NGINX sits in the Layer 7 request path, terminating TLS and routing external traffic to your services, which makes it one of the most security-sensitive components in a cluster. After EOL, any newly discovered vulnerability has no upstream fix. The Kubernetes Steering and Security Response Committees were explicit that remaining on the retired controller leaves you and your users exposed to attack, and that none of the available alternatives are true drop-in replacements.

This is not hypothetical. CVEs continue to be discovered in code paths that affect retired Ingress NGINX builds, including the NGINX Rift heap buffer overflow disclosed in May 2026. HeroDevs tracks these in the vulnerability directory and ships patches for them.

Compliance

For regulated organizations, the compliance clock often moves faster than the security clock. Running known end-of-life software in the request path triggers findings under SOC 2, PCI DSS, HIPAA, and ISO 27001. Those findings can block production promotions, delay customer security reviews, and surface in audits well before any specific CVE is exploited. An unpatched, unsupported ingress controller is exactly the kind of artifact a compliance auditor is trained to flag.

Operational drift

Even setting security aside, a frozen controller decays in a moving ecosystem. As Kubernetes advances through new minor versions, untested compatibility issues emerge. Adjacent tooling such as cert-manager and external-dns continues to evolve around supported controllers, not retired ones. The common failure mode is a deployment that works fine until the next cluster upgrade, then breaks unexpectedly, forcing an emergency migration under far worse conditions than a planned one.

Your options, compared honestly

There is no universal right answer; the best path depends on how many Ingress resources you run, how many vendor-specific annotations they carry, your compliance posture, and how much engineering time you can commit in the near term. Below is a candid comparison of every realistic path, including the trade-offs each one carries. ("Drop-in" means existing Ingress resources keep working without rewriting annotations.)

• Gateway API (Envoy Gateway, Istio, NGINX Gateway Fabric, Cilium, kgateway) — Drop-in: No. Effort: High. Best for: teams ready to modernize traffic management for the long term. Trade-off: new resource model (GatewayClass, Gateway, HTTPRoute); requires translating every annotation and a staged cutover.
• Traefik — Drop-in: Partial. Effort: Medium. Best for: teams wanting the smoothest controller swap with a path to Gateway API. Trade-off: its Ingress-NGINX provider translates many annotations, but coverage is not complete; validate edge cases.
• HAProxy Kubernetes Ingress — Drop-in: Partial. Effort: Medium. Best for: performance-sensitive workloads. Trade-off: annotation and config model differs; requires reconfiguration and testing.
• F5 / NGINX Ingress Controller — Drop-in: Partial. Effort: Medium. Best for: organizations that need to stay in the NGINX narrative for support or compliance reasons. Trade-off: different project with its own annotations, CRDs (VirtualServer, Policy), and ConfigMap model; commercial tier for advanced features.
• Envoy Gateway — Drop-in: No. Effort: High. Best for: teams standardizing on Envoy or planning a service mesh. Trade-off: Gateway API only; full migration of routing config required.
• NES for Ingress NGINX (HeroDevs) — Drop-in: Yes. Effort: Minimal. Best for: teams that cannot safely migrate before the risk window opens, or want to decouple the security deadline from the migration project. Trade-off: a commercial subscription; it buys supported time rather than performing the eventual migration for you.

The sections that follow look at each of these paths in more depth, starting with the long-term destination and working toward the option that buys you time.

Gateway API: the long-term successor

Gateway API is the Kubernetes project's designated replacement for Ingress, and it is the strategically cleanest destination. It replaces controller-specific annotation sprawl with a portable, role-aware resource model (GatewayClass, Gateway, and HTTPRoute), implemented by many controllers including Envoy Gateway, Istio, NGINX Gateway Fabric, Cilium, and kgateway. The official ingress2gateway tool can convert much of your existing configuration automatically.

The honest caveat is that Gateway API is a genuine migration, not a swap. Every behavior previously expressed as an annotation has to be re-expressed, validated, and rolled out through a controlled traffic cutover. For a team with a handful of simple Ingress resources, that is very achievable before risk accumulates. For a team with hundreds of resources and years of accumulated annotations, it is a real project that needs planning, testing, and a change window.

Drop-in controller replacements

If a full Gateway API migration is not feasible on the available timeline, switching to another actively maintained Ingress controller buys breathing room. Traefik is frequently cited as the most straightforward swap because its Ingress-NGINX provider translates many existing annotations, and it also offers a forward path to Gateway API. HAProxy is a strong choice where raw performance matters, and F5's NGINX Ingress Controller is the natural fit for organizations that need to remain explicitly within the NGINX ecosystem for support or procurement reasons.

The shared caveat across all of these: none is a true drop-in. Each has its own configuration model, so you should expect to reconfigure and test rather than simply re-point your manifests. Kubernetes' own guidance on the surprising behaviors of Ingress NGINX is worth reading before you assume any replacement will behave identically.

Staying on Ingress NGINX with commercial support

There is a fourth path that the rest of the industry tends to skip, because most vendors in this conversation are selling a destination to migrate to. For many teams, the problem is not where to go but when: the security and compliance deadline arrives before a safe migration can realistically be completed.

NES for Ingress NGINX exists for exactly that gap. It is a commercially supported, drop-in replacement for end-of-life Ingress NGINX controller versions, delivered as an OCI image and Helm chart that integrate with GitOps, ArgoCD, and Flux workflows. When a new CVE affects your controller, HeroDevs validates and patches it and ships a new release, so the component in your request path stays secure and audit-ready. Your Ingress resources, annotations, and routing stay exactly as they are.

The point is to decouple the security deadline from the migration project. NES keeps you compliant and patched now; you still migrate to Gateway API or another controller when your team has the capacity to do it right, rather than under emergency conditions. It is a way to buy supported time, not a way to avoid the eventual move.

CVEs affecting end-of-life Ingress NGINX

New vulnerabilities continue to surface in code paths that affect retired Ingress NGINX builds, and after EOL none of them receive an upstream fix. The list below covers CVEs HeroDevs currently tracks and patches for NES for Ingress NGINX customers. Each links to its full entry in the HeroDevs vulnerability directory.

• Critical — CVE-2026-42945 — Heap-based buffer overflow ("NGINX Rift")
• High — CVE-2026-40890 — (Dependency) Denial of service
• High — CVE-2026-35205 — (Dependency) Improper verification of cryptographic signature
• High — CVE-2026-35204 — (Dependency) Path traversal
• Medium — CVE-2026-32282 — (Dependency) Improper link resolution before file access
• Medium — CVE-2024-44337 — (Dependency) Denial of service
• Critical — CVE-2025-1974 — IngressNightmare (cluster-wide RCE)

For a deeper technical breakdown of the most serious recent issue, see our analysis of CVE-2026-42945, the NGINX Rift heap buffer overflow, and our walkthrough of how NES for Ingress NGINX resolves CVE-2026-32282. The full, continuously updated list lives in the HeroDevs vulnerability directory.

How to decide

A simple way to frame the decision:

• If you run a small, simple set of Ingress resources and have engineering capacity now, migrate to Gateway API. You get the strategically correct end state and the migration is tractable at your scale.
• If you need to move off the retired controller quickly but cannot commit to a full API migration yet, swap to an actively maintained controller such as Traefik, then migrate routes to Gateway API later at your own pace.
• If your security or compliance deadline arrives before you can migrate safely (large estate, heavy annotation use, frozen change windows, or audit pressure), stay on Ingress NGINX with NES so you remain patched and compliant, and treat the migration as a separately scheduled project.

The one option that is not viable is doing nothing. Existing clusters will keep running, but every week on an unmaintained, unpatched controller in the request path adds security and compliance risk that only compounds.

Taking action

Start by inventorying where Ingress NGINX runs across your clusters and which versions and annotations are in play, since that inventory drives every subsequent decision. From there, pick the path that matches your scale, timeline, and compliance obligations.

If your immediate need is to close the security and compliance gap without a rushed migration, NES for Ingress NGINX delivers SLA-backed CVE patches as a drop-in Helm chart and OCI image, with VEX statements for every fix to support your audits and SBOMs. You can talk to our team about your environment or get pricing to scope what supported coverage looks like for your clusters.