EUVD-2026-36386
GHSA-c2rx-5r8w-8xr2
Severity by source
AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
Primary rating from Vendor (https://github.com/netty/netty) · only source for this CVE.
CVSS VectorVendor: https://github.com/netty/netty
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
Lifecycle Timeline
2DescriptionCVE.org
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.
AnalysisAI
Remote denial-of-service in Netty's HTTP/3 codec (io.netty:netty-codec-http3, versions 4.2.0.Final through 4.2.14.Final) allows an unauthenticated attacker to exhaust server memory by streaming an unbounded number of HTTP/3 headers over a single connection until the JVM throws an OutOfMemoryError. The flaw stems from an insecure default in Http3ConnectionHandler that follows RFC 9114's unlimited HTTP3_SETTINGS_MAX_FIELD_SECTION_SIZE rather than mirroring the 8192-byte cap Netty applies to HTTP/1.1 and HTTP/2. No public exploit identified at time of analysis and the issue is not on the CISA KEV list, but the vendor advisory (GHSA-c2rx-5r8w-8xr2) rates the issue high severity and a fix is shipped in 4.2.15.Final.
Technical ContextAI
Netty is a widely deployed asynchronous network framework used as the transport layer for many JVM-based servers, gateways, and microservice frameworks (gRPC-Java, Spring WebFlux/Reactor Netty, Vert.x, Apache Cassandra, Elasticsearch, etc.). The affected component, netty-codec-http3, implements RFC 9114 HTTP/3 over QUIC. The root cause is CWE-400 (Uncontrolled Resource Consumption): Http3FrameCodec stores a maxHeaderListSize that, when the peer does not send HTTP3_SETTINGS_MAX_FIELD_SECTION_SIZE, defaults to the RFC-mandated unbounded value rather than Netty's protective 8192-byte cap used in Http2CodecUtil.DEFAULT_HEADER_LIST_SIZE and HttpObjectDecoder. Because QPACK-decoded header field sections are accumulated in memory before being delivered to the application, an attacker can keep feeding header frames into a single QUIC stream until the heap is exhausted. The CPE pkg:maven/io.netty:netty-codec-http3 precisely scopes the impact to the HTTP/3 module.
RemediationAI
Vendor-released patch: upgrade io.netty:netty-codec-http3 to 4.2.15.Final or later (release notes: https://github.com/netty/netty/releases/tag/netty-4.2.15.Final), which is the primary and recommended fix; review the full security advisory at https://github.com/netty/netty/security/advisories/GHSA-c2rx-5r8w-8xr2 for full context. If immediate upgrade is not possible, the documented workaround is to explicitly construct Http3Settings with a sensible HTTP3_SETTINGS_MAX_FIELD_SECTION_SIZE (for parity with Netty's other codecs, 8192 bytes is a reasonable starting value) and pass it into Http3ConnectionHandler so the unbounded RFC 9114 default is overridden - the trade-off is that legitimate clients sending unusually large header sections will be rejected, so tune the value to match real application traffic. As a network-layer compensating control, terminate HTTP/3 at an upstream reverse proxy or load balancer that enforces its own header-size limits, or temporarily disable HTTP/3/QUIC listeners (typically UDP/443) and force clients back to HTTP/2 over TLS until the library is upgraded.
Same weakness CWE-400 – Uncontrolled Resource Consumption
View allSame technique Denial Of Service
View allShare
External POC / Exploit Code
Leaving vuln.today