Why Ingress Nginx’s Architecture Exposes Critical Vulnerabilities and How MSE Cloud‑Native Gateway Secures Them

Background and CVEs

In 2021 the Kubernetes ingress‑nginx controller disclosed three critical vulnerabilities (CVE‑2021‑25745, CVE‑2021‑25746, CVE‑2021‑25748). These flaws allow an attacker to inject malicious Nginx configuration and read the ServiceAccount token mounted at /var/run/secrets/kubernetes.io/serviceaccount, leading to credential theft and stability problems.

CVE‑2021‑25745 – configuration injection via an Ingress path enables retrieval of the ServiceAccount token.

CVE‑2021‑25746 – injection through various Ingress annotations yields the same token.

CVE‑2021‑25748 – bypasses the regex check added for CVE‑2021‑25745 and also steals the token.

Root cause

Ingress‑nginx runs the Go‑based controller (control plane) and the Nginx process (data plane) inside a single container. The controller stores sensitive credentials (e.g., the ServiceAccount token). Because the data plane shares the same container, an attacker who can influence Nginx configuration can read those credentials.

Impact on stability

When CPU load is high, resource contention between controller and Nginx can cause liveness‑probe timeouts, OOM kills, and container restarts.

Safer alternative architecture

Separating control‑plane and data‑plane, for example using a managed cloud‑native gateway that employs Istio as control plane and Envoy as data plane, eliminates the shared‑container risk. Configuration is delivered via the typed xDS API instead of string concatenation, preventing injection attacks. Envoy applies routing changes via RDS/ECDS without restarting, preserving long‑lived connections such as WebSockets.

Example Ingress manifest

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: ingress-example
spec:
  rules:
  - host: foo.bar.com
    http:
      paths:
      - pathType: Prefix
        path: "/"
        backend:
          service:
            name: service1
            port:
              number: 80
  - host: bar.foo.com
    http:
      paths:
      - pathType: Prefix
        path: "/"
        backend:
          service:
            name: service2
            port:
              number: 80

Illustrative vulnerable configuration

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: ingress-example
spec:
  rules:
  - http:
      paths:
      - pathType: Prefix
        # injection point
        path: "/inject{...}location /abc"
        backend:
          service:
            name: service
            port:
              number: 80

Resulting nginx.conf fragment:

location /inject{...}location /abc {
  set $ingress_name "ingress-example";
  ...
}

xDS RouteMatch protobuf (Envoy)

message RouteMatch {
  oneof path_specifier {
    string prefix = 1;
    string path = 2;
    type.matcher.v3.RegexMatcher safe_regex = 10;
    ConnectMatcher connect_matcher = 12;
    string path_separated_prefix = 14;
    string path_template = 15;
  }
  google.protobuf.BoolValue case_sensitive = 4;
  repeated HeaderMatcher headers = 6;
  repeated QueryParameterMatcher query_parameters = 7;
  // other fields omitted for brevity
}

Migration notes

The managed gateway fully supports the standard Kubernetes Ingress API and common ingress‑nginx annotations, enabling a drop‑in migration. Because configuration is applied via xDS, updates do not require Nginx restarts, preserving WebSocket and other long‑lived connections.

References

https://github.com/kubernetes/ingress-nginx/issues/8502 (CVE‑2021‑25745)

https://github.com/kubernetes/ingress-nginx/issues/8503 (CVE‑2021‑25746)

https://github.com/kubernetes/ingress-nginx/issues/8686 (CVE‑2021‑25748)