The Never-Ending Goodbye: Crashing WebTransport with Unbounded Errors

WebTransport is the new hotness in the protocol world. Built on top of HTTP/3 and QUIC, it promises to do everything WebSockets did, but faster, with less head-of-line blocking, and with that fresh "modern protocol" smell. It uses the concept of "Capsules" to handle signaling—think of them as control packets flowing alongside your data streams.

But here is the thing about modern protocols: the specifications are usually tighter than a drum, but the implementations? That is where the chaos lives. The IETF draft for WebTransport is very specific about safety limits. It explicitly states that when you close a session, the error message attached to that closure "SHALL NOT" exceed 1024 bytes.

Enter webtransport-go, the Go implementation maintained by the brilliant folks behind quic-go. In their rush to support this complex protocol, they made a classic mistake. They trusted the sender. They assumed that if the spec says "don't send more than 1KB," surely nobody would send more than 1KB, right? Spoiler: I am definitely going to send more than 1KB.

The vulnerability lives in session.go, specifically within the parseNextCapsule function. This function creates a loop that listens for incoming capsules, parses their type, and handles them accordingly. One such type is WT_CLOSE_SESSION (0x2843), which is used to cleanly terminate a connection.

When a session is closed, the closer can include an error code (4 bytes) and an error message (variable length string). To read this message, the developers reached for the most dangerous weapon in the Go standard library: io.ReadAll.

io.ReadAll is the programming equivalent of an all-you-can-eat buffet where the restaurant is legally required to keep cooking until you stop eating. It reads from the source until it hits EOF. In the context of a QUIC stream, the EOF is determined by the length field in the capsule header. If I, the attacker, send a capsule header claiming my error message is 4 Gigabytes long, io.ReadAll says "Challenge accepted" and begins allocating slices to fit that data.

There was no check. No if length > 1024. Just a blind read into the heap until the garbage collector panics and the kernel kills the process.

Let's look at the crime scene. Below is the code from version 0.9.0. Notice the complete lack of defensive programming around the message retrieval.

// Vulnerable Code in v0.9.0/session.go
 
case closeWebtransportSessionCapsuleType:
    b := make([]byte, 4)
    // Read the 4-byte error code
    if _, err := io.ReadFull(r, b); err != nil {
        return err
    }
    appErrCode := binary.BigEndian.Uint32(b)
 
    // THE BUG: Reads until EOF (defined by capsule length)
    appErrMsg, err := io.ReadAll(r) 
    if err != nil {
        return err
    }

The fix is almost frustratingly simple. It involves wrapping the reader in an io.LimitReader, which acts as a bouncer, cutting off the stream once the limit is reached.

// Patched Code in v0.10.0/session.go
 
const maxCloseCapsuleErrorMsgLen = 1024
 
// ... inside the case statement ...
 
// THE FIX: Enforce the 1024 byte limit strictly
appErrMsg, err := io.ReadAll(io.LimitReader(r, maxCloseCapsuleErrorMsgLen))
if err != nil {
    return err
}

By adding that LimitReader, the server now reads at most 1024 bytes. If the attacker sends 4GB, the server reads the first kilobyte, processes the error, and ignores the rest (or resets the stream), saving the heap from exhaustion.

Exploiting this is trivial and requires no authentication. We just need to establish a valid WebTransport session and then lie about how much we have to say before we leave.

Here is the attack chain:

1. Handshake: Perform a standard HTTP/3 handshake and upgrade to WebTransport.
2. Frame Injection: Construct a WT_CLOSE_SESSION capsule. In the capsule header, we encode a VarInt length field of 0xFFFFFFFF (approx 4GB) or higher.
3. The Flooding: Immediately after the header and the 4-byte error code, we start streaming 'A's. We don't even need to send the full 4GB fast; we just need to send it faster than the server can GC, or simply hold the connection open while the server allocates the buffer capacity.

Because io.ReadAll grows its buffer exponentially to accommodate incoming data, the server's memory usage will spike. Do this across 10 or 20 concurrent connections, and you will OOM virtually any standard containerized deployment.

While the CVSS score is a modest 5.3 (Medium), don't let that fool you. In a microservices environment, this is a nuclear option for a script kiddie. The asymmetry is the killer here: the attacker needs very little bandwidth to trigger massive memory allocations on the server.

If your Go application sits directly on the internet (which, given it is HTTP/3 / UDP, it likely does), it is vulnerable. Standard HTTP WAFs often struggle to inspect deep inside QUIC datagrams or encrypted HTTP/3 frames without full decryption and re-encryption proxies, which are computationally expensive. This means the bad packet is likely hitting your application logic directly.

This isn't just about crashing a single pod. If you are running an autoscaling group based on memory usage, an attacker could theoretically trick your orchestrator into spinning up max instances before crashing them all, hitting your wallet before hitting your availability.

The mitigation is straightforward: Update webtransport-go to v0.10.0. There are no clever configuration workarounds here because the vulnerability is inside the compiled logic of the library's frame parser.

If you are a developer using this library, check your go.mod file today.

> [!NOTE] > For Security Researchers: If you are looking for similar bugs, search for io.ReadAll in any networking library processing length-prefixed fields. It is the "SQL Injection" of memory corruption in Go.