Open actionable advisories and recorded vendor fixes. This public package view has no inventory attached and cannot establish whether your deployment is affected. A vendor fix never resolves your finding; verify your installed version and the source guidance.
Open advisories
4 actionable advisories, newest first. Withdrawn advisories and news are excluded. Coverage is partial.
Netty's Http3FrameCodec buffers incoming data for HTTP/3 reserved frame types up to the specified payload length without any limits. The payload length is read directly from the wire and trusted without validation. A bad actor can send a reserved frame with a payload length of up to Integer.MAXVALUE, causing the server to buffer the data in memory. This leads to an OOM and a gradual Denial of Service due to memory exhaustion as multiple streams are opened. Details io.netty.handler.codec.http3.Http3FrameCodec#decodeFrame handles reserved frame types as follows: The payLoadLength is read directly from the wire and trusted implicitly. Since payLoadLength can be up to Integer.MAXVALUE and there is no maximum payload length enforcement for reserved frames, the decoder will accumulate bytes in memory until the wire-provided length is reached. This allows a bad actor to exhaust server memory by opening multiple QUIC streams and sending reserved frames with large payload lengths,…
Recommended action: Upgrade to 4.2.16.Final or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
A memory exhaustion vulnerability in the Netty HTTP/3 codec allows the creation of an infinite number of blocked streams, which can cause OOM error. Details The vulnerability exists in io.netty.handler.codec.http3.QpackDecoder#shouldWaitForDynamicTableUpdates: If a client sends a header referencing a table entry that the server hasn't received yet, the server must pause that stream and wait for the missing entry to arrive. To prevent attackers from exhausting resources by intentionally sending missing references, Netty limits the number of streams that can be blocked at the same time. However, the check is implemented as: If the server enables QPACK dynamic tables (by setting HTTP3SETTINGSQPACKMAXTABLECAPACITY 0) but does not explicitly configure HTTP3SETTINGSQPACKBLOCKEDSTREAMS, it defaults to 0. When maxBlockedStreams is 0, the condition evaluates to blockedStreamsCount == -1. Since blockedStreamsCount starts at 0 and only increments, it never equals -1. This bypasses the…
Recommended action: Upgrade to 4.2.15.Final or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
The default configuration of the Http3ConnectionHandler in the Netty HTTP/3 codec lacks an enforced maximum header size limit. When a peer does not explicitly specify HTTP3SETTINGSMAXFIELDSECTIONSIZE, the implementation defaults to an unbounded limit. This insecure default configuration allows a malicious client or server to send an enormous number of headers, leading to a memory exhaustion Denial of Service via an OutOfMemoryError. Details Netty securely limits header sizes for older protocols. In HTTP/1.1, Netty strictly enforces an 8192-byte limit out-of-the-box via HttpObjectDecoder. For HTTP/2, while RFC 9113 specifies that SETTINGSMAXHEADERLISTSIZE defaults to unlimited, Netty securely overrides this RFC default by enforcing an 8192-byte limit (Http2CodecUtil.DEFAULTHEADERLISTSIZE). However, this secure-by-default configuration is missing in the HTTP/3 implementation. While Netty provides a mechanism to configure the maximum header field section size via Http3Settings,…
Recommended action: Upgrade to 4.2.15.Final or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
When Netty decodes HTTP/3 headers, it sometimes runs new byte[length] using a length from the wire before checking that many bytes are really there. A small malicious header can claim a huge length (on the order of a gigabyte). Details When decoding header blocks, the non-Huffman branch of io.netty.handler.codec.http3.QpackDecoder#decodeHuffmanEncodedLiteral may execute new byte[length] for a string literal before verifying that length bytes are actually present in the compressed field section. The wire encoding allows a very large length to be expressed in few bytes. There is no check that length <= in.readableBytes() before new byte[length]. PoC The test below constructs a small HTTP/3 HEADERS frame whose QPACK section decodes to a ~1 GiB non-Huffman name length and is used to observe server-side failure; it illustrates how little wire data can target new byte[length]. Impact The server can slow down, stall, or crash under load when many crafted HTTP/3 HEADERS frames…
Recommended action: Upgrade to 4.2.13.Final or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.