GHSA-cmm3-54f8-px4j: High severity maven/io.netty:netty-codec-classes-quic vulnerability
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 quicheaccept 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.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
maven/io.netty:netty-codec-classes-quicto a version that resolves this vulnerability.Fixed in 4.2.15.Final
Event History
Frequently Asked Questions
What is the severity of GHSA-cmm3-54f8-px4j?
The severity of GHSA-cmm3-54f8-px4j is classified as high with a score of 7.5.
How do I fix GHSA-cmm3-54f8-px4j?
To fix GHSA-cmm3-54f8-px4j, upgrade to the latest version of netty-codec-classes-quic.
What software is affected by GHSA-cmm3-54f8-px4j?
GHSA-cmm3-54f8-px4j affects maven/io.netty:netty-codec-classes-quic.
What is the impact of GHSA-cmm3-54f8-px4j?
The impact of GHSA-cmm3-54f8-px4j is a denial of service due to a vulnerability in token validation.
Is there a known exploit for GHSA-cmm3-54f8-px4j?
As of now, there are no public exploits reported for GHSA-cmm3-54f8-px4j.