<?xml version='1.0' encoding='UTF-8'?>
<?xml-stylesheet href="/static/style.xsl" type="text/xsl"?>
<feed xmlns="http://www.w3.org/2005/Atom" xml:lang="en">
  <id>https://vulnerability.circl.lu/rss/recent/all/10</id>
  <title>Most recent entries from all</title>
  <updated>2026-10-02T03:35:56.156258+00:00</updated>
  <author>
    <name>Vulnerability-Lookup</name>
    <email>info@circl.lu</email>
  </author>
  <link href="https://vulnerability.circl.lu" rel="alternate"/>
  <generator uri="https://lkiesow.github.io/python-feedgen" version="1.0.0">python-feedgen</generator>
  <subtitle>Contains only the most 10 recent entries.</subtitle>
  <entry>
    <id>https://vulnerability.circl.lu/vuln/fkie_cve-2026-88012</id>
    <title>fkie_cve-2026-88012</title>
    <updated>2026-10-02T03:35:56.181784+00:00</updated>
    <content type="xhtml">
      <div xmlns="http://www.w3.org/1999/xhtml">
        <p>Traefik is an open source HTTP reverse proxy and load balancer. From 2.8.2 until 2.11.56 and 3.7.12, HTTP/3 entrypoints do not apply entryPoints..transport.respondingTimeouts.readTimeout because the timeout is enforced on a TCP connection and the HTTP/3 server has no corresponding QUIC stream deadline. An unauthenticated client can use a slow request body, trickling data indefinitely while holding a request and an upstream connection open and exhausting backends with bounded connection pools. This issue is fixed in 2.11.56 and 3.7.12.</p>
      </div>
    </content>
    <link href="https://vulnerability.circl.lu/vuln/fkie_cve-2026-88012"/>
  </entry>
  <entry>
    <id>https://vulnerability.circl.lu/vuln/ghsa-7ghq-v6jf-g56c</id>
    <title>GHSA-7ghq-v6jf-g56c — Traefik: respondingTimeouts.readTimeout is not applied to HTTP/3, leaving slow-body uploads unbounded</title>
    <updated>2026-10-02T03:35:56.181867+00:00</updated>
    <content type="xhtml">
      <div xmlns="http://www.w3.org/1999/xhtml"><p><strong>Affected:</strong> Go: github.com/traefik/traefik/v2, Go: github.com/traefik/traefik/v3</p>
<p>## Summary</p>
<p>There is a medium severity vulnerability in Traefik's HTTP/3 entry points: the `respondingTimeouts` settings were not applied to the HTTP/3 request path. `readTimeout` in particular is on by default at 60s and is documented as bounding the time to read the entire request including its body, but it is enforced as a deadline on the TCP connection, which cannot reach a QUIC stream, and Traefik's HTTP/3 server was constructed with no timeout of any kind. An unauthenticated client that trickles a request body therefore holds a request open for as long as it chooses, and with it one upstream connection per request, at negligible cost to itself. Backends with bounded connection pools are the practical pressure point.</p>
<p>The HTTP/3 path lost these timeouts in v2.8.2, when a quic-go API change removed the embedded `http.Server` that had carried them; every release from v2.8.2 onward is affected, and releases before v2.8.2 are not. Traefik v2.8.2 through v2.10.x and v3.0 through v3.6 are affected and are no longer maintained: they will not receive a patch on their own line, and the remedy for their users is to upgrade to v2.11.56 or v3.7.12.</p>
<p>## Patches</p>
<p>- https://github.com/traefik/traefik/releases/tag/v2.11.56
- https://github.com/traefik/traefik/releases/tag/v3.7.12</p>
<p>## For more information</p>
<p>If you have any questions or comments about this advisory, please [open an issue](https://github.com/traefik/traefik/issues).</p>
<p>&lt;details&gt;
&lt;summary&gt;Original Description&lt;/summary&gt;</p>
<p>## Su…</p></div>
    </content>
    <link href="https://vulnerability.circl.lu/vuln/ghsa-7ghq-v6jf-g56c"/>
  </entry>
</feed>
