CVE-2026-25949: Traefik STARTTLS DoS Vulnerability

CVE-2026-25949 Overview

CVE-2026-25949 is a Denial of Service (DoS) vulnerability affecting Traefik, a popular HTTP reverse proxy and load balancer. The vulnerability exists in how Traefik handles STARTTLS requests, specifically Postgres SSLRequest preludes. An unauthenticated attacker can bypass Traefik's entrypoint respondingTimeouts.readTimeout setting by sending the 8-byte Postgres SSLRequest (STARTTLS) prelude and then stalling the connection. This causes connections to remain open indefinitely, leading to resource exhaustion and denial of service conditions.

Critical Impact

Unauthenticated remote attackers can exhaust server resources by creating persistent connections that bypass timeout controls, rendering Traefik-protected services unavailable.

Affected Products

• Traefik versions prior to 3.6.8

Discovery Timeline

• 2026-02-12 - CVE-2026-25949 published to NVD
• 2026-02-12 - Last updated in NVD database

Technical Details for CVE-2026-25949

Vulnerability Analysis

This vulnerability is classified as CWE-400 (Uncontrolled Resource Consumption). The flaw resides in how Traefik processes Postgres STARTTLS negotiation sequences. When a client initiates a Postgres SSLRequest, the server enters a specific code path designed to handle the TLS upgrade. However, the implementation removed connection deadlines after the STARTTLS negotiation began, allowing malicious clients to keep connections open indefinitely without completing the handshake.

The attack is particularly concerning because it requires no authentication and can be executed remotely over the network. An attacker simply needs to establish a TCP connection, send the 8-byte Postgres SSLRequest prelude, and then intentionally stall without completing further communication. Each stalled connection consumes server resources, and by repeating this attack pattern, an attacker can exhaust available connection slots.

Root Cause

The root cause lies in the TCP router's handling of Postgres connections in pkg/server/router/tcp/router.go. The original implementation explicitly removed read/write deadlines after detecting a Postgres connection, delegating timeout management to the underlying TCP server. However, this created a gap where STARTTLS requests could bypass the configured respondingTimeouts.readTimeout settings, leaving connections without proper timeout enforcement.

Attack Vector

The attack vector is network-based and requires no privileges or user interaction. An attacker initiates a TCP connection to a Traefik entrypoint configured to handle Postgres traffic. By sending the 8-byte Postgres SSLRequest prelude (which signals a STARTTLS upgrade request) and then ceasing communication, the attacker forces the server to keep the connection open while waiting for further data that never arrives. This simple attack pattern can be automated and parallelized to rapidly consume available resources.

// Vulnerable code path in pkg/server/router/tcp/router.go
// The following code removed deadlines for Postgres connections, enabling the attack

	if postgres {
		// Remove read/write deadline and delegate this to underlying TCP server.
		if err := conn.SetDeadline(time.Time{}); err != nil {
			log.Error().Err(err).Msg("Error while setting deadline")
		}

		r.servePostgres(r.GetConn(conn, getPeeked(br)))
		return
	}

Source: GitHub Commit Changes

The fix removes the explicit deadline clearing, allowing proper timeout enforcement to apply to Postgres STARTTLS connections:

// Fixed code in pkg/server/router/tcp/router.go
// Deadline clearing removed, allowing timeout enforcement

	if postgres {
		r.servePostgres(r.GetConn(conn, getPeeked(br)))
		return
	}

Source: GitHub Commit Changes

Detection Methods for CVE-2026-25949

Indicators of Compromise

• Unusually high number of established TCP connections to Traefik entrypoints
• Connections showing extended idle time in ESTABLISHED state without data transfer
• Resource exhaustion alerts on Traefik instances (file descriptors, memory)
• Postgres STARTTLS requests that never complete the TLS handshake

Detection Strategies

• Monitor for abnormal spikes in connection counts to Traefik TCP entrypoints
• Implement network-level logging to identify sources sending Postgres SSLRequest preludes without completing handshakes
• Deploy connection tracking rules to flag connections that remain idle after sending initial bytes
• Use intrusion detection systems to identify patterns consistent with slowloris-style DoS attacks

Monitoring Recommendations

• Configure alerting for connection pool exhaustion on Traefik instances
• Monitor system-level metrics including open file descriptors and socket states
• Track the ratio of completed versus stalled Postgres TLS handshakes
• Implement network flow analysis to identify unusual connection patterns from single sources

How to Mitigate CVE-2026-25949

Immediate Actions Required

• Upgrade Traefik to version 3.6.8 or later immediately
• Implement connection rate limiting at the network perimeter as a temporary measure
• Review and configure appropriate respondingTimeouts.readTimeout values
• Consider deploying a Web Application Firewall (WAF) to filter malicious connection patterns

Patch Information

Traefik has released version 3.6.8 which addresses this vulnerability. The fix modifies the TCP router behavior to maintain proper deadline enforcement for Postgres STARTTLS connections, preventing indefinite connection stalling. The patch is available through the official GitHub release. For detailed code changes, review the security commit.

Workarounds

• Implement network-level rate limiting on connections to Traefik entrypoints
• Deploy a reverse proxy or load balancer in front of Traefik with strict timeout enforcement
• Use firewall rules to limit concurrent connections from single IP addresses
• Consider temporarily disabling Postgres TCP routing if not actively required

# Example: Rate limiting with iptables
# Limit new connections to Traefik port 5432 (Postgres) to 10 per minute per IP
iptables -A INPUT -p tcp --dport 5432 -m state --state NEW -m recent --set
iptables -A INPUT -p tcp --dport 5432 -m state --state NEW -m recent --update --seconds 60 --hitcount 10 -j DROP