Traefik EUVD-2026-113926

Requires a specific stack and configuration collision: Traefik v3.7.0-ea.1 through v3.7.14 running the Kubernetes Ingress NGINX provider, with a host protected by mTLS via the nginx.ingress.kubernetes.io/auth-tls-secret annotation, AND at least one additional Ingress declaring a path on that same host that lacks matching auth-tls settings. The silent fallback only occurs when core.strictTLSOptions is NOT enabled - enabling strictTLSOptions prevents the fallback and is the vendor-stated mitigation short of upgrading. Exploitation is remote and unauthenticated (PR:N), but is limited by the required multi-Ingress same-host conflict (a non-default, non-attacker-controlled condition, reflected as AT:P) and by the narrow early-access 3.7.x version window; deployments on v2, v3 before v3.7.0, or with strictTLSOptions enabled are not exposed.

Signals are moderate and internally consistent rather than alarming. The vendor-assigned CVSS 4.0 vector (CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:N/VI:N/VA:N/SC:H/SI:H/SA:N, score 7.0) describes a network-reachable, unauthenticated bypass whose impact falls on a subsequent system (the protected backend: SC:H/SI:H) rather than on Traefik itself (VC/VI/VA:N). The AT:P flag is the key qualifier - exploitation is not unconditional but depends on a specific, non-attacker-controlled deployment condition (a second Ingress on the same host lacking matching auth-tls settings). There is no CISA KEV listing and no EPSS score in the supplied data, so widespread or automated exploitation is not evidenced; the only priority signal is the vuln.today 'this_week' decision label and VulnCheck's reporting. No public exploit code is referenced - only the GHSA and VulnCheck advisories. Net assessment: a genuine, serious authentication-bypass affecting a specific misconfiguration pattern on a new Traefik branch, warranting prompt patching (this week) but not emergency response. EPSS data is absent, so probabilistic exploitation likelihood cannot be weighed; this should be noted when prioritizing.

An attacker targets a Traefik 3.7.x deployment using the Kubernetes Ingress NGINX provider where one Ingress protects a host with mTLS via the nginx.ingress.kubernetes.io/auth-tls-secret annotation, while a second Ingress declares a path on that same host without matching auth-tls settings. Because Traefik attaches the client-authentication TLS option per-Ingress rather than per-host, the conflict causes a silent fallback to default TLS options that do not request a client certificate, so the attacker simply connects over TLS without presenting any client certificate and reaches the backend meant to require one. No public exploit code is referenced; only vendor and VulnCheck advisories exist.