CVE-2026-53622: Traefik: HTTP/3 mTLS bypass via exact SNI TLSOptions lookup for wildcard and mixed-case hosts
Traefik is an HTTP reverse proxy and load balancer. Versions prior to 3.7.3, 3.6.18, and 2.11.51 have a critical vulnerability in Traefik's HTTP/3 (QUIC) TLS configuration selection that allows unauthenticated clients to bypass router-specific mTLS enforcement. When HTTP/3 is enabled on an entrypoint, the TLS handshake selects the applicable TLS configuration through an exact, case-sensitive lookup on the SNI value, which fails to match wildcard host patterns (e.g., *.example.com) or case variants of the configured hostname. Because the handshake falls back to the default TLS configuration — which may 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. The issue affects deployments where HTTP/3 is enabled, a router uses a wildcard Host rule or case-insensitive hostname matching, a router-specific TLSOptions enforces client certificate authentication, and UDP access to the entrypoint is reachable by an attacker. This vulnerability is fixed in versions 3.7.3, 3.6.18, and 2.11.51.
Security readout for executives and security teams
Plain-English summary
Traefik can mistakenly admit an unauthenticated HTTP/3 connection to a service that should require a client certificate. An external attacker could bypass that identity check and access or modify sensitive backend data, but only when the affected HTTP/3, routing, TLS, and network conditions coexist.
Executive priority
Prioritize emergency remediation for internet-facing deployments matching all exposure conditions, especially where mTLS protects administrative, partner, or sensitive-data services. Other Traefik deployments should still be inventoried promptly. The 9.1 score reflects a potentially complete confidentiality and integrity impact without authentication.
Technical view
For QUIC handshakes, affected Traefik versions perform an exact, case-sensitive SNI lookup for router TLSOptions. Wildcard or mixed-case hostnames may miss, causing fallback to default TLS settings without client authentication. HTTP routing can then select the intended backend despite the router-specific mTLS policy not being enforced during the handshake.
Likely exposure
Exposure requires HTTP/3 enabled on the entrypoint, attacker-reachable UDP, router-specific TLSOptions enforcing client certificates, and wildcard Host rules or hostname case variation. Deployments without this combination are not described as exploitable by the supplied sources. Listed affected releases are before 2.11.51, 3.6.18, or 3.7.3 within their respective branches.
Exploitation context
The issue is remotely reachable, requires no privileges or user interaction, and can compromise confidentiality and integrity. The supplied record marks KEV false and provides no evidence of active exploitation. Treat that as absence of confirmation, not proof that exploitation has not occurred.
Researcher notes
Focus review on the boundary between QUIC TLS configuration selection and later HTTP router matching. Confirm SNI normalization, wildcard handling, default TLSOptions, and UDP reachability. The supplied sources identify CWE-288 and CWE-289. No exploit code or verified exploitation campaign is established in the bundle.
Mitigation direction
Upgrade to Traefik 2.11.51, 3.6.18, or 3.7.3, as appropriate for the deployed branch.
If immediate upgrading is impossible, disable HTTP/3 on affected entrypoints where operationally acceptable.
Restrict untrusted UDP access to affected entrypoints until patched.
Review current Traefik and downstream vendor guidance before applying platform-specific changes.
Validation and detection
Confirm every Traefik instance and container image runs a fixed or later supported version.
Audit entrypoints for HTTP/3 enablement and externally reachable UDP listeners.
Identify routers combining wildcard or case-insensitive hosts with router-specific client-certificate TLSOptions.
Check whether affected entrypoints can fall back to default TLSOptions lacking client authentication.
After remediation, verify unauthenticated HTTP/3 sessions cannot reach mTLS-protected backends.
Review access logs for unexpected HTTP/3 requests reaching certificate-protected routes.
Generated from the cited source records. This long-tail analysis has not been individually reviewed by a named human.
Potential ATT&CK relevance
Conservative CVE-to-ATT&CK context
These mappings and lookup hints may be relevant to the vulnerability behavior, CWE, affected product, or exposure path. Glexia-inferred context is not an official MITRE, ATT&CK, CWE, or CVE Program mapping.
ATT&CK lookup starting points
Use these exact CWE pages and searches to review the Glexia ATT&CK library from this CVE's weakness and description context.
cwe · low confidence lookup
CWE-288: Exact CWE lookup
Use the exact CWE identifier as the starting point before reviewing related ATT&CK behavior. Open the exact CWE lookup page first, then review the ATT&CK searches from that MITRE weakness context. This is a Glexia lookup hint, not an official ATT&CK mapping.
Use the exact CWE identifier as the starting point before reviewing related ATT&CK behavior. Open the exact CWE lookup page first, then review the ATT&CK searches from that MITRE weakness context. This is a Glexia lookup hint, not an official ATT&CK mapping.
These fields come from the CVE record and ADP containers, not from Glexia's Take. They preserve time-varying source decisions such as CISA SSVC, KEV status, CVSS metrics, and provider references.
We collect every scored CVSS vector available in the official CNA and ADP containers. When more than one version is present, the table keeps the source vectors side by side instead of collapsing them into the highest score.
CWE links open Glexia weakness intelligence pages with official CWE context, developer remediation guidance, and related CVE mappings.
CWE-288 · source CWE mapping
Authentication Bypass Using an Alternate Path or Channel
Authentication Bypass Using an Alternate Path or Channel represents a recurring weakness pattern that can create exploitable paths when design, validation, or implementation controls are missing.
Authentication Bypass by Alternate Name represents a recurring weakness pattern that can create exploitable paths when design, validation, or implementation controls are missing.