GHSA-c2rx-5r8w-8xr2
HIGHGHSA-c2rx-5r8w-8xr2 is a high-severity (CVSS 7.5) vulnerability in io.netty:netty-codec-http3. O3 Security confirms whether GHSA-c2rx-5r8w-8xr2 is actually reachable in your code before you act, and blocks exploitation at runtime until you patch.
Netty has a Vulnerable Default Configuration Which Leads to Denial of Service via Unbounded HTTP/3 Header Size
Real-World Exposure
io.netty:netty-codec-http3Real-time download stats are indexed for npm and PyPI packages. This vulnerability affects Maven packages — download data is not available via public APIs for these ecosystems.
Description
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.
Affected Packages
| Ecosystem | Package | Vulnerable range | Fix |
|---|---|---|---|
| ☕Maven | io.netty:netty-codec-http3 | ≥ 4.2.0.Final&&< 4.2.15.Final | 4.2.15.Final |
Detection & mitigation playbook
Open-source dependencyDetect
Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for io.netty:netty-codec-http3. O3's reachability analysis confirms whether the vulnerable code path is actually invoked in your application, so you act on real exposure instead of every transitive match.
Fix
Update io.netty:netty-codec-http3 to 4.2.15.Final or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms GHSA-c2rx-5r8w-8xr2 is resolved across your whole dependency graph.
Workarounds
If you can't upgrade right away: gate or disable the affected feature, validate untrusted input at the boundary, and avoid passing attacker-controlled data into the vulnerable path. O3's runtime protection blocks exploitation in production as an interim safeguard until the upgrade lands.
How O3 protects you
O3 pinpoints whether GHSA-c2rx-5r8w-8xr2 is reachable in your code and exactly where to fix it, then blocks exploitation in production at runtime until the patched version is deployed.
Tailored to GHSA-c2rx-5r8w-8xr2. Runtime protection reduces exposure until a permanent patch is applied and verified — it complements patching, it doesn't replace it.
Frequently Asked Questions
Is GHSA-c2rx-5r8w-8xr2 in your dependencies?
O3 detects GHSA-c2rx-5r8w-8xr2 across Maven dependencies and uses function-level reachability to confirm whether the vulnerable code path is actually reachable — not just present. No false positives.