CVE-2026-32305: 
NixOS vulnerability analysis and mitigation

CVE-2026-32305 is an mTLS authentication bypass vulnerability in Traefik, an HTTP reverse proxy and load balancer, caused by improper handling of fragmented TLS ClientHello packets. When a ClientHello is split across multiple TLS records, Traefik's SNI pre-sniffing logic fails with an EOF and returns an empty SNI, causing the TCP router to fall back to the default (permissive) TLS configuration that does not require client certificates. This allows unauthenticated remote attackers to bypass route-level mutual TLS enforcement and access services that should require client certificate authentication. Affected versions include Traefik ≤ 2.11.40, 3.0.0-beta1 through 3.6.10, and 3.7.0-ea.1. The vulnerability was disclosed on March 20, 2026, with a CVSS v4 score of 7.8 (High) and a CVSS v3.1 score of 5.3 (Medium) (Github Advisory, Feedly).

The root cause is classified under CWE-287 (Improper Authentication), CWE-1188 (Insecure Default Initialization of Resource), and CWE-179 (Incorrect Behavior Order: Early Validation). In Traefik's router.go, the ServeTCP function calls clientHelloInfo, which peeks only the first TLS record (reading exactly 5 + recLen bytes) and attempts to extract the SNI from that partial data. When a ClientHello is fragmented across multiple TLS records, this pre-sniff parse fails with an EOF and returns an empty SNI — but still signals isTLS=true. The TCP router then applies the default TLS configuration (NoClientCert), which is permissive by default. The actual Go TLS handshake subsequently completes without requiring a client certificate, and the request is routed to the mTLS-protected host. A public PoC using the tlsfuzzer library (setting --record-size to a small value such as 500 bytes to force fragmentation) was included in the original advisory (Github Advisory).

Successful exploitation allows an unauthenticated remote attacker to bypass route-level mTLS enforcement and gain unauthorized access to backend services that are intended to be protected by mutual TLS client certificate authentication. The primary impact is on the confidentiality and integrity of downstream (subsequent) systems, as attackers can interact with protected services without presenting valid client credentials. This could expose sensitive APIs, internal microservices, or administrative endpoints to unauthorized access, and may facilitate lateral movement within environments relying on mTLS as a zero-trust boundary control (Github Advisory, Feedly).

A public proof-of-concept script using the tlsfuzzer Python library was included in the original security advisory, demonstrating the bypass by sending a fragmented ClientHello with a small TLS record size (e.g., 500 bytes). No evidence of in-the-wild exploitation or threat actor attribution has been reported as of the time of disclosure. The vulnerability is not listed in the CISA KEV catalog. The EPSS score is approximately 0.046% (0.000460), indicating a low current probability of exploitation in the wild (Github Advisory, Feedly).

1. Reconnaissance: Identify internet-facing Traefik instances running vulnerable versions (≤ 2.11.40, 3.0.0-beta1 through 3.6.10, or 3.7.0-ea.1) using tools like Shodan or Censys, targeting HTTPS/TLS endpoints where mTLS is enforced on specific routes.
2. Set up the exploit environment: Install the tlsfuzzer Python library (git clone https://github.com/tlsfuzzer/tlsfuzzer.git and pip install -r requirements.txt) to craft custom TLS handshake sequences with controlled record sizes.
3. Craft a fragmented ClientHello: Use the PoC script (frag_clienthello.py) with a small --record-size (e.g., 500 bytes) and a large padding extension (--padding-len 1200) to force the ClientHello to span multiple TLS records, ensuring the SNI extension falls outside the first record boundary.
4. Trigger the SNI extraction failure: Send the fragmented ClientHello to the target Traefik endpoint (e.g., python frag_clienthello.py --connect-host <target> --port 8443 --sni <protected-host> --record-size 500). Traefik's pre-sniff logic fails with EOF, returns an empty SNI, and applies the default permissive TLS config.
5. Complete the handshake without a client certificate: The Go TLS stack completes the handshake without requesting or verifying a client certificate, as the default NoClientCert policy is in effect.
6. Access the protected service: Send an HTTP request (e.g., GET / HTTP/1.1\r\nHost: <protected-host>) over the established TLS session to interact with the mTLS-protected backend service without valid client credentials (Github Advisory).

• Network: Inbound TLS connections to Traefik where the ClientHello is split across multiple TLS records (record size significantly smaller than typical, e.g., ≤ 512 bytes); connections to mTLS-protected routes that complete without a CertificateRequest/Certificate exchange in the TLS handshake.
• Logs: Traefik access logs showing successful HTTPS requests to mTLS-protected routes from clients that did not present a client certificate; absence of client certificate fields in Traefik's TLS debug logs for connections to routes configured with RequireAndVerifyClientCert.
• Logs: Traefik debug-level logs showing SNI extraction returning an empty string ("") for connections that subsequently succeed — indicating fallback to the default TLS configuration.
• Network: Use of the tlsfuzzer library or similar TLS fuzzing tools generating non-standard TLS record fragmentation patterns detectable via network inspection or IDS signatures for anomalous TLS record sizes.

Traefik has released patched versions addressing this vulnerability: v2.11.41 (2.x series), v3.6.11 (3.6.x series), and v3.7.0-ea.2 (3.7.x early access series). Upgrading to one of these versions is the recommended remediation, as the fix adds proper support for fragmented TLS ClientHello parsing (v2.11.41 Release, v3.6.11 Release, v3.7.0-ea.2 Release). As a temporary workaround for environments that cannot immediately upgrade, configure the default TLS options to use RequireAndVerifyClientCert, and explicitly assign a permissive (NoClientCert) TLS option to any routes that should not require client certificates — this prevents the fallback from granting unintended access (Github Advisory).

The Traefik maintainer nmengin published the security advisory on March 20, 2026, and the Traefik community forum posted a dedicated security update announcement covering the affected and patched versions (Traefik Community). Red Hat tracked the vulnerability via Bugzilla and published a CVE advisory, indicating downstream impact on Red Hat products packaging Traefik (Red Hat CVE). OpenSUSE also issued security announcements for their Traefik packages, and the vulnerability was picked up by multiple vulnerability aggregators and Linux security news outlets shortly after disclosure.