CVE-2026-53622: Traefik HTTP/3 TLS configuration selection flaw bypasses router mTLS
Traefik releases before 3.7.3, 3.6.18 and 2.11.51 can let unauthenticated clients bypass router-specific mTLS when HTTP/3 is enabled on an entrypoint. The TLS configuration lookup on SNI is exact and case-sensitive, so wildcard and case-variant hostnames fall back to a default configuration that may not require client certificates. The record rates the issue critical and classifies it as CWE-288; the sources consulted do not confirm exploitation in the wild.
Overview
CVE-2026-53622 is a critical flaw in how Traefik, an HTTP reverse proxy and load balancer, selects TLS configuration for HTTP/3 (QUIC) connections. When HTTP/3 is enabled on an entrypoint, a client may complete the handshake under the default TLS configuration instead of the router-specific one, which can lead to a protected backend being reached without a client certificate.
Impact
- According to the record, an unauthenticated client can bypass router-specific mTLS enforcement.
- The TLS handshake falls back to the default configuration, which may not require client certificates, while HTTP routing still dispatches the request to the protected backend.
- The NVD vector describes a network-reachable issue with no privileges or user interaction required, high confidentiality and integrity impact, and no availability impact.
Affected products and versions
- The structured affected field lists Traefik with the range below 3.7.3.
- The description states that versions prior to 3.7.3, 3.6.18 and 2.11.51 are affected. The structured field does not list the exact boundaries for the older release lines, so these should be confirmed against the vendor advisory.
- Deployments are affected only when the conditions in the description are present: HTTP/3 enabled, a wildcard Host rule or case-insensitive hostname matching, a router-specific TLSOptions requiring client certificates, and reachable UDP access to the entrypoint.
Exploitation status
The KEV entry in the record shows that the vulnerability is not listed in CISA KEV. No confirmed exploitation in the wild appears in the sources consulted. The GitHub advisory carries an Exploit reference tag, but the record does not describe its content, so this tag is not treated as evidence of active exploitation.
Remediation and mitigation
- Upgrade to 3.7.3, 3.6.18 or 2.11.51, depending on the release line in use, as indicated in the vendor fixes.
- Inventory all Traefik instances, including those on older release lines, and confirm which ones have HTTP/3 enabled on entrypoints.
- Until patching is complete, consider whether HTTP/3 is required on entrypoints that protect services with mTLS, and whether wildcard or case-insensitive Host rules are needed for those routers.
- Limit UDP exposure of the affected entrypoints to trusted networks where operationally feasible.
Detection guidance
- Review static and dynamic configuration for HTTP/3 enabled on entrypoints, routers using wildcard Host rules, and TLSOptions that enforce client certificate authentication.
- If access logs record client certificate details, look for successful requests to mTLS-protected services where those details are absent.
- Track deployment versions across environments to identify instances still running releases below the fixed versions.
Limitations of the available information
- The record does not include proof-of-concept details, and this analysis does not attempt to provide any.
- The structured affected range does not fully match the description for the older release lines.
- The record has no EPSS or SSVC data, and the CVSS 4.0 score is reported only as a numeric value by the GitHub CNA.
- The Red Hat references in the record were not reviewed for their content, so no statements are drawn from them.
Frequently asked questions
Which Traefik versions fix CVE-2026-53622?
According to the record, the fixed versions are 3.7.3, 3.6.18 and 2.11.51, and the description states that earlier versions are affected.
Does this flaw require HTTP/3 to be enabled?
Yes. The record states that the issue affects deployments where HTTP/3 is enabled on an entrypoint, alongside other conditions such as wildcard Host rules and router-specific client certificate enforcement.
Is this vulnerability known to be exploited in the wild?
The record shows the vulnerability is not listed in CISA KEV, and the sources consulted do not confirm exploitation in the wild.
This analysis was drafted with AI assistance from verified source data and automatically checked against it.