V2: Traefik: respondingTimeouts.readTimeout is not applied to HTTP/3, leaving slow-body uploads unbounded (CVE-2026-88012)
A medium severity vulnerability in Traefik affects HTTP/3 entry points where the respondingTimeouts.readTimeout setting is not applied. This setting, which limits the time to read the entire request including its body, works for HTTP/1.1 and HTTP/2 but is ineffective for HTTP/3 due to architectural differences. As a result, an unauthenticated client can keep a request open indefinitely by trickling the request body slowly, consuming upstream connections and potentially exhausting backend connection pools. The issue affects Traefik versions from 2.8.2 up to but not including 2.11.56, and from 3.0.0 up to but not including 3.7.12. Patches are available in versions 2.11.56 and 3.7.12.
AI Analysis
Technical Summary
Traefik's HTTP/3 implementation does not enforce the respondingTimeouts.readTimeout setting because it applies a deadline on the TCP connection, which HTTP/3 (based on QUIC) does not use. This omission allows clients to hold HTTP/3 requests open indefinitely by slowly sending the request body, tying up one upstream connection per request at minimal client cost. The vulnerability was introduced in version 2.8.2 due to a quic-go API change removing the embedded http.Server that enforced timeouts. It affects all releases from 2.8.2 through 2.10.x and 3.0 through 3.6, which are no longer maintained. The recommended remediation is to upgrade to Traefik v2.11.56 or v3.7.12 where the issue is fixed.
Potential Impact
The vulnerability allows unauthenticated clients to keep HTTP/3 requests open indefinitely by trickling the request body slowly, which consumes one upstream connection per request. This can exhaust backend connection pools, potentially leading to denial of service conditions for legitimate users. There is no impact on confidentiality or integrity, only availability (denial of service).
Mitigation Recommendations
A patch is available and should be applied. Users should upgrade to Traefik version 2.11.56 or later, or 3.7.12 or later, where the respondingTimeouts.readTimeout is correctly enforced on HTTP/3. Versions 2.8.2 through 2.10.x and 3.0 through 3.6 are no longer maintained and will not receive backported fixes. No other mitigations are indicated.
V2: Traefik: respondingTimeouts.readTimeout is not applied to HTTP/3, leaving slow-body uploads unbounded (CVE-2026-88012)
Description
A medium severity vulnerability in Traefik affects HTTP/3 entry points where the respondingTimeouts.readTimeout setting is not applied. This setting, which limits the time to read the entire request including its body, works for HTTP/1.1 and HTTP/2 but is ineffective for HTTP/3 due to architectural differences. As a result, an unauthenticated client can keep a request open indefinitely by trickling the request body slowly, consuming upstream connections and potentially exhausting backend connection pools. The issue affects Traefik versions from 2.8.2 up to but not including 2.11.56, and from 3.0.0 up to but not including 3.7.12. Patches are available in versions 2.11.56 and 3.7.12.
CVSS v3.1
Score 5.3medium
Affected software
Run on your own infrastructure? Check whether these packages are installed with threat-finder — our free open-source scanner.
Weaknesses
AI-Powered Analysis
Machine-generated threat intelligence
Technical Analysis
Traefik's HTTP/3 implementation does not enforce the respondingTimeouts.readTimeout setting because it applies a deadline on the TCP connection, which HTTP/3 (based on QUIC) does not use. This omission allows clients to hold HTTP/3 requests open indefinitely by slowly sending the request body, tying up one upstream connection per request at minimal client cost. The vulnerability was introduced in version 2.8.2 due to a quic-go API change removing the embedded http.Server that enforced timeouts. It affects all releases from 2.8.2 through 2.10.x and 3.0 through 3.6, which are no longer maintained. The recommended remediation is to upgrade to Traefik v2.11.56 or v3.7.12 where the issue is fixed.
Potential Impact
The vulnerability allows unauthenticated clients to keep HTTP/3 requests open indefinitely by trickling the request body slowly, which consumes one upstream connection per request. This can exhaust backend connection pools, potentially leading to denial of service conditions for legitimate users. There is no impact on confidentiality or integrity, only availability (denial of service).
Mitigation Recommendations
A patch is available and should be applied. Users should upgrade to Traefik version 2.11.56 or later, or 3.7.12 or later, where the respondingTimeouts.readTimeout is correctly enforced on HTTP/3. Versions 2.8.2 through 2.10.x and 3.0 through 3.6 are no longer maintained and will not receive backported fixes. No other mitigations are indicated.
Technical Details
- Gcve Source
- db.gcve.eu
- Osv Id
- GHSA-7ghq-v6jf-g56c
- Osv Schema Version
- 1.4.0
- Aliases
- ["CVE-2026-88012"]
- Ecosystems
- ["Go"]
- Database Specific Severity
- MODERATE
- Cvss Version
- 3.1
Threat ID: 6aa3295e91cc7f3848d18c1d
Added to database: 09/10/2026, 22:04:14 UTC
Last enriched: 09/10/2026, 22:05:50 UTC
Last updated: 09/10/2026, 22:05:50 UTC
Views: 1
Community Reviews
0 reviewsCrowdsource mitigation strategies, share intel context, and vote on the most helpful responses. Sign in to add your voice and help keep defenders ahead.
Want to contribute mitigation steps or threat intel context? Sign in or create an account to join the community discussion.
Actions
Updates to AI analysis require Pro Console access. Upgrade inside Console → Billing.
Need more coverage?
Upgrade to Pro Console for AI refresh and higher limits.
For incident response and remediation, OffSeq services can help resolve threats faster.
Latest Threats
Check if your credentials are on the dark web
Instant breach scanning across billions of leaked records. Free tier available.