CVE-2026-53622: Traefik HTTP/3 mTLS Auth Bypass Flaw

CVE-2026-53622 Overview

CVE-2026-53622 is an authentication bypass vulnerability in Traefik, an HTTP reverse proxy and load balancer. Versions prior to 3.7.3 mishandle TLS configuration selection during HTTP/3 (QUIC) handshakes. The proxy performs an exact, case-sensitive Server Name Indication (SNI) lookup that fails to match wildcard host patterns or case variants. The handshake then falls back to the default TLS configuration, which may not require client certificates. Attackers can complete the QUIC handshake without presenting a certificate, then reach a backend protected by a router-specific mutual TLS (mTLS) policy. The flaw is categorized as [CWE-288] Authentication Bypass Using an Alternate Path or Channel.

Critical Impact
Unauthenticated clients can bypass router-specific mTLS enforcement and reach protected backends over HTTP/3.

Affected Products

Traefik versions prior to 3.7.3
Deployments with HTTP/3 enabled on an entrypoint
Routers using wildcard Host rules or case-insensitive hostname matching with router-specific TLSOptions enforcing client certificate authentication

Discovery Timeline

2026-06-23 - CVE-2026-53622 published to the National Vulnerability Database (NVD)
2026-06-25 - Last updated in NVD database

Technical Details for CVE-2026-53622

Vulnerability Analysis

The vulnerability resides in Traefik's HTTP/3 TLS configuration selection logic. When a QUIC client initiates a handshake, Traefik selects the applicable TLS configuration by performing an exact, case-sensitive lookup against the SNI value sent by the client. This lookup does not evaluate wildcard host patterns such as *.example.com, nor does it normalize case variants of the configured hostname.

When the lookup misses, Traefik falls back to the default TLS configuration on the entrypoint. The default configuration typically does not enforce client certificate authentication. The QUIC handshake therefore completes without any client certificate exchange.

The HTTP routing layer evaluates the request separately. It matches the Host header against router rules, which do support wildcard and case-insensitive matching. The request is dispatched to a backend whose router expects mTLS, even though no client certificate was validated at the TLS layer.

Root Cause

The root cause is inconsistent hostname matching semantics between the TLS configuration lookup and the HTTP router. The TLS layer requires exact, case-sensitive SNI matches while the routing layer accepts wildcards and case variants. This asymmetry creates an alternate path that bypasses the intended authentication boundary.

Attack Vector

Exploitation requires network reachability to a UDP entrypoint with HTTP/3 enabled. The attacker sends a QUIC handshake with an SNI value that does not exactly match any TLS configuration entry, such as a differently cased hostname or a value covered only by a wildcard rule. After the handshake completes against the default TLS configuration, the attacker issues an HTTP request whose Host header matches the protected router, gaining access to the backend without presenting a client certificate.

No exploitation code is publicly available. See the GitHub Security Advisory GHSA-9cr8-q42q-g8m7 for technical details.

Detection Methods for CVE-2026-53622

Indicators of Compromise

QUIC handshakes on HTTP/3 entrypoints completing without client certificate exchange against routers that require mTLS
HTTP/3 requests reaching mTLS-protected backends with no recorded client certificate identity in access logs
SNI values in QUIC traffic that differ in case from configured TLS option hostnames or that match only wildcard host rules

Detection Strategies

Correlate Traefik access logs between the TLS handshake event and the HTTP routing decision to flag mismatches where mTLS was expected but no client certificate was presented
Inventory all routers with TLSOptions enforcing clientAuth and verify that corresponding TLS option entries cover every hostname variant the router accepts
Audit entrypoint configurations to identify where HTTP/3 is enabled alongside wildcard Host rules

Monitoring Recommendations

Enable verbose Traefik access logging and forward TLS handshake and routing events to a centralized log platform
Monitor UDP traffic to HTTP/3 entrypoints for anomalous SNI values
Alert on backend requests received without a verified client certificate when the upstream router policy requires mTLS

How to Mitigate CVE-2026-53622

Immediate Actions Required

Upgrade Traefik to version 3.7.3 or later, which contains the fix
If immediate upgrade is not possible, disable HTTP/3 on entrypoints serving routers that enforce router-specific mTLS
Restrict UDP access to HTTP/3 entrypoints at the network layer until the patch is applied

Patch Information

The vulnerability is fixed in Traefik 3.7.3. Release notes and the patched binaries are available in the GitHub Release v3.7.3. Review the GitHub Security Advisory GHSA-9cr8-q42q-g8m7 for full remediation guidance.

Workarounds

Disable HTTP/3 on affected entrypoints until patched
Replace wildcard Host router rules with exact hostname matches that align with configured TLS options
Move mTLS enforcement to the default TLS configuration of the entrypoint so it applies regardless of SNI lookup outcome
Block UDP traffic to the QUIC entrypoint at upstream firewalls or load balancers

bash

# Configuration example: disable HTTP/3 on an entrypoint as a temporary workaround
# traefik.yml
entryPoints:
  websecure:
    address: ":443"
    http3:
      advertisedPort: 0   # remove or comment out the http3 block entirely