The vulnerability exists in Netty's HTTP/3 codec due to an insecure default configuration for the maximum header size. The analysis of the patch between the last vulnerable version (4.2.14.Final) and the first patched version (4.2.15.Final) pinpointed the exact commit that fixes the issue.
The core of the vulnerability lies in the constructor of the io.netty.handler.codec.http3.Http3ConnectionHandler class. Before the patch, if a peer's HTTP/3 settings did not specify a HTTP3_SETTINGS_MAX_FIELD_SECTION_SIZE, the handler would default to a virtually unlimited size ((1L << 62) - 1). This allowed a malicious peer to send an extremely large header section, causing the application to allocate excessive memory and eventually crash with an OutOfMemoryError, resulting in a Denial of Service. The patch corrects this by replacing the unbounded default with a safe, hardcoded limit of 8192 bytes (Http3CodecUtils.DEFAULT_MAX_FIELD_SECTION_SIZE).
Additionally, the io.netty.handler.codec.http3.Http3Settings.defaultSettings() method was also modified. It previously configured a default header size limit of 16MB, which, while not unlimited, is still large enough to pose a resource exhaustion risk. The patch reduces this to the same safe 8KB limit.
Therefore, any application using Netty's HTTP/3 codec with default settings would have been vulnerable. During exploitation, the Http3ConnectionHandler constructor would be called, and its flawed logic for determining the header size limit would be executed, making it a key indicator in a runtime profile.