CVE-2026-50560: Denial of Service in Netty HTTP/2 Codec via Max Header List Size Exception

The vulnerability exists in the netty-codec-http2 module, which is responsible for handling HTTP/2 frame parsing, state management, and stream multiplexing within the Netty framework.

In HTTP/2 deployments, Netty frequently serves as the edge protocol engine, receiving requests from untrusted external clients and routing them to internal backend services. This architecture creates an attack surface where an adversary can manipulate protocol-level settings to alter how Netty serializes and writes outbound data back to the client.

This specific security flaw is categorized under CWE-770 (Allocation of Resources Without Limits or Throttling). An attacker can exploit this weakness by establishing a multiplexed connection and instructing Netty to apply restrictive header list limits. The resulting system state leads to repeated processing failures, connection teardowns, and resource exhaustion.

Under the HTTP/2 specification (RFC 9113), the SETTINGS_MAX_HEADER_LIST_SIZE parameter allows a receiver to inform its peer of the maximum size of header list (in octets) it is prepared to accept. The peer is required to respect this limit when constructing response headers for the negotiated stream.

In vulnerable versions of Netty, a logic and sequencing error exists in how the outbound codec enforces this limit. When a client transmits a custom, highly restrictive SETTINGS_MAX_HEADER_LIST_SIZE value, Netty accepts the setting and updates its internal stream metadata. However, it does not validate or reject the request early based on this limit. Instead, the request is fully processed and forwarded to the upstream origin or application handler.

When the backend origin responds, Netty attempts to write the response headers back to the client. During the outbound serialization phase, the codec checks the outgoing header list size against the client's negotiated limit. Because the response headers exceed the artificially low limit set by the client, Netty's frame writer throws an unhandled local write exception. Rather than handling this mismatch gracefully, the exception triggers a stream reset or terminates the connection abruptly.

This behavior is structurally distinct from the HTTP/2 Rapid Reset vulnerability (CVE-2023-44487). In a Rapid Reset attack, the client explicitly transmits RST_STREAM frames immediately after sending headers to drive up CPU cycles. In CVE-2026-50560, the client never sends a reset frame. Instead, the server-side proxy performs the resource-intensive request processing and backend forwarding, only to fail internally when serializing the response, forcing the server itself to initiate the teardown.

The vulnerability stems from the processing flow in Netty's HTTP/2 outbound frame writer. In vulnerable versions, the frame writer lacks defensive validation during incoming request processing to ensure the backend response can actually be transmitted back to the client.

// Conceptual depiction of the vulnerable frame writing sequence
public final class Http2OutboundFrameWriter {
    
    public ChannelFuture writeHeaders(ChannelHandlerContext ctx, int streamId, 
                                      Http2Headers headers, int padding, 
                                      boolean endStream, ChannelPromise promise) {
        
        // Get the client's configured max header list size
        long maxHeaderListSize = connection.local().maxHeaderListSize();
        long headerSize = calculateHeaderSize(headers);
        
        if (headerSize > maxHeaderListSize) {
            // Vulnerable behavior: Throws an exception deep in the outbound pipeline
            // instead of dropping or refusing the request at ingestion time
            Http2Exception ex = connectionError(PROTOCOL_ERROR, 
                "Header list size %d exceeds maximum allowed %d", headerSize, maxHeaderListSize);
            promise.setFailure(ex);
            throw ex;
        }
        
        return serializeAndSend(ctx, streamId, headers, padding, endStream, promise);
    }
}

In the patched versions, Netty improves the handling of these limits to prevent write-phase exceptions from terminating the pipeline. Additionally, proper validation and early-rejection mechanics are introduced to ensure that clients cannot force downstream resource consumption for requests that cannot be successfully answered.

To exploit this vulnerability, an attacker must establish an HTTP/2 connection with a target Netty server. The attack does not require authentication or specific network placement beyond the ability to reach the listening port.

First, the attacker transmits a SETTINGS frame specifying an extremely small SETTINGS_MAX_HEADER_LIST_SIZE (for example, 16 bytes). This frame forces the Netty server to apply this limit to all subsequent outbound responses on that connection.

Second, the attacker pipeline-sends standard requests over multiplexed streams. Because the requests themselves do not violate any ingress limits, Netty accepts them, instantiates internal stream buffers, and forwards the requests to the backend application server.

Third, as the backend application processes these requests, it consumes database connections, CPU cycles, and memory. When the backend returns standard responses (which naturally exceed the 16-byte header limit), Netty's write exception occurs. Netty discards the state and tears down the stream. The attacker can repeat this cycle continuously, causing resource exhaustion on backend servers without ever receiving or processing responses on the client side.

This technique has significant evasion potential. Security monitoring systems configured to flag high rates of client-initiated RST_STREAM frames will not detect this activity, as all stream resets are initiated internally by the server due to serialization failures.

The primary impact of CVE-2026-50560 is application-level Denial of Service (DoS). By forcing Netty to process requests that can never be completed, an attacker can saturate backend worker pools, exhaust memory allocations, and consume available network sockets.

Furthermore, because Netty's event-loop threads (EventLoopGroup) handle multiple multiplexed connections simultaneously, repeated local exceptions on these threads can lead to thread starvation. This affects not only the attacker's connection but also degrades or completely blocks legitimate traffic sharing the same EventLoop instances.

No confidentiality or integrity loss is associated with this vulnerability. However, the availability impact is rated as Low to Medium on standard metrics due to the temporary nature of the resource exhaustion, which can typically be recovered by terminating the affected Netty process or enforcing connection timeouts.

The most effective remediation is upgrading Netty dependencies to patched versions. For deployments on the 4.1.x branch, upgrade to 4.1.135.Final or later. For deployments on the 4.2.x branch, upgrade to 4.2.15.Final or later.

If upgrading is not immediately feasible, operators should implement temporary controls at the network perimeter. Configure fronting load balancers, such as NGINX, Envoy, or Cloudflare, to enforce minimum allowable values for SETTINGS_MAX_HEADER_LIST_SIZE and reject connections that negotiate values below standard operating thresholds (typically 4096 or 8192 bytes).

Additionally, implement strict connection rate-limiting and stream concurrency limits to mitigate the impact of pipelined multiplexing attacks.