By On March 24, 2026, kubernetes/ingress-nginx — the Ingress controller running in roughly half of all production Kubernetes clusters — reached End-of-Life. The repository is now read-only. No more CVE patches. No bug fixes. No dependency updates. And CVE-2026-24512, a CVSS 8.8 configuration injection vulnerability that enables arbitrary code execution and secret disclosure, remains permanently unpatched in the community controller. If you haven’t migrated yet, this is your situation: you’re running EOL software with an unpatched code execution CVE in your L7 data path.
How We Got Here
The retirement wasn’t a surprise — it was announced in November 2025 and the Kubernetes Steering Committee issued a joint warning in January 2026. The project was maintained by one or two people working in their free time, handling critical infrastructure that Datadog estimates appears in about 50% of cloud-native environments. The technical debt had compounded past the point of resolution without a full rewrite, and the CVE-2025-1974 RCE from March 2025 made the security posture undeniable.
Before going further: there are two NGINX Ingress projects with different fates. kubernetes/ingress-nginx — the community project — is dead. The F5 NGINX Ingress Controller (nginx/kubernetes-ingress) is a separate, actively maintained project with commercial backing. If you’re on the community controller, you need to act. If you’re on F5’s controller, you’re fine for now.
The Security Problem Is Not Theoretical
Three CVEs disclosed in early 2026 will never be patched in the community controller:
- CVE-2026-24512 (CVSS 8.8): Configuration injection via the
rules.http.paths.pathfield allows arbitrary NGINX config injection, leading to code execution in the controller and exposure of secrets it has access to. - CVE-2026-24513: Auth URL annotation bypass — if your backend doesn’t honor the
X-CodeHTTP header, authenticated routes become unauthenticated. - CVE-2026-1580: Authentication bypass when custom-errors are configured for 401/403 responses.
Beyond the direct exposure, EOL software in the L7 data path is an automatic finding in SOC 2, PCI-DSS, ISO 27001, and HIPAA audits. Some teams are already having deployments blocked by compliance reviews. The “we’ll migrate in Q4” answer doesn’t hold up when a CVE is open and there’s no fix date.
The Migration Tool: ingress2gateway 1.0
Kubernetes SIG-Network released ingress2gateway 1.0 on March 20, 2026 — four days before EOL. This is the official, stable migration tool. It reads your live cluster’s Ingress resources and converts them to Gateway API equivalents. The 1.0 release supports 30+ common nginx annotations including CORS, backend TLS, regex matching, path rewrite, timeouts, SSL redirects, canary routing, and IP access control.
# Install ingress2gateway 1.0
go install github.com/kubernetes-sigs/ingress2gateway@v1.0.0
# Dry-run: scan live cluster, write output for review
ingress2gateway print --providers=ingress-nginx -A > gateway-resources.yaml
# Review the output, then apply
kubectl apply -f gateway-resources.yamlFor Ingress resources with five or fewer annotations, the tool handles 80–90% of the conversion automatically. Unsupported or unrecognized annotations are explicitly flagged — you know exactly what still needs manual attention. The output is structured YAML for Gateway and HTTPRoute resources, ready to review before touching your cluster.
Gateway API Is Actually Ready
Gateway API v1.5 is the current stable release, with 20+ conformant implementations available today. The architecture is meaningfully better than what Ingress offered:
| Feature | Ingress (EOL) | Gateway API v1.5 |
|---|---|---|
| Status | Dead — no patches | Active, 20+ implementations |
| Protocols | HTTP/HTTPS only | L4 (TCP/UDP) + L7 |
| Routing | Path/host only | Headers, weights, methods |
| Role model | Mixed ownership | Infra / ops / app separated |
| Traffic splitting | Annotation-dependent | Native HTTPRoute weights |
| CVE coverage | None | Implementation-maintained |
The role separation is what teams miss when they just compare feature lists. With Gateway API, infrastructure teams control GatewayClass definitions, platform teams manage Gateway resources, and application teams own their HTTPRoutes — without needing cluster-wide permissions to modify Ingress annotations. That’s a genuine security improvement, not just a checkbox on a migration checklist.
On implementations: Envoy Gateway is the CNCF-backed option with strong spec conformance. Traefik is the simplest drop-in for teams that prioritize developer experience. Cilium works if you’re already running eBPF-native networking. All three are production-ready. Pick one, install it alongside your existing setup, and validate before cutting over.
If You Can’t Migrate Right Now
Two short-term options exist, with caveats:
Chainguard EmeritOSS fork: Chainguard is maintaining a CVE-patching fork through their EmeritOSS program — patching vulnerabilities and updating dependencies. The catch: there are no pre-built images or Helm charts. You build and host everything yourself. Traefik has called this “the illusion of safety” and they’re not wrong. It buys time, but it’s not a strategy.
F5 NGINX Ingress Controller: If your team is deep in NGINX familiarity and needs operational continuity, F5’s controller is actively maintained, permissively licensed, and a closer drop-in than Gateway API. It’s a legitimate medium-term option while you plan the full migration.
What to Do This Sprint
- Audit: Run
kubectl get ingress -Aand count what you have. Checkkubectl get ingressclassto confirm which controller you’re running. - Install a Gateway controller: Envoy Gateway, Traefik, or Cilium — install it alongside your existing setup without touching live traffic.
- Convert: Run ingress2gateway 1.0, review the output YAML, fix flagged annotations manually.
- Cut over: Use weighted HTTPRoute rules to shift traffic progressively — 10%, 50%, 100% — before removing Ingress resources.
The Gateway API migration guide is the canonical reference for the conversion details. The tool handles the mechanical work. The only missing piece is scheduling the sprint — which, given the open CVEs and compliance pressure, probably shouldn’t wait for next quarter.
