Netty: NoQuicTokenHandler is the tokenHandler used when the application does not set one. (CVE-2026-44894)

Netty's NoQuicTokenHandler, used when no token handler is set by the application, had a flaw before version 4.2.15.Final where its validateToken() method always returned 0, indicating a valid token. In QuicheQuicServerCodec.handlePacket(), this non-negative return was interpreted as a validated client address, lifting the 3× anti-amplification send limit per RFC 9000 §8.1. An attacker sending an Initial packet with any non-empty token bytes and a spoofed victim IP causes the server to reflect full-size handshake packets to the victim without the usual amplification limit. The correct behavior would be to return -1 for invalid tokens, enforcing the amplification limit. Version 4.2.15.Final patches this issue.

The vulnerability allows an unauthenticated attacker to cause a Netty server to reflect large QUIC handshake packets to a victim IP address, bypassing the normal anti-amplification limit. This can be used to amplify traffic in reflection-based denial-of-service attacks against the victim. There is no direct confidentiality or availability impact on the server itself.

Upgrade Netty to version 4.2.15.Final or later, where the NoQuicTokenHandler correctly returns -1 for invalid tokens, enforcing the anti-amplification limit. No other mitigation is indicated or required.