CVE-2026-53622

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.

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.

Summary

There is 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.

Patches

• https://github.com/traefik/traefik/releases/tag/v3.6.18
• https://github.com/traefik/traefik/releases/tag/v3.7.3

For more information

If you have any questions or comments about this advisory, please open an issue.

<details> <summary>Original Description</summary>

Summary

Traefik's HTTP/3 TLS configuration selection can ignore router-specific TLSOptions and allow unauthenticated clients to bypass mTLS. The QUIC/HTTP3 path resolves TLS configuration with Router.GetTLSGetClientInfo(), which performs a direct, case-sensitive map lookup on hostHTTPTLSConfig[info.ServerName].

This is inconsistent with the later HTTP host routing semantics, where the same request host can still match wildcard or case-insensitive Host rules after the HTTP/3 TLS handshake has already fallen back to the default TLS configuration. Two exploit paths are confirmed:

1. Host("*.example.com") with tls.options=mtls: HTTP/2 requires a client certificate, but HTTP/3 reaches the protected backend without one.
2. Host("api.example.com") with tls.options=mtls: HTTP/2 requires a client certificate, but HTTP/3 with mixed-case SNI/Host such as API.EXAMPLE.COM reaches the protected backend without one.

Confirmed versions:

• wildcard HTTP/3 bypass: v3.7.0, v3.7.1
• exact-host mixed-case HTTP/3 bypass: v3.6.17, v3.7.0, v3.7.1

Details

HTTP/3 installs a QUIC TLS callback in pkg/server/server_entrypoint_tcp_http3.go:

h3.Server = &http3.Server{
    Addr:      config.GetAddress(),
    Port:      config.HTTP3.AdvertisedPort,
    Handler:   httpsServer.Server.(*http.Server).Handler,
    TLSConfig: &tls.Config{GetConfigForClient: h3.getGetConfigForClient},
}

The callback is wired to the TCP router's TLS selector:

func (e *http3server) Switch(rt *tcprouter.Router) {
    e.lock.Lock()
    defer e.lock.Unlock()

    e.getter = rt.GetTLSGetClientInfo()
}

The selector in pkg/server/router/tcp/router.go only performs an exact map lookup:

func (r *Router) GetTLSGetClientInfo() func(info *tls.ClientHelloInfo) (*tls.Config, error) {
    return func(info *tls.ClientHelloInfo) (*tls.Config, error) {
        if tlsConfig, ok := r.hostHTTPTLSConfig[info.ServerName]; ok {
            return tlsConfig, nil
        }

        return r.httpsTLSConfig, nil
    }
}

That creates two mismatches:

• wildcard keys such as *.example.com are never matched for api.example.com
• lower-case router keys such as api.example.com are not matched for mixed-case SNI such as API.EXAMPLE.COM

On the later HTTP request path, the same host can still match wildcard or case-insensitive Host rules through the muxer. The HTTP/3 TLS handshake path falls back to the default TLS config before that routing decision happens. If the default TLS config does not require a client certificate, the QUIC handshake succeeds without mTLS, and the later HTTP…

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.

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.

Summary

There is 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.

Patches

• https://github.com/traefik/traefik/releases/tag/v3.6.18
• https://github.com/traefik/traefik/releases/tag/v3.7.3

For more information

If you have any questions or comments about this advisory, please open an issue.

<details> <summary>Original Description</summary>

Summary

Traefik's HTTP/3 TLS configuration selection can ignore router-specific TLSOptions and allow unauthenticated clients to bypass mTLS. The QUIC/HTTP3 path resolves TLS configuration with Router.GetTLSGetClientInfo(), which performs a direct, case-sensitive map lookup on hostHTTPTLSConfig[info.ServerName].

This is inconsistent with the later HTTP host routing semantics, where the same request host can still match wildcard or case-insensitive Host rules after the HTTP/3 TLS handshake has already fallen back to the default TLS configuration. Two exploit paths are confirmed:

1. Host("*.example.com") with tls.options=mtls: HTTP/2 requires a client certificate, but HTTP/3 reaches the protected backend without one.
2. Host("api.example.com") with tls.options=mtls: HTTP/2 requires a client certificate, but HTTP/3 with mixed-case SNI/Host such as API.EXAMPLE.COM reaches the protected backend without one.

Confirmed versions:

• wildcard HTTP/3 bypass: v3.7.0, v3.7.1
• exact-host mixed-case HTTP/3 bypass: v3.6.17, v3.7.0, v3.7.1

Details

HTTP/3 installs a QUIC TLS callback in pkg/server/server_entrypoint_tcp_http3.go:

h3.Server = &http3.Server{
    Addr:      config.GetAddress(),
    Port:      config.HTTP3.AdvertisedPort,
    Handler:   httpsServer.Server.(*http.Server).Handler,
    TLSConfig: &tls.Config{GetConfigForClient: h3.getGetConfigForClient},
}

The callback is wired to the TCP router's TLS selector:

func (e *http3server) Switch(rt *tcprouter.Router) {
    e.lock.Lock()
    defer e.lock.Unlock()

    e.getter = rt.GetTLSGetClientInfo()
}

The selector in pkg/server/router/tcp/router.go only performs an exact map lookup:

func (r *Router) GetTLSGetClientInfo() func(info *tls.ClientHelloInfo) (*tls.Config, error) {
    return func(info *tls.ClientHelloInfo) (*tls.Config, error) {
        if tlsConfig, ok := r.hostHTTPTLSConfig[info.ServerName]; ok {
            return tlsConfig, nil
        }

        return r.httpsTLSConfig, nil
    }
}

That creates two mismatches:

• wildcard keys such as *.example.com are never matched for api.example.com
• lower-case router keys such as api.example.com are not matched for mixed-case SNI such as API.EXAMPLE.COM

On the later HTTP request path, the same host can still match wildcard or case-insensitive Host rules through the muxer. The HTTP/3 TLS handshake path falls back to the default TLS config before that routing decision happens. If the default TLS config does not require a client certificate, the QUIC handshake succeeds without mTLS, and the later HTTP…