Summary
A security issue in ingress-nginx allows a user with permission to create or update Ingress objects to bypass the sanitization applied to the spec.rules[].http.paths[].path field by embedding a newline character. This bypass enables the attacker to retrieve the credentials of the ingress-nginx controller, which in a default cluster configuration has read access to all secrets across all namespaces. The chrooted ingress-nginx controller variant introduced in v1.2.0 is not affected.
Impact
Any user who can create or update networking.k8s.io/Ingress or extensions/Ingress objects in a cluster running ingress-nginx prior to v1.2.1 can exploit this vulnerability to gain access to the ingress-nginx service account token. Because the default ingress-nginx service account is granted cluster-wide access to secrets, successful exploitation effectively exposes all Kubernetes secrets in the cluster. Multitenant environments where non-admin users hold Ingress create or update permissions are most at risk.
Detection
Audit which users and service accounts hold the create or update verbs on networking.k8s.io/ingresses or extensions/ingresses resources, and review Ingress objects in the cluster for path values containing newline characters or other non-standard characters. If you find evidence that this vulnerability has been exploited, contact security@kubernetes.io.
Mitigation
Upgrade ingress-nginx to v1.2.1 or later, which includes the sanitization fix for the path field.
If an immediate upgrade is not possible, implement an admission policy that restricts the spec.rules[].http.paths[].path field on networking.k8s.io/Ingress resources to a known safe character set. The ingress-nginx project documents a suggested annotation-value-word-blocklist ConfigMap setting that can serve as a baseline for the blocklist pattern.