Netty CVE-2026-44894: Brief Summary of a QUIC Anti-Amplification Bypass via Default Token Handler

Introduction

A single character in a return statement is all that separated Netty's QUIC server implementation from correctly enforcing RFC 9000's anti-amplification protections. CVE-2026-44894 reveals how Netty's default NoQuicTokenHandler unconditionally returned 0 from its validateToken() method, causing the server to treat every incoming QUIC Initial packet as if the client's address had already been verified through a Retry exchange, effectively lifting the protocol's three-times amplification cap and enabling reflection DDoS attacks against arbitrary victims.

Netty is the dominant asynchronous network application framework in the Java ecosystem, with over 35,000 GitHub stars and adoption by at least 756 companies including organizations like Facebook, Apple, and Red Hat. It serves as the embedded network transport for Spring Boot, Apache Kafka, gRPC-Java, and numerous database drivers, making vulnerabilities in Netty's protocol implementations a concern that radiates across a vast dependency tree.

Technical Information

Root Cause: A Semantic Mismatch in NoQuicTokenHandler

The vulnerability lives in the NoQuicTokenHandler class within the io.netty:netty-codec-classes-quic Maven artifact. This class is the default QuicTokenHandler used whenever an application does not explicitly configure a custom handler, meaning the vulnerable code path is active in any default Netty QUIC server deployment.

NoQuicTokenHandler implements two key methods:

1. writeToken() returns false, indicating the server will not generate Retry tokens. This is an acceptable configuration choice per RFC 9000.
2. validateToken() unconditionally returns 0.

The problem is entirely in the second method. In QuicheQuicServerCodec.handlePacket(), the return value from validateToken() carries specific semantic meaning:

• A non-negative return value (>= 0) means "the token is valid, and the Original Destination Connection ID (ODCID) starts at this byte offset."
• A return value of -1 means "the token is invalid."

By returning 0, NoQuicTokenHandler tells the server codec that every token it encounters is valid and that the ODCID begins at offset 0. The server then calls quiche_accept with the client's address marked as validated, as if a successful Retry round-trip had occurred.

RFC 9000 Anti-Amplification: The Security Mechanism Being Bypassed

RFC 9000 Section 8.1 establishes a fundamental defense against reflection and amplification DDoS attacks in QUIC. Until a server has verified the client's source address (either through a Retry exchange or handshake completion), it must not send more than three times the number of bytes it has received from that client. This 3x cap exists precisely because QUIC runs over UDP, where source IP spoofing is trivial.

When NoQuicTokenHandler.validateToken() returns 0, the server believes address validation has already occurred. The 3x limit is lifted, and the server is free to send its full handshake flight, which includes TLS certificates, server parameters, and other cryptographic material, potentially amounting to several kilobytes of data in response to a single small Initial packet.

Attack Flow

The exploitation follows a classic reflection/amplification pattern:

1. The attacker constructs a QUIC Initial packet. The token field is populated with any non-empty byte sequence; the actual content is irrelevant since validateToken() does not inspect it.
2. The attacker sets the source IP address of the UDP datagram to the victim's IP address.
3. The packet is sent to a Netty QUIC server running a vulnerable version (4.2.0.Final through 4.2.14.Final) with no custom QuicTokenHandler configured.
4. The server's QuicheQuicServerCodec.handlePacket() invokes NoQuicTokenHandler.validateToken(), which returns 0.
5. The server interprets this as a successful address validation. It calls quiche_accept with the address marked as validated.
6. The server sends its full handshake response (certificates and all) to the victim's IP address, unconstrained by the 3x amplification limit.

The attack requires no authentication, no user interaction, and no prior access to the target server. The CVSS v3.1 vector AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:N reflects this: network accessible, low complexity, no privileges, no user interaction, with high integrity impact. The vulnerability is classified under CWE-940 ("Improper Verification of Source of a Communication Channel"), which describes failures to confirm that a communication originates from a legitimate source.

Why the CVSS Vector Shows Integrity Impact, Not Availability

An interesting aspect of the scoring is that the primary impact is categorized as integrity rather than availability. This reflects the fact that the vulnerability causes the server to violate its own protocol guarantees: it sends data to an address it should not have treated as validated. The DDoS amplification against the victim is a secondary consequence of this integrity violation in the server's address validation logic.

Patch Information

A public patch for CVE-2026-44894 was merged into the Netty repository on June 1, 2026, by Norman Maurer via commit 0d4e608. The fix shipped in Netty 4.2.15.Final, released on June 2, 2026.

The fix is a single-line change to NoQuicTokenHandler, located at codec-classes-quic/src/main/java/io/netty/handler/codec/quic/NoQuicTokenHandler.java:

