CVE-2026-56816: Netty HTTP/3 Denial of Service Vulnerability

CVE-2026-56816 Overview

CVE-2026-56816 is a denial of service vulnerability in Netty, a widely used Java network application framework for building protocol servers and clients. The flaw resides in the Http3FrameCodec component, where the decodeFrame method trusts the attacker-controlled payLoadLength field on reserved HTTP/3 frame types without enforcing an upper bound. An unauthenticated remote attacker can open multiple QUIC streams and send reserved frames declaring very large payload lengths, forcing the server to buffer data until memory is exhausted. The issue is classified as uncontrolled resource consumption [CWE-400] and is fixed in Netty version 4.2.16.Final.

Critical Impact
Remote unauthenticated attackers can exhaust server memory over HTTP/3, causing complete denial of service for any application built on vulnerable Netty releases.

Affected Products

Netty framework versions prior to 4.2.16.Final
Applications and services embedding Netty's HTTP/3 codec (Http3FrameCodec)
QUIC-enabled server implementations built on vulnerable Netty releases

Discovery Timeline

2026-07-21 - CVE-2026-56816 published to NVD
2026-07-22 - Last updated in NVD database

Technical Details for CVE-2026-56816

Vulnerability Analysis

Netty implements HTTP/3 frame parsing in the Http3FrameCodec class. When the decoder encounters a reserved frame type, it reads the wire-declared payLoadLength value and allocates buffer capacity to accumulate the incoming payload. The decoder does not validate payLoadLength against a configurable maximum or against available memory. An attacker who can reach the HTTP/3 endpoint can craft frames declaring payload sizes far beyond legitimate values.

HTTP/3 runs over QUIC, which multiplexes many streams over a single connection. An attacker opens multiple concurrent QUIC streams and sends reserved-type frames on each. Each stream then buffers up to the declared length, multiplying memory pressure across the process. The server exhausts heap or direct buffer memory and stops responding to legitimate traffic.

Root Cause

The root cause is missing input validation in decodeFrame. The method trusts the untrusted payLoadLength field for reserved frame types and does not apply the maximum frame size limits enforced on standard HTTP/3 frames. This is a classic uncontrolled resource consumption pattern [CWE-400].

Attack Vector

Exploitation requires only network reachability to the HTTP/3 listener. No authentication, no user interaction, and low attack complexity are needed. The attacker establishes a QUIC connection, opens several streams, and transmits reserved-type frames with oversized payLoadLength values. The vulnerability manifests in the Netty HTTP/3 codec buffering logic. Refer to the Netty GHSA-hpcc-26xq-25fv advisory and the upstream fix commit for the specific decoder changes.

Detection Methods for CVE-2026-56816

Indicators of Compromise

Sudden growth in JVM heap usage or direct buffer allocations on HTTP/3-enabled Netty services
Multiple concurrent QUIC streams from a single remote peer sending reserved HTTP/3 frame types
OutOfMemoryError events in application logs correlated with inbound QUIC traffic
Service unavailability or process crashes on hosts exposing UDP/443 or other QUIC ports

Detection Strategies

Inventory all Java applications and container images that ship Netty and identify versions earlier than 4.2.16.Final
Instrument Netty pipelines to log oversized frame lengths and reserved frame types at the codec layer
Monitor QUIC flow telemetry for abnormally large declared frame payloads from single source addresses

Monitoring Recommendations

Alert on rapid heap growth combined with sustained inbound UDP traffic to QUIC listeners
Track connection and stream counts per source IP on HTTP/3 endpoints and threshold outliers
Correlate application OutOfMemoryError events with upstream network flow records for the same time window

How to Mitigate CVE-2026-56816

Immediate Actions Required

Upgrade Netty to version 4.2.16.Final or later in all affected applications and rebuild dependent artifacts
Audit software bills of materials for transitive Netty dependencies pulled in by frameworks such as Vert.x, Reactor Netty, gRPC, and Spring WebFlux
Restrict exposure of HTTP/3 listeners to trusted networks until patched builds are deployed
Deploy connection-rate and per-source stream limits at the load balancer or QUIC gateway

Patch Information

The fix is available in Netty 4.2.16.Final. See the Netty 4.2.16.Final release notes and the commit 5b68c61 that adds bounds checking to the HTTP/3 frame decoder. Full details are documented in the GitHub Security Advisory GHSA-hpcc-26xq-25fv.

Workarounds

Disable HTTP/3 and QUIC listeners if the protocol is not required by the application
Terminate HTTP/3 at an upstream proxy or CDN that enforces frame size limits before forwarding to Netty
Apply strict JVM heap and direct memory limits so a single process failure does not cascade across the host
Rate-limit new QUIC connections and per-connection stream creation at the network edge

bash

# Example Maven dependency update to the fixed version
<dependency>
    <groupId>io.netty</groupId>
    <artifactId>netty-codec-http3</artifactId>
    <version>4.2.16.Final</version>
</dependency>

# Gradle equivalent
implementation 'io.netty:netty-codec-http3:4.2.16.Final'