Traefik HTTP/3 readTimeout vulnerability affects slow-body uploads

According to the GitHub Security Advisory database, a medium severity vulnerability has been identified in Traefik versions v2.8.2 through v2.10.x and v3.0 through v3.6. This issue arises from the `respondingTimeouts.readTimeout` setting not being applied to HTTP/3 request paths. While this timeout is intended to bound the time for reading an entire request, including its body, it is enforced on the TCP connection and does not extend to QUIC streams used in HTTP/3. As a result, unauthenticated clients can trickle request bodies indefinitely, holding upstream connections open at negligible cost to themselves. This behavior can place significant pressure on backends with limited connection pools.

The vulnerability was introduced in v2.8.2 due to changes in the quic-go API, which removed the embedded `http.Server` that previously carried these timeout settings. Versions prior to v2.8.2 are unaffected. To address this issue, users are advised to upgrade to v2.11.56 or v3.7.12, as these versions restore timeout enforcement for HTTP/3.

Operators should verify whether HTTP/3 is enabled in their Traefik configuration and assess the impact on their backend connection pools. Deployments relying heavily on HTTP/3 may experience resource exhaustion if slow-body uploads are exploited. Before upgrading, ensure compatibility with the patched versions and confirm that other configurations remain intact. This vulnerability highlights the importance of reviewing timeout settings across all protocol layers, especially when adopting newer technologies like HTTP/3.