GPU VulnDB

Database/Container, Kubernetes & orchestration

Traefik: mTLS silently disabled when another Ingress shares the host, bypassing client-cert auth

CVSS 7.0CVE-2026-119572Container, Kubernetes & orchestrationcurated

Impact

Traefik's Kubernetes Ingress NGINX provider drops the mTLS configuration declared by the auth-tls-secret annotation when a second Ingress declares a path on the same host without matching auth-tls settings; the route then falls back to the default TLS options. A backend that was meant to be reachable only with a valid client certificate becomes reachable unauthenticated from anywhere the ingress is exposed. On a GPU cluster this is the pattern used to fence off internal control surfaces - scheduler APIs, inference endpoints, metrics - behind certificate auth, and the bypass is silent: the annotation is still present in the manifest, so an operator reading config sees mTLS enabled while it is not enforced. Any namespace allowed to create an Ingress on a shared host can trigger the fallback for someone else's route.

Who can reach it

Unauthenticated network attacker who can reach the Traefik ingress, once any Ingress object (possibly created by a different tenant namespace) declares a path on the same host without matching auth-tls annotations. No credentials and no client certificate needed.

What to do

Upgrade Traefik to 3.7.15 or later; affected range is 3.7.0-ea.1 through 3.7.14. Rolling-restart the Traefik deployment, which is a normal daemon restart with no GPU node impact. Until patched, audit Ingress objects that share a host with an mTLS-protected route and verify from outside that the protected path actually demands a client certificate.

References

Related entries

All Container, Kubernetes & orchestration entries

This entry is curated: imported from vendor advisories with machine assistance, not yet individually verified. Confirm against your vendor's advisory before acting, and report anything wrong.