CVE-2026-48748: Netty HTTP/3 QPACK Blocked Streams Memory Exhaustion

The HTTP/3 protocol uses QPACK (RFC 9204) for efficient compression of HTTP headers over QUIC. QPACK introduces a dynamic table containing header fields that are added incrementally during the lifetime of a connection. This mechanism necessitates handling out-of-order header delivery. When an HTTP/3 client sends a header referencing a dynamic table entry that the server has not yet parsed, the server must pause (block) processing of that stream until the prerequisite instructions arrive.

To prevent resource exhaustion attacks, servers must enforce strict upper limits on the number of concurrent blocked streams. In Netty's HTTP/3 codec (io.netty:netty-codec-http3), this limit is tracked using the maxBlockedStreams setting. A flaw in how Netty validates this limit combined with a failure to release tracking state leads to heap exhaustion.

This analysis details CVE-2026-48748, a high-severity resource exhaustion vulnerability affecting Netty HTTP/3 implementations. Unauthenticated remote attackers can exploit this vulnerability to trigger JVM heap memory exhaustion, resulting in a persistent Denial of Service.

The vulnerability resides within the QPACK decoding engine of Netty, specifically inside the class io.netty.handler.codec.http3.QpackDecoder and its helper method shouldWaitForDynamicTableUpdates. The primary defect is a logical flaw in the boundary check used to enforce the concurrent blocked stream limit.

When a server enables QPACK dynamic tables (by defining HTTP3_SETTINGS_QPACK_MAX_TABLE_CAPACITY greater than zero) but relies on default parameters, the setting HTTP3_SETTINGS_QPACK_BLOCKED_STREAMS remains unconfigured. Under these conditions, the property maxBlockedStreams defaults to a value of 0. The implementation checks the current count of blocked streams using the expression if (blockedStreamsCount == maxBlockedStreams - 1). When maxBlockedStreams is 0, this condition evaluates to if (blockedStreamsCount == -1). Because blockedStreamsCount starts at zero and only increments upon blocking new streams, the check can never evaluate to true. Consequently, the limit is bypassed entirely.

Furthermore, the QpackDecoder contains a secondary memory leak defect. When a stream is successfully unblocked or closed, the decoder does not remove the stream's metadata from its internal blockedStreams tracking data structure, nor does it decrement the blockedStreamsCount counter. This lack of cleanup ensures that memory allocated for the ReadResumptionListener and associated stream context persists for the duration of the QUIC connection, creating a severe memory leak.

To understand the vulnerabilities, analyze the following representation of the vulnerable QpackDecoder implementation:

// Vulnerable Implementation
public boolean shouldWaitForDynamicTableUpdates(long streamId, long requiredIndex) {
    // ... other checks ...
    
    // Flaw 1: Integer subtraction vulnerability leading to bypass
    // When maxBlockedStreams is 0, (maxBlockedStreams - 1) equals -1
    if (blockedStreamsCount == maxBlockedStreams - 1) {
        throw new Http3Exception(Http3ErrorCode.H3_QPACK_DECOMPRESSION_FAILED, "Limit exceeded");
    }
    
    // Flaw 2: Allocation without release
    ReadResumptionListener listener = new ReadResumptionListener(streamId);
    blockedStreams.put(streamId, listener);
    blockedStreamsCount++; // Incremented but never decremented
    
    return true;
}

The fix implemented in Netty version 4.2.15.Final addresses both structural flaws. It corrects the mathematical validation and ensures appropriate resource cleanup when a stream is processed or closed. The patched code implements the validation logic and cleanup actions:

// Patched Implementation
public boolean shouldWaitForDynamicTableUpdates(long streamId, long requiredIndex) {
    // ... other checks ...
    
    // Fix 1: Robust boundary check prevents bypass when limit is 0 or low
    if (blockedStreamsCount >= maxBlockedStreams) {
        throw new Http3Exception(Http3ErrorCode.H3_QPACK_DECOMPRESSION_FAILED, "Limit exceeded");
    }
    
    ReadResumptionListener listener = new ReadResumptionListener(streamId);
    blockedStreams.put(streamId, listener);
    blockedStreamsCount++;
    
    return true;
}
 
// Fix 2: Proper resource deallocation
public void onStreamClosed(long streamId) {
    ReadResumptionListener removed = blockedStreams.remove(streamId);
    if (removed != null) {
        blockedStreamsCount--;
    }
}

The replacement of the exact-match condition (== maxBlockedStreams - 1) with a relational inequality check (>= maxBlockedStreams) prevents bypass regardless of the configuration value. The addition of the tracking cleanup in onStreamClosed or equivalent lifecycle handlers prevents memory from growing indefinitely.

An attacker can exploit this vulnerability with standard HTTP/3 traffic. The exploit requires no authentication or specific system state, only the ability to establish an HTTP/3 connection with the target server.

The attacker initiates standard HTTP/3 handshakes and configures the connection to negotiate QPACK support. The attacker then continuously issues streams containing HTTP headers that deliberately reference dynamic table entries that have not yet been defined. The Netty decoder blocks each stream and registers a ReadResumptionListener in heap memory.

Because the boundary condition is broken and the cleanup is non-existent, the attacker can pile up hundreds of thousands of blocked streams on a single QUIC connection. This monotonically increases heap allocations until the JVM runs out of memory, leading to an abrupt application crash.

The impact of CVE-2026-48748 is classified as a high-severity Denial of Service (DoS). The vulnerability allows a single unauthenticated attacker to completely exhaust system memory resources on the hosting platform, resulting in an OutOfMemoryError (OOM) inside the Java Virtual Machine.

Because Netty is widely used as an underlying networking engine for various high-throughput proxy servers, API gateways, and microservice frameworks, a crash of the Netty runtime halts all dependent network services. This creates a complete service outage.

No data confidentiality or integrity is directly compromised, as the exploit does not permit unauthorized read or write access to application memory. The CVSS base score is determined to be 7.5.

The primary remediation is upgrading io.netty:netty-codec-http3 to version 4.2.15.Final or later. This version contains the complete correction for both the limit-validation expression and the memory-cleanup omissions.

If immediate patching is not possible, a temporary workaround is available. Administrators must explicitly configure the setting HTTP3_SETTINGS_QPACK_BLOCKED_STREAMS to a non-zero integer, such as 100. Doing so prevents the maxBlockedStreams variable from defaulting to 0, ensuring that the vulnerable condition blockedStreamsCount == maxBlockedStreams - 1 triggers once the threshold is approached.

Note that because of the memory tracking leak, once the limit is reached, the connection will permanently refuse to block further streams, which may cause degradation of long-lived connections. However, this protects the server from infinite heap growth and subsequent JVM crashes. This workaround should be treated as a short-term risk reduction strategy until patches are applied.