Description

Netty's HTTP/3 codec (io.netty:netty-codec-http3) versions 4.2.0.Final through 4.2.17.Final contain an uncontrolled resource consumption vulnerability in the QPACK encoder-stream instruction decoder (QpackEncoderHandler, installed on the peer-initiated unidirectional QPACK encoder stream, type 0x02). The handler accepts an attacker-declared string-literal length of up to Integer.MAX_VALUE (~2 GiB) for the Name Length and Value Length fields of the "Insert With Literal Name" instruction (RFC 9204 §4.3.3), with no per-instruction or per-literal length cap and no cumulation-size limit; the existing HTTP/3 limits (maxHeaderListSize, maxUnknownFramePayloadLength, DEFAULT_MAX_FIELD_SECTION_SIZE) are not applied to this handler. A remote, unauthenticated peer with an established HTTP/3 connection to a default Netty HTTP/3 server can declare a very large literal length and then trickle fewer bytes than declared, causing the ByteToMessageDecoder MERGE cumulator to retain and grow the per-connection buffer, and ultimately triggering a large byte-array allocation. This leads to unbounded per-connection heap growth and OutOfMemoryError, resulting in denial of service. Fixed in 4.2.18.Final.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "7.5",
  "pubDate": "2026-09-26T14:16:49.257Z",
  "pubdate": "2026-09-26T14:16:49.257Z",
  "executiveSummary": "A critical uncontrolled resource consumption vulnerability exists in io.netty:netty-codec-http3, affecting versions 4.2.0.Final through 4.2.17.Final. The vulnerability resides in the QPACK encoder-stream instruction decoder, specifically within the QpackEncoderHandler.\nThe flaw allows a remote, unauthenticated attacker to trigger an OutOfMemoryError (OOM) on a default Netty HTTP/3 server by sending specially crafted 'Insert With Literal Name' instructions. By specifying arbitrary string-literal lengths up to Integer.MAX_VALUE without validation or cumulative size limits, an attacker can force the server to allocate excessive heap memory.\nThis vulnerability leads to a denial-of-service (DoS) condition by exhausting the heap through per-connection buffer growth. The primary risk involves the exhaustion of available system memory, causing the application to crash or become unresponsive. Exploitation does not require prior authentication, as the attacker only needs to establish an HTTP/3 connection to the server. Remediation is achieved by updating the Netty dependency to version 4.2.18.Final, which implements the necessary length constraints.",
  "technicalDetails": "The vulnerability originates in the QpackEncoderHandler, which processes peer-initiated unidirectional QPACK encoder streams (type 0x02) as defined in RFC 9204. The component responsible for decoding 'Insert With Literal Name' instructions (RFC 9204 §4.3.3) fails to enforce any upper bounds on the Name Length and Value Length fields, which are parsed as integers up to 2 GiB (Integer.MAX_VALUE).\nCrucially, the existing HTTP/3 protection mechanisms, such as maxHeaderListSize, maxUnknownFramePayloadLength, and DEFAULT_MAX_FIELD_SECTION_SIZE, are not applied to this specific handler. This lack of validation creates a direct vector for heap-based resource exhaustion.\nThe attack flow proceeds as follows: First, an unauthenticated attacker establishes an HTTP/3 connection with a vulnerable Netty server. The attacker then transmits an 'Insert With Literal Name' instruction over the QPACK encoder stream. Within this instruction, the attacker declares an extremely large literal length (e.g., nearing Integer.MAX_VALUE).\nBecause the decoder expects a sequence of bytes matching the declared length, the ByteToMessageDecoder MERGE cumulator is invoked. If the attacker trickles fewer bytes than the declared length, the system is forced to retain the received data in an internal buffer. As the decoder waits for the remaining bytes to fulfill the declared length, the buffer grows per connection.\nThe combination of the lack of per-instruction length caps and the absence of cumulative size limits allows an attacker to sustain multiple malicious connections, each forcing the ByteToMessageDecoder to perform large byte-array allocations. This behavior leads to uncontrolled heap growth. Once the cumulative memory consumption exceeds the allocated heap, the Java Virtual Machine (JVM) triggers an OutOfMemoryError, resulting in a denial-of-service condition for the entire process.\nThe vulnerability affects all Netty HTTP/3 implementations within the 4.2.0.Final through 4.2.17.Final version range. The attack is network-exploitable, requiring only the ability to initiate an HTTP/3 handshake with the target server, and does not necessitate any administrative or user-level privileges."
}