CVE-2026-53622: HTTP/3 mTLS bypass in Traefik router TLSOptions selection

I reported an HTTP/3 mutual TLS bypass in Traefik that was published as CVE-2026-53622 / GHSA-9cr8-q42q-g8m7.

The issue affected deployments that used router-specific TLSOptions as an access-control boundary while HTTP/3 was enabled on the same entrypoint. In that configuration, an unauthenticated client could complete the QUIC/TLS handshake without a client certificate and still reach a backend that was intended to be protected by mTLS.

Advisory

• CVE: CVE-2026-53622
• GitHub Advisory: GHSA-9cr8-q42q-g8m7
• Package: Traefik
• Ecosystem: Go module
• Affected versions: <= v3.7.2
• Patched version: v3.7.3
• Severity: High 7.8/10
• CVSS: CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:N/SC:H/SI:H/SA:N
• CWE: CWE-288: Authentication Bypass Using an Alternate Path or Channel

Root Cause

Traefik supports selecting TLS options from router host rules. That is commonly used to make one route require client certificates while another route on the same entrypoint remains public.

The vulnerable behavior was specific to the HTTP/3 path. HTTP/3 uses a QUIC TLS callback to choose the TLS configuration before the HTTP request is routed. In the affected versions, that callback looked up the TLS configuration by doing an exact map lookup on the SNI value:

if tlsConfig, ok := r.hostHTTPTLSConfig[info.ServerName]; ok {
    return tlsConfig, nil
}

return r.httpsTLSConfig, nil

That lookup did not apply the same hostname semantics as the later HTTP router.

Two mismatches mattered:

• *.example.com did not match an SNI such as api.example.com;
• api.example.com did not match a mixed-case SNI such as API.EXAMPLE.COM.

If the exact SNI lookup failed, Traefik fell back to the default HTTPS TLS configuration. If that fallback configuration did not require a client certificate, the QUIC handshake succeeded. The later HTTP routing layer could still match the same request to the protected backend.

Attack Shape

The vulnerable deployment shape was:

1. HTTP/3 is enabled on an entrypoint.
2. A router uses tls.options=mtls to require client certificates.
3. The default TLS configuration does not require client certificates.
4. The protected route is matched through a wildcard host rule or a case-insensitive host match.
5. UDP access to the HTTP/3 entrypoint is reachable by the attacker.

For the wildcard case, direct HTTP/2 access to api.example.com failed with certificate required, as expected.

The HTTP/3 request to the same host succeeded without a client certificate because the TLS selector failed to resolve api.example.com against the configured wildcard entry and fell back to the weaker default TLS configuration.

For the mixed-case case, the protected route used an exact host such as api.example.com. A normal HTTP/2 request still required a client certificate, but an HTTP/3 request using API.EXAMPLE.COM could miss the exact SNI map key while the later host routing still treated the name as equivalent.

Impact

The impact is an authentication bypass for deployments that use router-level mTLS as a security boundary.

The important point is that mTLS was not bypassed by forging a certificate or breaking TLS. The issue was that different protocol paths inside Traefik disagreed on which TLS options applied to the same logical host.

In affected deployments:

• the normal TCP/HTTP2 path required a client certificate;
• the HTTP/3 handshake could fall back to a permissive TLS configuration;
• the HTTP router could still dispatch the request to the protected backend;
• unauthenticated clients could access routes that operators expected to be mTLS-only.

This is especially relevant for private APIs, administrative backends, internal service gateways, and tenant-specific routes where client certificates are used as the primary access-control mechanism.

Why This Was Subtle

The bug was not in the HTTP router itself. The router could still match wildcard hosts and case variants correctly.

The problem was the earlier TLS selection step for HTTP/3. By the time the HTTP router evaluated the request, the QUIC handshake had already completed under the wrong TLS configuration.

That makes the issue easy to miss in manual testing:

• HTTP/2 tests can look correct.
• Direct access to the protected host can require a client certificate.
• The bypass only appears when HTTP/3 is enabled and the SNI lookup misses the router-specific TLS option.

This is a good example of an access-control rule being split across two layers: the TLS layer and the HTTP routing layer. If those layers do not share identical hostname matching semantics, the weaker layer wins.

Fix Direction

The fix needs to make HTTP/3 TLS configuration selection use the same hostname matching model as the router.

Defensive principles:

• do not use exact SNI map lookups where router semantics are wildcard-aware;
• normalize hostnames consistently before selecting security-sensitive TLS options;
• ensure that fallback TLS options are never weaker than route-specific options for the same reachable host;
• add regression tests for wildcard and mixed-case SNI values on the HTTP/3 path.

References

• GitHub Advisory: https://github.com/traefik/traefik/security/advisories/GHSA-9cr8-q42q-g8m7
• Traefik project: https://github.com/traefik/traefik