Skip to content

← Public intelligence

Go package

github.com/quic-go/webtransport-go

Open actionable advisories and recorded vendor fixes. This public package view has no inventory attached and cannot establish whether your deployment is affected. A vendor fix never resolves your finding; verify your installed version and the source guidance.

Open advisories

4 actionable advisories, newest first. Withdrawn advisories and news are excluded. Coverage is partial.

  1. Medium, CVSS 5.3GoAmendedPublished

    webtransport-go: Memory Exhaustion Attack due to Buffering of Unknown Capsules

    CVE-2026-57497 · GHSA-g35j-m5xg-vh3q

    Affected
    • Go github.com/quic-go/webtransport-go <= 0.11.0
    Fixed in
    0.11.1· Vendor fix available
    Issue
    An attacker can cause excessive memory allocation in webtransport-go by sending an unknown WebTransport capsule with a large payload. The implementation skips unknown capsules by reading the entire capsule body into memory, instead of draining it without retaining the data. This can lead to memory exhaustion. Impact A misbehaving or malicious peer can cause a denial-of-service (DoS) attack against webtransport-go clients or servers by triggering excessive memory allocation, potentially leading to crashes or resource exhaustion. Details WebTransport sessions use capsules on the HTTP/3 request stream. Unknown capsule types are ignored, but the capsule body still needs to be consumed before the next capsule can be parsed. webtransport-go used io.ReadAll when skipping unknown capsules. Since the capsule reader is only limited by the capsule's declared length, a peer could send a large unknown capsule and cause the receiver to allocate memory for the full capsule body. QUIC flow…

    Recommended action: Upgrade to 0.11.1 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.

    Sources:osv.dev (1)github.com (2)Source checked Evidence →
  2. Medium, CVSS 5.3GoPublished

    webtransport-go: Memory Exhaustion Attack due to Missing Cleanup of Streams Map

    CVE-2026-21438 · GHSA-2f2x-8mwp-p2gc

    Affected
    • Go github.com/quic-go/webtransport-go <= 0.9.0
    Fixed in
    0.10.0· Vendor fix available
    Issue
    An attacker can cause unbounded memory consumption repeatedly creating and closing many WebTransport streams. Closed streams were not removed from an internal session map, preventing garbage collection of their resources. Details webtransport-go maintains an internal map tracking WebTransport streams (both unidirectional and bidirectional) belonging to a session. In affected versions, entries for closed streams were not removed from this map, causing the map to grow indefinitely as streams were created and closed. A malicious peer can exploit this by opening large numbers of streams and closing them, leading to steady memory growth proportional to the number of closed streams. The Fix webtransport-go now removes closed streams from the internal map upon closure. This allows the associated resources to be garbage collected, bounding memory usage to active streams only.

    Recommended action: Upgrade to 0.10.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.

    Sources:github.comSource checked Evidence →
  3. Medium, CVSS 5.3GoPublished

    webtransport-go: CloseWithError can block indefinitely

    CVE-2026-21435 · GHSA-px4r-g4p3-hhqv

    Affected
    • Go github.com/quic-go/webtransport-go <= 0.9.0
    Fixed in
    0.10.0· Vendor fix available
    Issue
    An attacker can cause a denial of service in webtransport-go by preventing or indefinitely delaying WebTransport session closure. A malicious peer can withhold QUIC flow control credit on the CONNECT stream, blocking transmission of the WTCLOSESESSION capsule and causing the close operation to hang. Details WebTransport over HTTP/3 signals session termination by sending a WTCLOSESESSION capsule on the CONNECT stream. The capsule is only needed to transmit a reason phrase and an error code to the peer. After the capsule is sent, the CONNECT stream is closed. In affected versions, the closure procedure blocked indefinitely while waiting for sufficient QUIC flow control credit from the peer. A malicious peer can withhold this credit, preventing the capsule from being sent. The Fix webtransport-go now attempts to send the WTCLOSESESSION capsule with a short deadline. If the capsule cannot be sent within this deadline, the CONNECT stream is reset instead. This closes the…

    Recommended action: Upgrade to 0.10.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.

    Sources:github.comSource checked Evidence →
  4. Medium, CVSS 5.3GoPublished

    webtransport-go: Memory Exhaustion Attack due to Missing Length Check in WT_CLOSE_SESSION Capsule

    CVE-2026-21434 · GHSA-g6x7-jq8p-6q9q

    Affected
    • Go github.com/quic-go/webtransport-go >= 0.3.0, <= 0.9.0
    Fixed in
    0.10.0· Vendor fix available
    Issue
    An attacker can cause excessive memory consumption in webtransport-go's session implementation by sending a WTCLOSESESSION capsule containing an excessively large Application Error Message. The implementation does not enforce the draft-mandated limit of 1024 bytes on this field, allowing a peer to send an arbitrarily large message payload that is fully read and stored in memory. This allows an attacker to consume an arbitrary amount of memory. The attacker must transmit the full payload to achieve the memory consumption, but the lack of any upper bound makes large-scale attacks feasible given sufficient bandwidth. Details WebTransport over HTTP/3, as defined in draft-ietf-webtrans-http3, uses the WTCLOSESESSION capsule to signal session termination with an optional detailed error. The draft specifies that the length of the Application Error Message in this capsule MUST NOT exceed 1024 bytes. In affected versions of webtransport-go, the parser does not enforce this 1024-byte…

    Recommended action: Upgrade to 0.10.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.

    Sources:github.comSource checked Evidence →