CVE-2026-32305
mTLS Bypass in Traefik via Fragmented TLS ClientHello
Publication date: 2026-03-20
Last updated on: 2026-03-24
Assigner: GitHub, Inc.
Description
Description
CVSS Scores
EPSS Scores
| Probability: | |
| Percentile: |
Meta Information
Affected Vendors & Products
| Vendor | Product | Version / Range |
|---|---|---|
| traefik | traefik | to 2.11.41 (exc) |
| traefik | traefik | From 3.0.0 (inc) to 3.6.11 (inc) |
| traefik | traefik | 3.7.0 |
Helpful Resources
Exploitability
| CWE ID | Description |
|---|---|
| CWE-287 | When an actor claims to have a given identity, the product does not prove or insufficiently proves that the claim is correct. |
| CWE-1188 | The product initializes or sets a resource with a default that is intended to be changed by the product's installer, administrator, or maintainer, but the default is not secure. |
Attack-Flow Graph
AI Powered Q&A
Can you explain this vulnerability to me?
[{'type': 'paragraph', 'content': "CVE-2026-32305 is a vulnerability in Traefik's TLS Server Name Indication (SNI) pre-sniffing logic that affects certain versions of Traefik. When a TLS ClientHello message is fragmented across multiple TLS records, Traefik attempts to extract the SNI by only peeking at the first TLS record and a fixed number of bytes. If the ClientHello is fragmented, this extraction fails with an EOF error, resulting in an empty SNI."}, {'type': 'paragraph', 'content': 'Because Traefik uses the extracted SNI to select the TLS configuration per route, failure to obtain the SNI causes the TCP router to fall back to the default TLS configuration, which by default does not require client certificates. This allows an attacker to bypass route-level mutual TLS (mTLS) enforcement by sending a fragmented ClientHello, causing Traefik to skip client certificate verification and route the request to services that should be protected by mTLS.'}, {'type': 'paragraph', 'content': "The root cause is that Traefik's early TLS policy decision is based on partial ClientHello data, which is insufficient for fragmented ClientHello messages, leading to a mismatch with the Go TLS library's later full ClientHello parsing."}] [2]
How can this vulnerability impact me? :
This vulnerability can allow an attacker to bypass mutual TLS (mTLS) authentication on services protected by Traefik. By exploiting the fragmented ClientHello message handling flaw, an attacker can connect to services that should require client certificate verification without providing a valid client certificate.
This means unauthorized users could gain access to sensitive services or data that are intended to be protected by mTLS, potentially leading to unauthorized access, data exposure, or other security breaches.
How does this vulnerability affect compliance with common standards and regulations (like GDPR, HIPAA)?:
I don't know
How can this vulnerability be detected on my network or system? Can you suggest some commands?
[{'type': 'paragraph', 'content': "This vulnerability involves Traefik's TLS SNI pre-sniffing logic failing when TLS ClientHello messages are fragmented across multiple records, causing fallback to a default TLS configuration that does not require client certificates. Detection involves identifying fragmented TLS ClientHello packets and observing if Traefik accepts connections without enforcing mutual TLS (mTLS) where it should."}, {'type': 'paragraph', 'content': 'A practical approach to detect exploitation attempts is to monitor network traffic for fragmented TLS ClientHello messages targeting Traefik services configured with route-level mTLS enforcement. Tools like Wireshark or tcpdump can be used to capture and analyze TLS handshakes.'}, {'type': 'list_item', 'content': "Use tcpdump to capture TLS ClientHello packets and check for fragmentation: tcpdump -i <interface> 'tcp port 443 and (((ip[2:2] - ((ip[0]&0xf)<<2)) - ((tcp[12]&0xf0)>>2)) > 0)' -w capture.pcap"}, {'type': 'list_item', 'content': 'Analyze the capture with Wireshark to filter ClientHello messages and check if they are fragmented across multiple TLS records.'}, {'type': 'paragraph', 'content': 'Additionally, reviewing Traefik logs for unexpected connections that bypass client certificate verification on routes configured to require mTLS may help detect exploitation.'}, {'type': 'paragraph', 'content': 'The advisory provides a proof-of-concept using a Python script with the tlsfuzzer framework to send fragmented ClientHello messages, which can be adapted for testing detection.'}] [2]
What immediate steps should I take to mitigate this vulnerability?
The primary mitigation is to upgrade Traefik to a patched version that fixes the vulnerability. The fixed versions are 2.11.41, 3.6.11, and 3.7.0-ea.2.
- Upgrade Traefik to version 2.11.41 or later if using the 2.11.x series.
- Upgrade Traefik to version 3.6.11 or later if using the 3.6.x series.
- Upgrade Traefik to version 3.7.0-ea.2 or later if using the 3.7.x early access series.
As a temporary workaround, configure the default TLS configuration in Traefik to require client certificates (RequireAndVerifyClientCert) instead of the default NoClientCert. This ensures that fallback TLS configurations still enforce mTLS, though it requires explicitly setting permissive TLS configs for hosts that do not require client certificates.
Review and update Traefik TLS configurations to avoid relying on the default TLS config for routes that require mTLS.