ingress-nginx is retiring in March 2026: here’s your Gateway API migration plan

November 11, 2025: the Kubernetes project announces ingress-nginx is retiring. March 24, 2026: the GitHub repository is archived read-only — no more releases, no more bugfixes, no more security patches. CVSS 9.8: that’s the score of CVE-2025-1974 (dubbed IngressNightmare), which laid bare the architectural fragility of the most deployed ingress controller in the Kubernetes ecosystem. The migration to Gateway API is no longer a “someday” item — it’s a security decision that directly affects your clusters, and the clock is already ticking.

Why ingress-nginx is going away

ingress-nginx is not a niche project. Deployed in over 40% of Kubernetes clusters, it served as the reference ingress controller for a decade: cloud-agnostic, feature-rich, flexible to a fault. That flexibility is precisely what killed it.

The core problem is structural. ingress-nginx translates Ingress objects into nginx configuration using a model where users can inject arbitrary directives through annotations — most notably nginx.ingress.kubernetes.io/server-snippet. What was designed as a convenience escape hatch became an uncloseable attack surface. The project’s November 2024 security report put it bluntly: “yesterday’s flexibility has become today’s insurmountable technical debt.”

Layered on top is a governance crisis. Despite 19.5k GitHub stars and 8.6k forks, the project never had more than one or two active maintainers — volunteers working evenings and weekends. An attempt to build a successor — the InGate project — never progressed beyond the experimental stage and has been abandoned. SIG Network and the Security Response Committee concluded that maintaining the status quo meant leaving a ticking bomb inside clusters.

The repository is archived. Existing artifacts — container images, Helm charts — remain available, but they will receive no security updates. A cluster still running ingress-nginx after March 2026 is a cluster that will absorb every future CVE with zero recourse.

CVE-2025-1974: the wake-up call

On March 24, 2025, the ingress-nginx maintainers shipped a patch for five vulnerabilities. The most severe, CVE-2025-1974, scored CVSS 9.8 — one notch below the maximum. Dubbed IngressNightmare by the Wiz research team that discovered it, this vulnerability lets any process on the Pod network take full control of the cluster.

The attack vector is brutally simple. ingress-nginx’s Validating Admission Controller listens on the cluster’s internal network and accepts requests with no authentication. By chaining the configuration injection vulnerabilities — made possible by those infamous snippet annotations — an attacker on the Pod network could:

• read every Secret the controller had access to (by default: all Secrets in the cluster);
• execute arbitrary code inside the controller’s context;
• pivot to the control plane using the ingress-nginx ServiceAccount privileges.

No admin access required. No permission to create Ingress objects. The only prerequisite: network access to the Pod network, which is true for any compromised workload in the cluster, and often for the entire cloud VPC or corporate network.

The Wiz researchers — Nir Ohfeld, Sagi Tzadik, Ronen Shustin, and Hillai Ben-Sasson — demonstrated this exploit chain against a default ingress-nginx deployment. The patches (v1.11.5 and v1.12.1) closed the holes, but the architectural lesson stands: a model that accepts arbitrary configuration directives from unprivileged Kubernetes objects is structurally unsafe. Gateway API does not repeat this mistake.

Gateway API: the successor is ready

Gateway API is not a newcomer: the project started in 2019, reached GA in October 2023 with v1.0, and is now integrated into Kubernetes’ standard release channel as of 1.31. As of January 2026, the specification stands at v1.2, with 14 conformant implementations available — including Cilium, Istio, Envoy Gateway, Traefik, NGINX Gateway Fabric, HAProxy Ingress, and Gloo Gateway.

The fundamental difference from Ingress is architectural. Where Ingress defined a single object with per-controller annotations, Gateway API splits the problem across three responsibility tiers:

• The Infrastructure Provider declares a GatewayClass: “here’s the controller that manages this class of gateways.”
• The Cluster Operator deploys a Gateway: “here’s an infrastructure instance listening on this port with this protocol.”
• The Application Developer defines Routes (HTTPRoute, GRPCRoute, TCPRoute, TLSRoute): “route traffic from this hostname to this service.”

This role hierarchy has a direct security consequence: a developer creating an HTTPRoute does not need permissions on the Gateway or GatewayClass. They cannot inject arbitrary configuration into the data plane. The attack surface is limited to the intended API surface, with no annotation escape hatches.

Another concrete advantage: Gateway API is natively multi-protocol. A single Gateway can route HTTP, gRPC, and TCP traffic without hacks — where Ingress was HTTP/HTTPS-only and required workarounds (TCP/UDP ConfigMaps) for everything else.

The migration path in three steps

Migrating from ingress-nginx to Gateway API doesn’t happen with a single command, but the path is well-defined.

1. Pick and install a Gateway API controller

First decision: which controller? The answer depends on your existing infrastructure.

