Description

Netty's HTTP/3 codec (io.netty:netty-codec-http3) versions 4.2.0.Final through 4.2.17.Final contain a denial-of-service vulnerability in the QPACK prefixed-integer decoder (QpackUtil.decodePrefixedInteger), which does not bound the number of continuation bytes it will process. A remote, unauthenticated peer can open a QPACK unidirectional stream (type 0x02 encoder or 0x03 decoder) and send a first byte with all prefix bits set (e.g. 0xFF for a 7-bit prefix or 0x3F for a 5-bit prefix) followed by an endless run of 0x80 continuation bytes. The decoder returns -1 ('need more bytes'), so callers never consume the input, the ByteToMessageDecoder cumulator grows without bound, and each decode() invocation re-scans the whole accumulated buffer, yielding O(N^2) CPU cost. The result is unbounded per-connection heap growth (OutOfMemoryError) and event-loop CPU starvation, reachable in every configuration. Fixed in 4.2.18.Final.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "7.5",
  "pubDate": "2026-09-26T14:16:49.110Z",
  "pubdate": "2026-09-26T14:16:49.110Z",
  "executiveSummary": "A critical denial-of-service vulnerability exists in the io.netty:netty-codec-http3 library, specifically within the QPACK prefixed-integer decoding logic. The flaw stems from a failure to enforce constraints on continuation bytes during the decoding process of variable-length integers.\nA remote, unauthenticated attacker can exploit this by sending a malformed stream of bytes consisting of a high-prefix byte followed by an infinite sequence of 0x80 continuation bytes. This triggers excessive memory allocation and CPU cycles, eventually leading to heap exhaustion (OutOfMemoryError) and event-loop thread starvation.\nThe vulnerability affects Netty versions 4.2.0.Final through 4.2.17.Final. Successful exploitation results in the complete compromise of the affected service's availability. Since the vulnerability is reachable in all configurations without authentication, it poses a severe risk to any application utilizing the HTTP/3 codec.\nImmediate mitigation requires upgrading the library to version 4.2.18.Final or newer to implement proper bounds checking on QPACK integer decoding.",
  "technicalDetails": "The vulnerability is located in the QpackUtil.decodePrefixedInteger function within the io.netty:netty-codec-http3 package. This function is responsible for parsing QPACK-encoded integers, which utilize a prefix-based variable-length encoding scheme. The implementation fails to impose a hard limit on the number of continuation bytes processed during the decoding of these integers.\nThe attack vector involves a remote, unauthenticated peer initiating a QPACK unidirectional stream, specifically targeting type 0x02 (encoder stream) or 0x03 (decoder stream). By crafting a payload where the initial byte has all prefix bits set—such as 0xFF for a 7-bit prefix or 0x3F for a 5-bit prefix—the attacker signals the start of a multi-byte integer. Following this, the attacker appends an indefinite stream of 0x80 continuation bytes.\nBecause the decoder continuously returns -1, indicating that it 'needs more bytes' to complete the integer decoding, the Netty ByteToMessageDecoder cumulator does not consume the input. Consequently, the input buffer continues to grow indefinitely as the peer streams data. Furthermore, each invocation of the decode() method requires the engine to re-scan the entirety of the accumulated, unparsed buffer. This behavior creates an O(N^2) computational complexity relative to the number of bytes received.\nThe combination of unbounded heap accumulation (leading to OutOfMemoryError) and the massive CPU load caused by the repeated re-scanning of the buffer results in immediate event-loop starvation. Once the event-loop is starved, the affected Netty instance becomes unable to process legitimate requests or manage existing connections, effectively rendering the service unavailable.\nThis vulnerability is reachable by any remote actor capable of establishing a connection to the HTTP/3 endpoint, as it does not require authentication or elevated privileges. Because the parsing logic is fundamental to the protocol's operation, it is exposed in all standard configurations of the affected versions, making it highly exploitable for any public-facing HTTP/3 implementation using the vulnerable Netty versions."
}