Traefik’s HTTP/3 implementation performs an exact, case‑sensitive lookup of the client‑supplied SNI against configured TLSOptions. This is a CWE-288 and CWE-289 weakness, where improper handling of TLS configuration can lead to insecure bypass of client‑certificate enforcement. 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. A client can complete the QUIC handshake without presenting a certificate, while the subsequent HTTP routing layer still dispatches the request to a backend protected by a router‑specific mTLS policy. Because the handshake falls back to a default TLS configuration, unauthenticated clients can bypass mTLS enforcement when HTTP/3 is enabled on an entrypoint and the router uses wildcard or case‑insensitive host matching. This vulnerability affects deployments where UDP access to the entrypoint is reachable by an attacker and is fixed in Traefik 3.7.3.

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.