Description

webtransport-go is an implementation of the WebTransport protocol. Prior to 0.11.1, Session.parseNextCapsule() in session.go skips an unknown WebTransport capsule on the HTTP/3 request stream by calling io.ReadAll on the capsule reader, retaining the complete declared capsule body in memory. A malicious peer can send a large unknown capsule and cause a client or server to allocate memory for the full payload; QUIC flow control does not bound the total retained allocation because reading advances the flow-control window while the received bytes remain in memory. The resulting memory and resource exhaustion can disrupt or crash the affected process. This issue is fixed in version 0.11.1.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "5.3",
  "pubDate": "2026-09-14T17:17:49.097Z",
  "pubdate": "2026-09-14T17:17:49.097Z",
  "executiveSummary": "The vulnerability identified in webtransport-go prior to version 0.11.1 is an improper resource management flaw leading to potential memory exhaustion. The issue resides within the Session.parseNextCapsule() function in session.go, which incorrectly handles unknown WebTransport capsules received over HTTP/3 streams.\nBy design, the affected code utilizes io.ReadAll to ingest the entire body of an unknown capsule into system memory. Because this ingestion process advances the QUIC flow-control window while simultaneously buffering the complete payload, the implementation fails to apply back-pressure or capacity limits on incoming data streams.\nAn unauthenticated, remote attacker can exploit this behavior by transmitting a maliciously crafted, oversized capsule. This forces the target process (client or server) to perform massive memory allocations, leading to resource depletion, service degradation, or an application crash due to out-of-memory (OOM) conditions. This vulnerability poses a significant denial-of-service (DoS) risk to any deployment utilizing webtransport-go, as it allows a peer to bypass typical flow-control constraints to induce process instability.",
  "technicalDetails": "The root cause of this vulnerability lies in the implementation of the capsule parsing logic within Session.parseNextCapsule() in session.go. When the parser encounters an unknown WebTransport capsule type, it incorrectly assumes that it should exhaust the entire capsule payload from the underlying reader to clear the stream.\nThe vulnerability is triggered because the implementation calls io.ReadAll on the provided capsule reader. In the context of HTTP/3 and QUIC, io.ReadAll attempts to read until EOF, buffering the entire byte stream into an allocated buffer in the application's heap memory. Crucially, the underlying QUIC transport layer interprets the consumption of these bytes as a signal to advance the flow-control window, signaling to the sender that it may transmit additional data. However, since the application holds the entirety of the payload in memory, it fails to enforce any reasonable size limits on the incoming capsule.\nAn attacker can exploit this by initiating a WebTransport session and sending a capsule with a declared size that exceeds available heap resources. The attack flow is as follows: 1) The attacker sends an unknown capsule type with a very large payload length; 2) The server/client receives the initial frames of the capsule; 3) The Session.parseNextCapsule() function invokes io.ReadAll; 4) The application continuously reads the incoming data, which satisfies the QUIC stream flow control and encourages the transport layer to keep accepting data; 5) The application allocates memory linearly proportional to the size of the malicious payload; 6) Once the allocation exceeds available system memory, the process experiences an OOM crash or extreme performance degradation, effectively causing a denial of service.\nThe affected component is the capsule parser in webtransport-go, specifically versions prior to 0.11.1. No authentication or elevated privileges are required to initiate this attack, as it occurs during the standard protocol handshake and stream processing phase. This vulnerability exposes network-facing services directly to memory-based DoS attacks, as the QUIC stack acts as an enabler for the memory exhaustion rather than a control mechanism."
}