Traefik EUVD-2026-71019

Exploitation requires all of the following conditions to be simultaneously present: Traefik v3.7.0-v3.7.10 deployed as a Kubernetes Ingress controller using the Ingress NGINX provider; at least two Ingress objects must reference the same hostname; both Ingresses must carry the nginx.ingress.kubernetes.io/auth-tls-secret annotation pointing to the same client CA secret; and both must have auth-tls-verify-client set to "on" (or the same verification mode). The attacker does not need credentials or a client certificate - they simply connect to the affected hostname over HTTPS without presenting a certificate. Exploitation is limited to the v3.7.x line only; prior major versions are not affected. The triggering configuration can arise unintentionally in multi-tenant clusters where teams independently deploy Ingresses for shared hostnames, but requires the coincidence of matching host, CA, and auth mode across two separate objects.

The CVSS 4.0 vector (AV:N/AC:L/AT:P/PR:N/UI:N/VC:H) captures the core tension: network exploitation is straightforward once the triggering configuration is present, but AT:P (attack requirements present) correctly reflects that the vulnerable state requires two Ingress objects co-existing on the same host. In practice, multi-tenant Kubernetes clusters - where different teams independently deploy Ingress resources for a shared hostname - naturally produce this collision, making the condition less exotic than it first appears. EPSS data is not provided, and the vulnerability is not listed in CISA KEV, suggesting no confirmed widespread exploitation at time of analysis. However, the confidentiality impact is high: a successful bypass grants access to back-end services that operators explicitly intended to restrict to certificate-authenticated clients, potentially exposing sensitive APIs or internal dashboards. Even a mid-sized municipal IT team in gniezno operating a shared Kubernetes cluster should treat this as urgent if running any v3.7.x Traefik instance with mTLS Ingress policies, given the ease of upgrade to v3.7.11 and the silent nature of the fallback - administrators may not realize their mTLS policy has been voided. The absence of a public exploit reduces immediate pressure slightly, but the vulnerability is conceptually trivial to exploit once the triggering configuration is identified.

An attacker targeting a Kubernetes cluster discovers that a sensitive internal API endpoint is fronted by Traefik with auth-tls-verify-client: "on", but also observes (via DNS enumeration or leaked Ingress configs) that a second Ingress on the same hostname exists with the same CA annotation. The attacker sends a standard HTTPS request to the API without a client certificate; Traefik, having detected a TLS options conflict between the two Ingresses, silently falls back to the default TLS configuration and serves the connection, bypassing the mTLS gate entirely. No client certificate or private key is required.