CVE-2026-88878 in Traefik
Summary
by MITRE • 09/10/2026
Traefik is an HTTP reverse proxy and load balancer. In versions >= v2.8.2 through <= v2.11.55 and >= v3.0.0 through <= v3.7.11, the entryPoints.<name>.transport.respondingTimeouts settings — notably readTimeout, which is enabled by default at 60s — are not applied to the HTTP/3 request path. readTimeout is enforced as a deadline on the underlying TCP connection, which cannot be applied to a QUIC stream, and Traefik's HTTP/3 server is constructed without any timeout. As a result, on entry points with HTTP/3 enabled, an unauthenticated remote client that trickles request body bytes can hold a request open indefinitely and, with it, one upstream connection per request, exhausting bounded backend connection pools and causing denial of service. The issue was introduced in v2.8.2 when a quic-go API change removed the embedded http.Server that carried these timeouts. Fixed in v2.11.56 and v3.7.12.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Analysis
by VulDB Data Team • 09/10/2026
Traefik, widely deployed as an HTTP reverse proxy and load balancer to manage traffic flow between clients and backend services, contains a critical configuration enforcement flaw affecting its handling of the QUIC protocol within versions ranging from 2.8.2 through 3.0.0. The vulnerability stems from a failure in applying standard transport-level timeouts, specifically the readTimeout setting which is enabled by default at sixty seconds, to HTTP/3 request paths. While these timeout parameters are rigorously enforced for traditional TCP-based connections as deadlines on the underlying socket, they are entirely absent in the implementation of the HTTP/3 server component. This discrepancy arises because QUIC operates over UDP and manages streams internally within a single connection, meaning that standard TCP-level timeouts cannot be directly mapped to individual QUIC streams without explicit application-layer logic. Consequently, when an entry point is configured with HTTP/3 enabled, the proxy does not impose any time-based limits on how long it will wait for data from a client during the request body transmission phase.
The operational impact of this architectural oversight allows unauthenticated remote attackers to execute denial-of-service attacks by exploiting the lack of timeout enforcement. By trickling small amounts of request body bytes at intervals slower than an implicit or default threshold, an attacker can keep HTTP/3 requests open indefinitely. Each such active request consumes one upstream connection from Traefik’s bounded backend connection pool. Since these connections are held open without expiration due to the missing readTimeout logic for QUIC streams, a sustained attack using multiple concurrent slow-request sessions will eventually exhaust all available backend connections. Once the connection pool is depleted, legitimate traffic cannot be proxied to backend services, resulting in a complete service outage for users attempting to access applications behind the Traefik proxy. This scenario effectively turns a configuration parameter intended for reliability into an unmitigated attack vector due to protocol-specific implementation gaps.
From a vulnerability classification perspective, this issue aligns with CWE-400, which describes Uncontrolled Resource Consumption, as the application fails to limit the amount of resources consumed by user-controlled input or interaction patterns. Furthermore, it relates to CWE-613, Insufficient Session Expiration, in the context that session-like state (the open upstream connection) is not properly terminated after a reasonable period of inactivity specific to the protocol layer. In terms of adversarial tactics, this vulnerability facilitates Denial-of-Service attacks categorized under MITRE ATT&CK technique T1499, Endpoint Denial of Service, specifically through resource exhaustion via slow-rate or low-and-slow attack patterns that bypass standard network-level timeouts by operating within the application’s accepted protocol parameters. The root cause was introduced in version 2.8.2 when an update to the quic-go API removed the embedded http.Server structure that previously carried these timeout configurations, leaving a gap where no equivalent mechanism was implemented for the new HTTP/3 server construction logic.
To mitigate this vulnerability and restore service resilience against slow-request attacks over QUIC, organizations must upgrade their Traefik instances immediately to version 2.11.56 or version 3.7.12, which contain the necessary fixes to enforce timeout settings on HTTP/3 streams. Until an upgrade is feasible, administrators should consider disabling HTTP/3 support if it is not strictly required for their deployment architecture, thereby forcing all traffic through the TCP path where existing timeout mechanisms remain effective and secure. Additionally, implementing rate limiting or request throttling at a network perimeter device preceding Traefik can help mitigate the volume of concurrent connections initiated by malicious actors attempting to exhaust backend resources. Regular auditing of proxy configurations against known vulnerability databases is essential to ensure that protocol-specific implementations do not introduce unintended security regressions in reverse proxy deployments.