The following document describes an identified vulnerability in the Traefik reverse proxy up to and including version 3.7.11.
Product Vendor
Product Description
Traefik is an open-source reverse proxy and ingress controller, widely deployed in container and Kubernetes environments. The project's official website is traefik.io. It has supported HTTP/3 since 2022, and the latest versions at the time of testing were 2.11.55 and 3.7.11.
Vulnerabilities List
One vulnerability was identified within Traefik:
- Request Read Timeout Not Applied to HTTP/3
Affected Version
Versions 2.8.2 through 2.11.55, and versions 3.0.0 through 3.7.11.
Summary of Findings
Bishop Fox staff identified one vulnerability in Traefik. This vulnerability could allow an unauthenticated remote user to hold requests open indefinitely, occupying one upstream connection per request and denying service to legitimate traffic.
Traefik provides a request read timeout that is enabled by default at 60 seconds and is documented as the maximum duration for reading an entire request, including its body. The setting is applied as a deadline on the underlying TCP connection. HTTP/3 does not use one, and Traefik's HTTP/3 server was constructed without a timeout of any kind, so the setting had no effect on that protocol.
Bishop Fox staff demonstrated the issue on version 3.7.10 using the official release binary, measuring the lifetime of the upstream connection at the backend. Under identical configuration, a slow upload over HTTP/1.1 was released at the configured value, while the same upload over HTTP/3 ran to completion with the upstream connection held throughout.
The condition was introduced in version 2.8.2, released in August 2022, when a change to an underlying library removed the component that had been carrying the timeouts. Versions before 2.8.2 are not affected.
Impact
The significance of this issue is not that a hardening option was left unset. The setting is enabled by default, is documented without protocol qualification, and appears in the running configuration, so an organization has every reason to believe a 60-second bound is in force. On HTTP/3 it was silently absent.
Each held request occupies one upstream connection for as long as the client chooses, at negligible cost to the client, and a single client can open many. Backends with bounded connection pools are the practical pressure point. The traffic remains well formed and low in volume, so it is unlikely to be identified as an attack by rate-based defenses.
Because the condition dates to August 2022, it has been present across four years of releases. Versions 2.8.2 through 2.10.x and 3.0 through 3.6 have reached end of maintenance and will not receive a patch on their own branches; organizations running those versions must move to a supported branch to obtain the fix.
Solution
Update to version 2.11.56 or 3.7.12.
Timeline
- 08/10/2026: Initial discovery
- 08/12/2026: Contact with vendor
- 08/24/2026: Vendor acknowledged the vulnerability and produced a fix
- 08/26/2026: Fixed versions released
- 08/28/2026: Vulnerability publicly disclosed
Credits
Shad Malloy, Managing Sr. Consultant II, Bishop Fox ([email protected])
Request Read Timeout Not Applied to HTTP/3
CVE ID: CVE coming soon (GHSA-7ghq-v6jf-g56c)
Vulnerability Type: Uncontrolled resource consumption
Access Vector: Remote
Impact: Denial of service
Security Risk: Medium
CWE: CWE-770, Allocation of Resources Without Limits or Throttling
Traefik applies its request read timeout by setting a read deadline on the TCP connection, in pkg/server/server_entrypoint_tcp.go
. A deadline on a TCP connection cannot reach a QUIC stream. The HTTP/3 server, constructed in pkg/server/server_entrypoint_tcp_http3.go
, reuses the HTTPS server's handler but inherits none of its timeouts.
In version 2.8.1 the HTTP/3 server was built around an embedded standard-library server that carried the read timeout. Version 2.8.2 removed that component in response to a change in the underlying QUIC library, and only the handler was carried across.
Bishop Fox staff reproduced the issue using the official release binary, a self-signed certificate, and a backend that reads the request body before responding. A backend that responds to the request headers alone allows Traefik to release the upstream connection immediately and conceals the behavior.
The same slow upload was sent over each protocol, holding longer than the timeout under evaluation. Measured at the backend, with the documented 60-second default and a 92-second hold, the HTTP/1.1 request released the upstream connection at 59.99 seconds while the HTTP/3 request held it for the full 92.94 seconds. With the timeout configured to 5 seconds and a 30-second hold, the corresponding figures were 4.99 seconds and 30.98 seconds. The HTTP/1.1 arm is the control, and it establishes that the timeout was live on the same binary and configuration.
Vendor Response
Traefik Labs confirmed that the timeout was not applied to HTTP/3 and that the documentation did not record the exception and released fixes on both maintained branches within twelve days of the report.
Subscribe to our blog
Be first to learn about latest tools, advisories, and findings.
Thank You! You have been subscribed.
Recommended Posts