• Cloud deployments: go with your provider’s native controller — AWS Load Balancer Controller, GKE Gateway Controller, or Azure Application Gateway for Containers. They provision cloud load balancers automatically.
• Bare-metal or on-premise: the leading software implementations are Envoy Gateway (lightweight, backed by the Envoy project), Cilium (if you already use it as your CNI), and Traefik (simple configuration, built-in dashboard).
• Staying in NGINX territory: NGINX Gateway Fabric is the official successor, developed by the same F5/NGINX team that contributed to ingress-nginx.

Installation is typically a Helm chart away:

# Example with Envoy Gateway
helm install eg oci://docker.io/envoyproxy/gateway-helm \
  --version v1.3.0 -n envoy-gateway-system --create-namespace

2. Create a GatewayClass and Gateway

Once the controller is installed, declare a GatewayClass, then a Gateway that will receive incoming traffic:

apiVersion: gateway.networking.k8s.io/v1
kind: GatewayClass
metadata:
  name: eg
spec:
  controllerName: gateway.envoyproxy.io/gatewayclass-controller
---
apiVersion: gateway.networking.k8s.io/v1
kind: Gateway
metadata:
  name: external-gateway
spec:
  gatewayClassName: eg
  listeners:
    - name: http
      protocol: HTTP
      port: 80
      allowedRoutes:
        namespaces:
          from: All

At this point, the gateway receives an IP address (external or internal depending on the implementation). This is the equivalent of the LoadBalancer-type Service that ingress-nginx used to create automatically.

3. Migrate Ingress objects to HTTPRoutes

This is the most manual step. Each Ingress object must be converted to an HTTPRoute. Here’s a typical conversion:

# Before: Ingress
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: app-ingress
spec:
  ingressClassName: nginx
  rules:
    - host: app.example.com
      http:
        paths:
          - path: /api
            pathType: Prefix
            backend:
              service:
                name: api-service
                port:
                  number: 8080

# After: HTTPRoute
apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: app-route
spec:
  parentRefs:
    - name: external-gateway
  hostnames:
    - app.example.com
  rules:
    - matches:
        - path:
            type: PathPrefix
            value: /api
      backendRefs:
        - name: api-service
          port: 8080

Two notable differences. First, the HTTPRoute explicitly references the parent Gateway via parentRefs — routing is declared on the application side, not the infrastructure side. Second, there are no annotations: all routing configuration (header matching, traffic weighting, redirects, request modification filters) is expressed in the API’s native schema.

For advanced features — rate limiting, authentication, CORS — Gateway API provides extension filters (HTTPRouteFilter) and policies (BackendTLSPolicy, upcoming ServicePolicy) instead of magic annotations.

What happens if you don’t migrate

Stalling means accepting three compounding risks:

• Zero security patches. The next vulnerability in nginx or in ingress-nginx’s own code will ship without a fix. Your cluster stays exposed, with no recourse other than an emergency migration — the worst-case scenario for an ops team.
• Future Kubernetes incompatibility. The Ingress API itself is frozen and won’t be removed from Kubernetes, but ingress-nginx tested compatibility against specific versions. The last supported release targets Kubernetes 1.32. Later versions may or may not work — no guarantees are provided.
• Collective skill atrophy. The longer you wait, the fewer teams master ingress-nginx and the more teams treat Gateway API as the default. Staying on a dead controller isolates you from both the job market and the community.

This isn’t theoretical. CVE-2025-1974 proved a critical vulnerability can emerge without warning. The only difference in March 2026: nobody will be around to ship the patch.

Verdict

If your clusters still run ingress-nginx, you have three months to migrate. Here’s how to prioritize:

• Internet-facing clusters: migrate first. Start with production environments, service by service. Every migrated Ingress removes attack surface.
• Internal clusters with restricted Pod networks: schedule migration before March 2026. The short-term risk is lower, but the absence of future patches is an existential threat.
• New clusters: never deploy ingress-nginx again. Go directly with the Gateway API controller of your choice. The learning curve is real, but it pays for itself with the first HTTPRoute.

Migrating to Gateway API is not a luxury or a leap of faith. It’s a stable technology backed by the entire ecosystem — and, critically, the only one that will receive security patches six months from now. ingress-nginx served the community well for a decade, but its time has passed.

References

• Kubernetes Blog — Ingress NGINX Retirement: What You Need to Know (November 11, 2025)
• Kubernetes Blog — CVE-2025-1974: What You Need to Know (March 24, 2025)
• ingress-nginx GitHub repository (archived) — archived March 24, 2026
• Gateway API — Official documentation
• Gateway API — Conformant implementations
• Kubernetes Documentation — Gateway API
• Wiz Research — IngressNightmare (CVE-2025-1974)
• GitHub Issue — ingress-nginx maintenance future