CVE-2026-44892: Netty HTTP/3 Codec DoS Vulnerability

CVE-2026-44892 Overview

CVE-2026-44892 affects Netty, a network application framework used to build protocol servers and clients in Java. The flaw resides in the Http3ConnectionHandler within the HTTP/3 codec. Prior to version 4.2.15.Final, the default configuration does not enforce a maximum header size limit. When a peer omits the HTTP3_SETTINGS_MAX_FIELD_SECTION_SIZE setting, the implementation defaults to an unbounded value. A malicious client or server can exploit this to send an excessive volume of headers, exhausting heap memory and triggering an OutOfMemoryError. The result is a denial of service against any application built on the affected Netty HTTP/3 stack.

Critical Impact
Remote, unauthenticated attackers can crash Netty-based HTTP/3 services through memory exhaustion, disrupting availability of dependent applications.

Affected Products

Netty netty versions prior to 4.2.15.Final
Applications embedding the Netty HTTP/3 codec with default Http3ConnectionHandler configuration
Java services exposing HTTP/3 endpoints built on vulnerable Netty releases

Discovery Timeline

2026-06-12 - CVE-2026-44892 published to the National Vulnerability Database
2026-06-17 - Last updated in NVD database

Technical Details for CVE-2026-44892

Vulnerability Analysis

The vulnerability is classified as Uncontrolled Resource Consumption [CWE-400], resulting in memory exhaustion denial of service. HTTP/3 uses QPACK header compression and exposes the HTTP3_SETTINGS_MAX_FIELD_SECTION_SIZE setting to advertise the maximum size of header sections a peer will accept. Netty's Http3ConnectionHandler relies on that peer-supplied setting to bound buffering behavior.

When a peer does not transmit this setting during connection establishment, Netty defaults to an unbounded limit instead of a safe ceiling. An attacker controlling either side of the connection can omit the setting and then send an unusually large header section. The codec continues accepting and buffering header field data until the Java Virtual Machine exhausts available heap space.

The resulting OutOfMemoryError typically terminates the process or renders it unresponsive. Because HTTP/3 operates over QUIC and UDP, attackers can initiate sessions without TCP-level filtering, increasing reachability of the vulnerable code path.

Root Cause

The root cause is an insecure default configuration. The Http3ConnectionHandler treats an absent HTTP3_SETTINGS_MAX_FIELD_SECTION_SIZE value as unlimited rather than applying a conservative default. This violates safe-by-default design principles for network-facing parsers handling untrusted input.

Attack Vector

The attack is network-based and requires no authentication or user interaction. An attacker opens an HTTP/3 connection to a vulnerable Netty endpoint, suppresses the field-section-size setting, and transmits an oversized header block. The malicious actor can also operate as a hostile server against a Netty-based HTTP/3 client. Each malicious connection consumes server heap until the JVM throws OutOfMemoryError.

No verified public exploit code is available. The vulnerability mechanism is documented in the GitHub Security Advisory GHSA-c2rx-5r8w-8xr2.

Detection Methods for CVE-2026-44892

Indicators of Compromise

Java application crashes or restarts accompanied by java.lang.OutOfMemoryError entries referencing Netty HTTP/3 classes in stack traces
Sudden heap growth in JVM metrics correlated with inbound HTTP/3 (QUIC/UDP) traffic from a single peer
HTTP/3 connections that never advertise HTTP3_SETTINGS_MAX_FIELD_SECTION_SIZE followed by abnormally large header sections

Detection Strategies

Inventory Java services for Netty dependencies and identify any version below 4.2.15.Final that loads the HTTP/3 codec
Inspect QUIC SETTINGS frames at perimeter proxies or QUIC-aware sensors to flag peers omitting field-section-size limits
Correlate JVM OutOfMemoryError events with HTTP/3 request volume in log aggregation pipelines

Monitoring Recommendations

Track heap utilization, garbage collection pauses, and process restarts on HTTP/3-facing services
Alert on repeated TCP/UDP source addresses producing outsized HTTP/3 header payloads
Forward Netty and JVM logs to a centralized analytics platform to detect crash patterns matching this advisory

How to Mitigate CVE-2026-44892

Immediate Actions Required

Upgrade Netty to version 4.2.15.Final or later across all affected services and rebuild dependent artifacts
Audit transitive dependencies in build manifests such as pom.xml and build.gradle to confirm the patched version is resolved
Restart affected JVM processes after upgrade to ensure the patched Http3ConnectionHandler is loaded

Patch Information

The vendor released the fix in Netty 4.2.15.Final. Release details are available in the GitHub Netty Release Notes and the GitHub Security Advisory GHSA-c2rx-5r8w-8xr2.

Workarounds

Explicitly configure a bounded HTTP3_SETTINGS_MAX_FIELD_SECTION_SIZE value when initializing Http3ConnectionHandler if immediate upgrade is not possible
Place HTTP/3-capable services behind a reverse proxy or QUIC gateway that enforces header size limits
Restrict exposure of HTTP/3 endpoints to trusted networks until patching is complete

bash

# Configuration example: enforce a maximum HTTP/3 header section size
# Refer to the Netty advisory for the exact builder API in your version
# Pseudocode
Http3.newConnectionHandlerBuilder()
     .initialSettings(settings -> settings.maxFieldSectionSize(65536))
     .build();