Traefik’s HTTP/3 implementation performs an exact, case‑sensitive lookup of the client‑supplied SNI against configured TLSOptions. The lookup fails for wildcard host patterns or for case variants of the configured hostname, causing the TLS handshake to fall back to the default configuration that does not require client certificates. The HTTP routing layer, however, still enforces the router‑specific mTLS policy, allowing an unauthenticated client to reach a backend that was intended to require mutual authentication.

The flaw affects all Traefik deployments using the open‑source reverse proxy prior to version 3.7.3 when HTTP/3 is enabled on an entrypoint, a router uses a wildcard host rule or case‑insensitive hostname matching, and a router‑specific TLSOptions enforces client‑certificate authentication. Updating to Traefik 3.7.3 or newer removes the vulnerability.

The CVSS score of 7.8 indicates high severity. EPSS is not available, so the current estimated exploitation probability is unknown but potentially low. KEV is not listed, meaning no documented widespread exploitation. An attacker who can reach the UDP port that handles the HTTP/3 entrypoint can complete the QUIC handshake without presenting a certificate and subsequently be routed to a backend protected by an mTLS policy, effectively bypassing authentication. The impact is unauthorized access to services that depend on client‑certificate validation.