CVE-2026-42582: Netty Buffer Overflow Vulnerability

CVE-2026-42582 Overview

CVE-2026-42582 affects Netty, an asynchronous event-driven network application framework widely deployed in Java-based servers and clients. The vulnerability resides in the HTTP/3 QPACK decoder and allows a remote attacker to trigger uncontrolled memory allocation by sending a crafted compressed header block. The flaw, classified as [CWE-770] Allocation of Resources Without Limits or Throttling, can exhaust JVM heap memory and cause denial of service. All versions prior to 4.2.13.Final are affected, and the issue is fixed in 4.2.13.Final.

Critical Impact

Remote unauthenticated attackers can trigger heap exhaustion in any Netty-based HTTP/3 endpoint, causing service-wide denial of service without any prerequisites.

Affected Products

• Netty framework versions prior to 4.2.13.Final
• Applications using io.netty.handler.codec.http3.QpackDecoder
• Java services exposing HTTP/3 endpoints built on Netty

Discovery Timeline

• 2026-05-13 - CVE-2026-42582 published to NVD
• 2026-05-13 - Last updated in NVD database

Technical Details for CVE-2026-42582

Vulnerability Analysis

The vulnerability exists in the non-Huffman branch of io.netty.handler.codec.http3.QpackDecoder#decodeHuffmanEncodedLiteral. When decoding a string literal in a QPACK header block, the decoder reads a length prefix from the wire and immediately allocates a byte array of that size using new byte[length]. The allocation occurs before the decoder verifies that length bytes are actually present in the compressed field section.

QPACK is the header compression format used by HTTP/3, equivalent to HPACK in HTTP/2. The wire format uses prefixed integers, which allow very large numeric values to be expressed in only a few bytes. An attacker exploits this asymmetry to request a multi-gigabyte buffer using a small payload.

Root Cause

The decoder fails to enforce the invariant length <= in.readableBytes() before allocating the destination buffer. This missing bounds check turns an attacker-controlled wire value into a direct heap allocation request, satisfying the conditions for [CWE-770].

Attack Vector

An unauthenticated remote attacker sends a malformed HTTP/3 request containing a QPACK header block. The block declares a literal string with an inflated length prefix while supplying only a few bytes of actual data. The decoder calls new byte[length], and the JVM attempts to allocate the requested region. Repeated requests, or a single request with a sufficiently large length, exhaust the heap and produce OutOfMemoryError, halting request processing across the affected process.

No verified public proof-of-concept code is available. See the GitHub Security Advisory GHSA-2c5c-chwr-9hqw for upstream details.

Detection Methods for CVE-2026-42582

Indicators of Compromise

• Repeated java.lang.OutOfMemoryError: Java heap space events originating from Netty HTTP/3 codec threads
• Spikes in JVM old-generation heap usage correlated with inbound HTTP/3 traffic
• Abnormally large QPACK literal length fields observed in HTTP/3 packet captures

Detection Strategies

• Inspect HTTP/3 traffic for QPACK literal length prefixes that exceed the size of the enclosing QUIC stream frame
• Monitor stack traces containing io.netty.handler.codec.http3.QpackDecoder.decodeHuffmanEncodedLiteral in heap dumps or crash logs
• Correlate sudden process restarts of Netty-based services with inbound connections from a single source

Monitoring Recommendations

• Enable JVM heap and GC telemetry on all services exposing HTTP/3 listeners
• Alert on OutOfMemoryError exceptions and Netty channel exception events in application logs
• Track Netty dependency versions across build manifests to identify hosts running versions earlier than 4.2.13.Final

How to Mitigate CVE-2026-42582

Immediate Actions Required

• Upgrade Netty to 4.2.13.Final or later in all production and pre-production environments
• Inventory all Java services and transitive dependencies that pull in netty-codec-http3
• Restart affected JVM processes after upgrading to ensure the patched classes are loaded

Patch Information

The issue is fixed in Netty 4.2.13.Final. The patched decoder validates that the declared literal length does not exceed the number of readable bytes in the input buffer before allocating the destination array. Upgrade guidance is available in the GitHub Security Advisory GHSA-2c5c-chwr-9hqw.

Workarounds

• Disable HTTP/3 listeners on Netty-based services until the upgrade is applied
• Place an HTTP/3-aware reverse proxy in front of Netty endpoints to enforce maximum header block sizes
• Restrict exposure of HTTP/3 ports to trusted networks while patching is in progress