VDB
Sign up
HIGH7.5

GHSA-cmm3-54f8-px4j

Netty's Default QUIC token handler accepts any client-supplied token

Quick fix

GHSA-cmm3-54f8-px4j — io.netty:netty-codec-classes-quic: upgrade to the fixed version with the command below.

# pom.xml: bump <version>4.2.15.Final</version> for io.netty:netty-codec-classes-quic

Details

NoQuicTokenHandler is the tokenHandler used when the application does not set one. Its writeToken() returns false (server will not send Retry — acceptable), but validateToken() unconditionally `return 0`. In QuicheQuicServerCodec.handlePacket(), a non-negative return from validateToken() is interpreted as 'token is valid, ODCID starts at offset 0', causing the server to call quiche_accept as if the client's address had been validated by a Retry round-trip. Per RFC 9000 §8.1, a validated address lifts the 3× anti-amplification send limit. Thus any attacker who includes ANY non-empty token bytes in an Initial packet — with a spoofed victim source IP — causes the Netty server to treat the victim as validated and reflect full-size handshake flights (certificates, etc.) toward it without the 3× cap. The correct 'no token handler' semantics would be to return -1 (invalid) so the normal un-validated path and amplification limit apply.

Are you affected?

Enter the version of the package you're using.

Affected packages

Maven/io.netty:netty-codec-classes-quic
Introduced in: 4.2.0.FinalFixed in: 4.2.15.Final
Fix# pom.xml: bump <version>4.2.15.Final</version> for io.netty:netty-codec-classes-quic

References