CVE-2026-26999: 
NixOS vulnerability analysis and mitigation

CVE-2026-26999 is a Denial of Service vulnerability in Traefik's TCP router TLS handshake handling, commonly described as a Slowloris-style DoS. It affects Traefik versions up to and including v2.11.37 (v2.x branch) and v3.0.0 through v3.6.8 (v3.x branch). The vulnerability was disclosed on March 4, 2026, via a GitHub Security Advisory, and published to the NVD on March 5, 2026. It carries a CVSS v3.1 base score of 7.5 (High) (GitHub Advisory, Traefik Advisory).

The root cause lies in pkg/server/router/tcp/router.go within the (*Router).ServeTCP function, classified as CWE-400 (Uncontrolled Resource Consumption) and CWE-772 (Missing Release of Resource after Effective Lifetime). After sniffing a TLS Client Hello during protocol detection, the router calls conn.SetDeadline(time.Time{}), which clears the connection-level read deadline entirely before the TLS handshake completes. When a TLS handshake read error occurs, the code silently attempts a second handshake with different parameters, ignoring the initial error. An unauthenticated remote attacker can exploit this by sending a partial TLS record header (sufficient to trigger the TLS sniffing path) and then halting further data transmission, causing the subsequent handshake reads to block indefinitely with no enforced timeout (GitHub Advisory, Traefik Advisory).

Successful exploitation causes resource exhaustion on the affected Traefik instance: each stalled connection consumes a file descriptor, a goroutine, and potentially additional memory from buffering. By opening many such connections in parallel, an attacker can exhaust the system's file descriptor and goroutine limits, degrading or completely denying availability of all services routed through the affected entrypoint. There is no confidentiality or integrity impact — the vulnerability is purely an availability (DoS) issue (GitHub Advisory, Red Hat Bugzilla).

A proof-of-concept (PoC) integration harness (poc.zip) was included with the original advisory submission, demonstrating the stall behavior in vulnerable versions versus the fixed behavior. No in-the-wild exploitation has been reported, and the vulnerability is not listed in the CISA Known Exploited Vulnerabilities (KEV) catalog. The EPSS score is approximately 0.012% (6th percentile), indicating a low current probability of active exploitation. No threat actor attribution has been identified (GitHub Advisory, Traefik Advisory).

1. Reconnaissance: Identify internet-facing Traefik instances with TCP routers configured for TLS forwarding, running versions ≤ v2.11.37 or v3.0.0–v3.6.8, using tools like Shodan or Censys targeting Traefik's default ports (e.g., 443, 8443).
2. Initiate TCP connection: Open a raw TCP connection to the Traefik entrypoint that handles TLS-routed traffic.
3. Send partial TLS record: Transmit a partial TLS record header — enough bytes to trigger Traefik's protocol sniffing path and cause it to identify the connection as TLS — but do not send a complete Client Hello.
4. Halt transmission: Stop sending any further data. After the initial sniffing deadline expires, Traefik clears the connection deadline via conn.SetDeadline(time.Time{}) and enters the TLS handshake phase with no timeout enforced.
5. Hold connection open: The TLS handshake read blocks indefinitely, consuming a file descriptor and goroutine for the duration of the stalled connection.
6. Scale the attack: Open hundreds or thousands of such stalled connections in parallel to exhaust the server's file descriptor and goroutine limits, causing a denial of service for all services on the affected entrypoint (GitHub Advisory, Traefik Advisory).

• Network: Large number of long-lived TCP connections to Traefik TLS entrypoints from one or more source IPs that never complete a TLS handshake; connections remaining open for minutes or hours with no data exchange after the initial partial bytes.
• Process/Runtime: Rapidly increasing goroutine count in Traefik process metrics (e.g., via /metrics Prometheus endpoint — go_goroutines metric spiking); file descriptor exhaustion errors in Traefik logs (e.g., too many open files).
• Logs: Traefik access or error logs showing repeated TLS handshake timeout or read error messages from the same or rotating source IPs; absence of completed TLS handshakes from connections that remain open.
• System: OS-level ulimit or /proc/<pid>/fd showing file descriptor count approaching system limits for the Traefik process; elevated memory usage consistent with many buffered but inactive connections.

Traefik has released patched versions v2.11.38 (for the v2.x branch) and v3.6.9 (for the v3.x branch), both of which fix TLS handshake error handling by preserving or enforcing a deadline through the handshake phase. The vendor has confirmed no workaround is available — upgrading to a patched version is the only remediation. Users on OpenSUSE can also apply the distribution-provided security update (Traefik v2.11.38 Release, Traefik v3.6.9 Release, Traefik Advisory).

The Traefik maintainer emilevauge published the advisory on March 4, 2026, and the fix was contributed by juliens via PR #12692. The Traefik community forum acknowledged the security updates for both the 2.11 and 3.6 branches. Red Hat tracked the issue via Bugzilla (Bug 2444874) with high severity. OpenSUSE issued a security announcement for the updated Traefik packages. Social media activity was limited, with a brief mention on Mastodon via @thehackerwire (Traefik Community Forum, Red Hat Bugzilla).