NGINX Ingress Is Dead.
Here's How to Not Get Owned.

Why Ingress NGINX Is Dead

On November 11, 2025, Kubernetes SIG Network and the Security Response Committee published a retirement notice for the community-maintained Ingress NGINX Controller (kubernetes/ingress-nginx). Best-effort maintenance continues until March 2026. After that: zero releases, zero bugfixes, zero security patches.

The Kubernetes Steering Committee followed up in January 2026 with an unusually blunt statement: remaining on Ingress NGINX after retirement leaves you and your users vulnerable to attack. They weren't hedging.

How did we get here? The project was maintained by one or two volunteers working nights and weekends. The codebase accumulated what the Kubernetes Security Response Committee called “insurmountable technical debt”—particularly the snippets annotation system that allowed arbitrary NGINX config injection. The planned replacement, InGate, never shipped.

IngressNightmare: The CVEs That Sealed It

In March 2025, Wiz Research disclosed a chain of five vulnerabilities in Ingress NGINX collectively dubbed IngressNightmare. CVSS 9.8. Unauthenticated RCE leading to full cluster takeover. 43% of cloud environments were vulnerable, with over 6,500 clusters exposing the admission webhook to the public internet.

The Kill Chain

The attack exploits a fundamental design flaw: the admission controller runs inside the same pod as the NGINX reverse proxy, and validates Ingress objects by running nginx -t on generated configs—without sandboxing. The attacker uploads a malicious shared library via NGINX's client-body-buffer, then injects an ssl_engine directive through annotation injection to load it during config validation.

NGINX Ingress Annotation Risk Radar

This radar maps every dangerous annotation in the Ingress NGINX config injection surface. Each spoke is a real annotation. The radial axis scores impact from Info Leak (center) through DoS and Privilege Escalation to RCE (outer edge). The angular width represents exploitability. Every annotation shown here has at least one CVE tied to it—and server-snippet and configuration-snippet sit at the outer ring with direct RCE impact via CVE-2021-25742 and CVE-2025-1974.

Attack Surface Anatomy

Your ingress controller is the most exposed component in the cluster. It terminates TLS, parses HTTP headers, evaluates routing rules, and holds credentials to interact with the Kubernetes API.

Ingress Controller Comparison: NGINX vs HAProxy vs Traefik vs Cilium

Four contenders. Each fills a different niche. HAProxy for raw performance and drop-in Ingress API compatibility. Traefik for automated service discovery and Let's Encrypt. Cilium for eBPF-native networking with built-in L7 visibility and zero sidecar overhead. This table scores them on what matters for a security-first migration.

Hardened Migration Playbook

Step 1: Inventory

bash# Find all ingress-nginx pods across namespaces
kubectl get pods --all-namespaces \
  --selector=app.kubernetes.io/name=ingress-nginx -o wide

# Check controller version
kubectl exec -n ingress-nginx deploy/ingress-nginx-controller \
  -- /nginx-ingress-controller --version

# List all Ingress resources using NGINX class
kubectl get ingress --all-namespaces \
  -o jsonpath='{range .items[*]}{.metadata.namespace}/{.metadata.name} class={.spec.ingressClassName}{"\n"}{end}' \
  | grep -i nginx

# Count annotation types — identify snippet usage
grep -oP 'nginx\.ingress\.kubernetes\.io/\K[^:]+' ingress-export.yaml \
  | sort | uniq -c | sort -rn

Step 2: Deploy Side-by-Side

bashhelm repo add haproxytech https://haproxytech.github.io/helm-charts
helm repo update

# Install in separate namespace with its own IngressClass
helm install haproxy-ingress haproxytech/kubernetes-ingress \
  --namespace haproxy-ingress --create-namespace \
  --set controller.ingressClass=haproxy \
  --set controller.kind=DaemonSet \
  --set controller.service.type=LoadBalancer

# Migrate a single Ingress to test
kubectl patch ingress my-app -n production \
  --type=json -p='[{"op":"replace","path":"/spec/ingressClassName","value":"haproxy"}]'

Step 3: Harden the New Controller

yamlapiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: restrict-ingress-admission
  namespace: haproxy-ingress
spec:
  podSelector:
    matchLabels:
      app.kubernetes.io/name: kubernetes-ingress
  policyTypes:
    - Ingress
  ingress:
    # External traffic on HTTP/HTTPS
    - ports:
        - port: 80
        - port: 443
    # Admission webhook ONLY from API server
    - from:
        - ipBlock:
            cidr: <api-server-cidr>/32
      ports:
        - port: 8443
    # Prometheus from monitoring namespace
    - from:
        - namespaceSelector:
            matchLabels:
              name: monitoring
      ports:
        - port: 10254

yamlapiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: ingress-controller-role
  namespace: production
rules:
  - apiGroups: [""]
    resources: ["secrets"]
    verbs: ["get", "list", "watch"]  # Only this namespace
  - apiGroups: [""]
    resources: ["services", "endpoints"]
    verbs: ["get", "list", "watch"]
  - apiGroups: ["networking.k8s.io"]
    resources: ["ingresses"]
    verbs: ["get", "list", "watch"]
  - apiGroups: ["networking.k8s.io"]
    resources: ["ingresses/status"]
    verbs: ["update"]

Migration Checklist

Four phases. Each gate must be validated before moving to the next.