CVE-2026-44894: Netty QUIC Amplification DoS Vulnerability

CVE-2026-44894 Overview

CVE-2026-44894 is a high-severity vulnerability in Netty, a widely deployed network application framework used to build protocol servers and clients on the Java Virtual Machine. The flaw resides in NoQuicTokenHandler, the default QUIC token handler used when an application does not configure a custom one. Its validateToken() method unconditionally returns 0, signaling the address as validated. An attacker who supplies any non-empty token in a spoofed Initial packet causes the Netty QUIC server to bypass the RFC 9000 §8.1 anti-amplification limit and reflect full handshake flights toward a victim. Netty 4.2.15.Final patches the issue.

Critical Impact
Attackers can leverage Netty QUIC servers as reflection amplifiers, sending full-size TLS handshake responses including certificates to spoofed victim IP addresses.

Affected Products

Netty versions prior to 4.2.15.Final
Applications using NoQuicTokenHandler (the default when no token handler is set)
QUIC server deployments built on QuicheQuicServerCodec

Discovery Timeline

2026-06-12 - CVE-2026-44894 published to NVD
2026-06-17 - Last updated in NVD database

Technical Details for CVE-2026-44894

Vulnerability Analysis

The vulnerability classifies as an Amplification Attack [CWE-940: Improper Verification of Source of a Communication Channel]. Netty's QUIC implementation delegates address validation decisions to a QuicTokenHandler. When the application supplies none, Netty installs NoQuicTokenHandler as a safe default.

The handler correctly returns false from writeToken(), meaning the server will not issue a Retry packet. However, validateToken() unconditionally returns 0 instead of -1. In QuicheQuicServerCodec.handlePacket(), any non-negative return value is interpreted as a successful validation result, with the Original Destination Connection ID (ODCID) starting at offset zero in the token buffer.

The server then invokes quiche_accept as if the client address were validated through a Retry round-trip. Per RFC 9000 §8.1, this lifts the 3× anti-amplification send limit, allowing the server to transmit unrestricted handshake data including certificate chains.

Root Cause

The root cause is a semantic inversion in the no-op token handler. The correct behavior for a handler that does not issue tokens is to reject all incoming tokens by returning -1, forcing the unvalidated code path that enforces the 3× send cap. Returning 0 instead signals every Initial packet containing any token bytes as pre-validated.

Attack Vector

An attacker crafts a QUIC Initial packet with a forged source IP address matching the victim. The packet contains any non-empty token field. Upon receipt, the Netty server treats the spoofed source as validated and transmits the full TLS 1.3 handshake — including the server certificate, intermediate certificates, and CRYPTO frames — to the victim address.

Because the anti-amplification limit is removed, a small attacker packet produces a multi-kilobyte response, yielding significant amplification suitable for distributed reflection denial-of-service campaigns. The attack requires no authentication and no user interaction.

No public proof-of-concept exploit code is currently available. Refer to the GitHub Security Advisory GHSA-cmm3-54f8-px4j for the authoritative technical description.

Detection Methods for CVE-2026-44894

Indicators of Compromise

Outbound QUIC handshake traffic with significantly higher byte volume than corresponding inbound Initial packets from the same remote address.
QUIC Initial packets arriving with non-empty token fields when the server has not previously issued a Retry.
UDP port 443 traffic patterns showing 1:N response ratios characteristic of reflection abuse.

Detection Strategies

Audit dependency manifests (pom.xml, build.gradle) across the environment for Netty versions earlier than 4.2.15.Final paired with QUIC modules such as netty-codec-quic.
Inspect application code for QUIC server bootstrap paths that do not explicitly configure a QuicTokenHandler, leaving the vulnerable default active.
Deploy network flow analysis to flag asymmetric byte ratios between QUIC clients and servers consistent with amplification reflection.

Monitoring Recommendations

Forward network flow telemetry and QUIC server logs into a centralized analytics platform to baseline normal handshake sizes and alert on anomalies.
Correlate spikes in outbound QUIC traffic with the absence of corresponding application-layer sessions, indicating reflected handshakes to non-clients.
Monitor upstream bandwidth saturation on systems exposing QUIC endpoints, which can signal active reflection abuse.

How to Mitigate CVE-2026-44894

Immediate Actions Required

Upgrade all Netty deployments running QUIC server components to version 4.2.15.Final or later.
Inventory applications using QUIC and confirm whether they rely on NoQuicTokenHandler either explicitly or by default.
Restrict exposure of QUIC server endpoints to the internet until patching is complete.

Patch Information

The Netty maintainers released the fix in 4.2.15.Final. Refer to the Netty 4.2.15.Final release notes and the GitHub Security Advisory GHSA-cmm3-54f8-px4j for full remediation details. The patch corrects NoQuicTokenHandler.validateToken() to return -1, ensuring the server applies the RFC 9000 anti-amplification limit.

Workarounds

Configure a custom QuicTokenHandler that implements Retry-based address validation, replacing the default no-op handler.
Apply rate limiting and source address filtering at upstream network devices to constrain potential amplification factor.
Restrict QUIC service exposure with firewall rules or load balancer policies until the upgrade is deployed.

bash

# Maven dependency upgrade example
# Update Netty to the patched release in pom.xml
# <dependency>
#   <groupId>io.netty</groupId>
#   <artifactId>netty-all</artifactId>
#   <version>4.2.15.Final</version>
# </dependency>
mvn versions:set-property -Dproperty=netty.version -DnewVersion=4.2.15.Final
mvn dependency:tree | grep netty