@@ -38,7 +36,7 @@ public boolean writeToken(ByteBuf out, ByteBuf dcid, InetSocketAddress address)
 
     @Override
     public int validateToken(ByteBuf token, InetSocketAddress address) {
-        return 0;
+        return -1;
     }

By changing return 0 to return -1, the handler now correctly signals that it cannot validate any token. This ensures the QUIC server treats connections handled by the default (no-token) path as unvalidated, keeping the RFC 9000 Section 8.1 three-times anti-amplification limit in place. Previously, the return 0 caused the server to call quiche_accept as if the peer had passed a valid Retry token, which lifted the amplification cap entirely.

The commit also updated the class-level Javadoc. The old comment described the handler as disabling "token generation / validation completely," while the new comment clarifies it as a handler that "will not use any token and so also fail to validate any given token." This is a subtle but important distinction that aligns the documentation with the intended security semantics.

Alongside the fix, a new test class NoQuicTokenHandlerTest.java was added with three unit tests: one verifying that maxTokenLength() returns 0, one confirming that writeToken() returns false and produces no output, and critically, one asserting that validateToken() now returns -1 for any supplied token bytes. This test coverage directly guards against regression.

The total changeset is small: 2 additions and 4 deletions in the source file, plus a 62-line test class. The scope is narrow, but the security impact is significant.

For Maven projects, the upgrade is:

<dependency>
    <groupId>io.netty</groupId>
    <artifactId>netty-codec-classes-quic</artifactId>
    <version>4.2.15.Final</version>
</dependency>

For Gradle projects:

implementation 'io.netty:netty-codec-classes-quic:4.2.15.Final'

As a workaround for environments where an immediate upgrade is not feasible, implementing a custom QuicTokenHandler whose validateToken() method returns -1 for all tokens restores the correct security posture without requiring a full library upgrade.

Organizations consuming Netty indirectly through Spring Boot should monitor the open upgrade issues (#50666 and #50692) for the Spring Boot release incorporating Netty 4.2.15.Final.

Affected Systems and Versions

The vulnerability affects only the 4.2.x branch. The 4.1.x maintenance branch (which received a simultaneous release of 4.1.135.Final on June 2, 2026) is not affected by this specific QUIC token handler flaw.

The vulnerable configuration is the default one: any Netty QUIC server that does not explicitly set a custom QuicTokenHandler will use NoQuicTokenHandler and be exposed. This means the vulnerability is active out of the box in affected versions.

Vendor Security History

Netty's security track record reflects its position as widely deployed infrastructure software. The project has accumulated 47 published CVEs since 2014, with 24 having known public exploits (approximately 51%) and one reaching CISA KEV status (confirmed active exploitation). OpenCVE tracks 49 total CVEs for the Netty vendor.

CVE-2026-44894 is part of a larger batch: security bulletin SB2026060813, published June 8, 2026, documents 21 to 22 vulnerabilities in Netty. Other recent CVEs addressed in the same 4.2.15.Final release include CVE-2026-44890 (resource exhaustion) and CVE-2026-48748 (resource allocation without limits or throttling).

This is also not the first QUIC-related security issue in the Netty ecosystem. A prior vulnerability, GHSA-hqqc-jr88-p6x2, addressed a hash collision DoS attack in the netty-incubator-codec-quic project, disclosed March 31, 2025. The recurrence of QUIC-related flaws suggests this is an area of ongoing security scrutiny for the project.

The Netty project does maintain an active security advisory program on GitHub and follows responsible disclosure practices. For this CVE, the patch was available in the 4.2.15.Final release (June 1, 2026) before the GHSA advisory was publicly disclosed on June 5, 2026, giving users a window to update before full details were public.

References

• NVD: CVE-2026-44894
• GitHub Advisory: GHSA-cmm3-54f8-px4j
• Patch Commit: 0d4e608
• Netty 4.2.15.Final Release
• OSV: GHSA-cmm3-54f8-px4j
• GitLab Advisory: CVE-2026-44894
• Tenable: CVE-2026-44894
• Strobes VI: CVE-2026-44894
• Security Bulletin SB2026060813
• RFC 9000: QUIC Transport Protocol
• Cloudflare: QUIC Broadcast Address Amplification Vulnerability
• CWE-940: Improper Verification of Source of a Communication Channel
• Spring Boot Issue #50666: Upgrade to Netty 4.2.15.Final
• Spring Boot Issue #50692: Upgrade to Netty 4.2.15.Final
• CISA Known Exploited Vulnerabilities Catalog
• Netty QUIC Hash Collision DoS: GHSA-hqqc-jr88-p6x2