# Traefik | Version Through 3.7.11

Traefik's default 60s request read timeout is a TCP deadline that never reaches HTTP/3 QUIC streams, letting clients hold upstream connections open indefinitely and exhaust backend pools.

- Payout: Research
- Severity: medium
- Program: Traefik
- Write-up by: Shad Malloy
- Disclosed: 2026-08-31
- Write-up quality: 7/10
- Original: https://bishopfox.com/blog/traefik-version-through-3-7-11
- Library page: https://bugbountylibrary.com/r/blog%3Abishopfox-com-blog-traefik-version-through-3-7-11
- Tags: area:cloud domain:infra impact:dos kind:research platform:research sev:medium tech:go technique:regression technique:source-review vuln:dos

**Target:** HTTP/3 (QUIC) entrypoint in Traefik reverse proxy
**Root cause:** The read timeout is applied as a deadline on the TCP connection in server_entrypoint_tcp.go, which cannot reach a QUIC stream; the HTTP/3 server in server_entrypoint_tcp_http3.go reuses the HTTPS handler but inherits none of its timeouts.
**Steps:**
1. Configure Traefik with a backend that reads the full request body before responding (a header-only responder releases the upstream connection and hides the bug).
2. Send a slow upload over HTTP/1.1 holding longer than the configured read timeout; observe the upstream connection released at the timeout (e.g. 59.99s with 60s default).
3. Send the same slow upload over HTTP/3; observe the upstream connection held for the full client-chosen duration (e.g. 92.94s).
4. Repeat with a 5s timeout and 30s hold: HTTP/1.1 releases at 4.99s, HTTP/3 holds 30.98s.
5. Open many such HTTP/3 requests to occupy one upstream connection each and exhaust bounded backend connection pools.
**How found:** Noticed the read timeout is implemented as a TCP connection deadline, reasoned that a TCP deadline cannot reach a QUIC stream, and confirmed the HTTP/3 server was constructed without any timeout; then built a differential test with a body-reading backend and HTTP/1.1 as control on the same binary and config.
**Exploitation:** Unauthenticated remote client opens many HTTP/3 requests with slow bodies, each pinning one upstream connection for as long as the client chooses at negligible cost; well-formed low-volume traffic evades rate-based defenses and starves legitimate traffic on backends with bounded connection pools.
**Insight:** When a timeout is enforced at the transport layer (TCP deadline), check every alternate transport the server supports (QUIC/HTTP3, Unix sockets, TLS-terminated paths) for an equivalent enforcement point; use a backend that reads the body so connection release timing is observable, and always run the same-protocol control.