CVE-2026-25949: 
NixOS vulnerability analysis and mitigation

CVE-2026-25949 is a denial-of-service vulnerability in Traefik, the open-source HTTP reverse proxy and load balancer, caused by a TCP readTimeout bypass via the PostgreSQL STARTTLS handshake. An unauthenticated remote attacker can send the 8-byte Postgres SSLRequest prelude to any exposed TCP entrypoint and then stall, causing connections to remain open indefinitely and exhausting file descriptors and goroutines. All Traefik versions up to and including v3.6.7 are affected; v3.6.8 contains the fix. The vulnerability carries a CVSS v3.1 base score of 7.5 (High) (GitHub Advisory, Red Hat Bugzilla).

The root cause is uncontrolled resource consumption (CWE-400) combined with allocation of resources without limits or throttling (CWE-770). In Traefik's TCP router protocol detection path (pkg/server/router/tcp/router.go), when the Postgres SSLRequest 8-byte signature (0x00 0x00 0x00 0x08 0x04 0xD2 0x16 0x2F) is detected, the code prematurely calls conn.SetDeadline(time.Time{}) — clearing all connection deadlines — before entering servePostgres. The Postgres handler (pkg/server/router/tcp/postgres.go) then blocks indefinitely waiting for a TLS ClientHello with no deadline enforced, so an attacker who stops sending after the initial prelude holds the connection open forever. This fast-path deadline-clearing bug is conceptually identical to CVE-2026-22045, which affected the TLS handshake path; CVE-2026-25949 is the same failure mode triggered via the Postgres STARTTLS detection path. The vulnerability is reachable on any TCP entrypoint — including standard HTTP entrypoints — regardless of whether any Postgres or TCP routers are configured (GitHub Advisory, Fix Commit).

Successful exploitation results in a complete availability impact against the Traefik proxy process, with no confidentiality or integrity impact. Each stalled connection consumes one goroutine and one file descriptor; at sufficient concurrency, Traefik reaches OS-level process limits (FD exhaustion, goroutine pressure, memory), taking the proxy entirely offline. Because Traefik typically fronts multiple backend services, its unavailability can cascade to all proxied applications, making this a high-impact denial-of-service condition for any deployment with internet-exposed entrypoints (GitHub Advisory).

A public proof-of-concept Python script is included in the official security advisory and requires only Python 3 and network access to a vulnerable Traefik entrypoint — no authentication or special privileges are needed. The EPSS score is approximately 0.016–0.019%, indicating low current exploitation probability, and there is no evidence of in-the-wild exploitation or threat actor attribution at this time. The vulnerability is not listed in the CISA Known Exploited Vulnerabilities catalog (GitHub Advisory).

1. Reconnaissance: Identify internet-exposed Traefik instances (v3.6.7 or earlier) using tools such as Shodan or Censys, searching for Traefik's default response headers or known management ports.
2. Connect to the target entrypoint: Establish a TCP connection to any exposed Traefik entrypoint (e.g., port 80 or 443), which uses the TCP switcher for protocol detection.
3. Send the Postgres SSLRequest prelude: Transmit the 8-byte Postgres STARTTLS magic bytes (\x00\x00\x00\x08\x04\xD2\x16\x2F) immediately after connecting. Traefik's protocol detection identifies this as a Postgres SSLRequest, clears all connection deadlines, and responds with a single byte (S).
4. Stall the connection: Stop sending any further data. The connection remains open indefinitely past the configured readTimeout, consuming one goroutine and one file descriptor in the Traefik process.
5. Scale the attack: Repeat steps 2–4 concurrently across hundreds or thousands of connections (the PoC uses 300). As FD and goroutine limits are reached, Traefik becomes unable to accept new connections and the proxy goes offline (GitHub Advisory).

• Network: Large number of TCP connections to Traefik entrypoints that remain in ESTABLISHED state far beyond the configured readTimeout; connections where only 8–9 bytes were exchanged (SSLRequest + single-byte S response) with no subsequent traffic.
• Process: Rapidly growing file descriptor count for the Traefik process (observable via /proc/<pid>/fd on Linux); elevated goroutine count visible in Traefik's debug/metrics endpoints; Traefik process approaching or hitting OS ulimit for open files.
• Logs: Absence of normal request completion log entries despite high connection counts; potential error messages such as Error while setting deadline in Traefik logs if the fix is partially applied; Traefik access logs showing connections with no routed requests.
• System: ss -tnp or netstat showing many connections in ESTABLISHED state to Traefik's listen port with no data transfer activity over extended periods (GitHub Advisory).

Upgrade Traefik to v3.6.8 or later, which moves the conn.SetDeadline(time.Time{}) call to after the full STARTTLS negotiation and TLS ClientHello have been successfully read, rather than before entering the blocking Postgres handler. No configuration-based workaround is documented; the fix requires a code change. As a temporary network-level mitigation, operators may consider rate-limiting or restricting access to Traefik entrypoints at the firewall or load balancer level to reduce exposure until the upgrade can be applied (Traefik Release v3.6.8, Fix Commit).

The vulnerability was reported by researcher manizada and published by Traefik maintainer nmengin on February 12, 2026. Red Hat tracked it as a high-severity issue in their Bugzilla system. Community coverage appeared on dev.to, The Hacker Wire (Mastodon and Bluesky), and security aggregators including VulDB and Vulners shortly after disclosure. The fix was included in Traefik v3.6.8 alongside another CVE (CVE-2025-68121), and the release received positive community engagement on GitHub (Red Hat Bugzilla, Traefik Release v3.6.8).