Summary
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 HTTP3_SETTINGS_MAX_FIELD_SECTION_SIZE, 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 SETTINGS_MAX_HEADER_LIST_SIZE defaults to unlimited, Netty securely overrides this RFC default by enforcing an 8192-byte limit (Http2CodecUtil.DEFAULT_HEADER_LIST_SIZE).
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, its out-of-the-box behaviour strictly follows RFC 9114's unlimited default.
Because many developers rely on the framework's default configurations and basic constructors, their applications are unknowingly left vulnerable. This nearly infinite default limit is passed into Http3FrameCodec#newFactory and stored as maxHeaderListSize inside Http3FrameCodec.
A bad actor can continuously send HTTP/3 headers within a connection, exploiting the insecure default configuration to consume server memory unconditionally until the application crashes with an OutOfMemoryError.
Impact
Denial of Service via memory exhaustion. All applications using Netty's HTTP/3 codec with its default configuration are impacted.
References
violetagg Reporter
Summary
The default configuration of the
Http3ConnectionHandlerin the Netty HTTP/3 codec lacks an enforced maximum header size limit. When a peer does not explicitly specifyHTTP3_SETTINGS_MAX_FIELD_SECTION_SIZE, 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 anOutOfMemoryError.Details
Netty securely limits header sizes for older protocols. In HTTP/1.1, Netty strictly enforces an
8192-byte limit out-of-the-box viaHttpObjectDecoder. For HTTP/2, while RFC 9113 specifies thatSETTINGS_MAX_HEADER_LIST_SIZEdefaults tounlimited, Netty securely overrides this RFC default by enforcing an8192-byte limit (Http2CodecUtil.DEFAULT_HEADER_LIST_SIZE).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, its out-of-the-box behaviour strictly follows RFC 9114's unlimited default.Because many developers rely on the framework's default configurations and basic constructors, their applications are unknowingly left vulnerable. This nearly infinite default limit is passed into
Http3FrameCodec#newFactoryand stored asmaxHeaderListSizeinsideHttp3FrameCodec.A bad actor can continuously send HTTP/3 headers within a connection, exploiting the insecure default configuration to consume server memory unconditionally until the application crashes with an
OutOfMemoryError.Impact
Denial of Service via memory exhaustion. All applications using Netty's HTTP/3 codec with its default configuration are impacted.
References