CVE-2026-44894
Netty's Default QUIC token handler accepts any client-supplied token
Netty is a network application framework for development of protocol servers and clients. NoQuicTokenHandler is the tokenHandler used when the application does not set one. Prior to version 4.2.15.Final, 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. Version 4.2.15.Final patches the issue.
Attack profile
How easy it is to exploit
- Attack vector
- Network
- Complexity
- Low
- Privileges needed
- None
- User interaction
- None
What an attacker can affect
- Confidentiality
- None
- Integrity
- High
- Availability
- None
Exploit likelihood
What each source reports
CVE List Score used
7.5
Netty's Default QUIC token handler accepts any client-supplied token
Netty is a network application framework for development of protocol servers and clients. NoQuicTokenHandler is the tokenHandler used when the application does not set one. Prior to version 4.2.15.Final, 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. Version 4.2.15.Final patches the issue.
- Record
CVE-2026-44894- CVSS 3.1
- 7.5 High
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:N - CVSS 3.1
- 7.5 High
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H - Weakness
- CWE-940, CWE-346
- Updated
- 2026-11-02
EUVDEUVD-2026-36435
7.5
Netty is a network application framework for development of protocol servers and clients. NoQuicTokenHandler is the tokenHandler used when the application does not set one. Prior to version 4.2.15.Final, 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. Version 4.2.15.Final patches the issue.
- Record
EUVD-2026-36435- CVSS 3.1
- 7.5 High
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:N - Updated
- 2026-11-02
GitHub AdvisoriesGHSA-cmm3-54f8-px4j
7.5
Netty's Default QUIC token handler accepts any client-supplied token
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.
- Record
GHSA-cmm3-54f8-px4j- CVSS 3.1
- 7.5 High
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:N - Weakness
- CWE-940
- Updated
- 2026-11-02
NVD
7.5
Netty is a network application framework for development of protocol servers and clients. NoQuicTokenHandler is the tokenHandler used when the application does not set one. Prior to version 4.2.15.Final, 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. Version 4.2.15.Final patches the issue.
- Record
CVE-2026-44894- CVSS 3.1
- 7.5 High
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:N - CVSS 3.1
- 7.5 High
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H - Weakness
- CWE-940, CWE-346
- Updated
- 2026-11-02
OSV
7.5
Netty's Default QUIC token handler accepts any client-supplied token
Netty is a network application framework for development of protocol servers and clients. NoQuicTokenHandler is the tokenHandler used when the application does not set one. Prior to version 4.2.15.Final, 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. Version 4.2.15.Final patches the issue.
- Record
CVE-2026-44894- CVSS 3.1
- 7.5 High
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:N - Weakness
- CWE-940
- Updated
- 2026-11-02
OSVDEBIAN-CVE-2026-44894
7.5
Netty is a network application framework for development of protocol servers and clients. NoQuicTokenHandler is the tokenHandler used when the application does not set one. Prior to version 4.2.15.Final, 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. Version 4.2.15.Final patches the issue.
- Record
DEBIAN-CVE-2026-44894- CVSS 3.1
- 7.5 High
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:N - Updated
- 2026-11-02
OSVGHSA-cmm3-54f8-px4j
7.5
Netty's Default QUIC token handler accepts any client-supplied token
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.
- Record
GHSA-cmm3-54f8-px4j- CVSS 3.1
- 7.5 High
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:N - Weakness
- CWE-940
- Updated
- 2026-11-02
OSVUBUNTU-CVE-2026-44894
7.5
Netty is a network application framework for development of protocol servers and clients. NoQuicTokenHandler is the tokenHandler used when the application does not set one. Prior to version 4.2.15.Final, 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. Version 4.2.15.Final patches the issue.
- Record
UBUNTU-CVE-2026-44894- CVSS 3.1
- 7.5 High
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:N - CVSS 3.1
- 7.5 High
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H - Updated
- 2026-11-02
Affected products
Affected packages
| Package | Affected | Fixed |
|---|---|---|
io.netty:netty-codec-classes-quicMaven |
4.2.0.Final to 4.2.14.Final | 4.2.15.Final |
nettyDebian:12 |
All versions, plus listed versions 1:4.1.48-101:4.1.48-111:4.1.48-121:4.1.48-131:4.1.48-14 Show 7 moreShow less1:4.1.48-151:4.1.48-161:4.1.48-71:4.1.48-7+deb12u11:4.1.48-7+deb12u21:4.1.48-81:4.1.48-9 |
None known |
nettyDebian:13 |
All versions, plus listed versions 1:4.1.48-101:4.1.48-10+deb13u11:4.1.48-111:4.1.48-121:4.1.48-131:4.1.48-141:4.1.48-151:4.1.48-16 |
None known |
nettyDebian:14 |
All versions, plus listed versions 1:4.1.48-101:4.1.48-111:4.1.48-121:4.1.48-131:4.1.48-141:4.1.48-151:4.1.48-16 |
None known |
io.netty:netty-codec-classes-quicMaven |
4.2.0.Final up to 4.2.15.Final, plus listed versions 4.2.1.Final4.2.10.Final4.2.11.Final4.2.12.Final4.2.13.Final Show 9 moreShow less4.2.14.Final4.2.2.Final4.2.3.Final4.2.4.Final4.2.5.Final4.2.6.Final4.2.7.Final4.2.8.Final4.2.9.Final |
4.2.15.Final |
nettyUbuntu:Pro:14.04:LTS |
All versions, plus listed versions 1:3.2.6.Final-21:3.2.6.Final-2+deb8u2build0.14.04.1~esm11:3.2.6.Final-2+deb8u2ubuntu0.1~esm1 |
None known |
nettyUbuntu:Pro:16.04:LTS |
All versions, plus listed versions 1:3.2.6.Final-21:4.0.32-11:4.0.33-11:4.0.34-11:4.0.34-1ubuntu0.1~esm1 Show 4 moreShow less1:4.0.34-1ubuntu0.1~esm21:4.0.34-1ubuntu0.1~esm31:4.0.34-1ubuntu0.1~esm41:4.0.34-1ubuntu0.1~esm5 |
None known |
nettyUbuntu:Pro:18.04:LTS |
All versions, plus listed versions 1:4.1.7-41:4.1.7-4ubuntu0.1~esm11:4.1.7-4ubuntu0.11:4.1.7-4ubuntu0.1+esm11:4.1.7-4ubuntu0.1+esm2 Show 5 moreShow less1:4.1.7-4ubuntu0.1+esm31:4.1.7-4ubuntu0.1+esm41:4.1.7-4ubuntu0.1+esm51:4.1.7-4ubuntu0.1+esm61:4.1.7-4ubuntu0.1+esm7 |
None known |
nettyUbuntu:Pro:20.04:LTS |
All versions, plus listed versions 1:4.1.33-11:4.1.33-21:4.1.33-31:4.1.45-11:4.1.45-1ubuntu0.1~esm1 Show 5 moreShow less1:4.1.45-1ubuntu0.1~esm21:4.1.45-1ubuntu0.1~esm31:4.1.45-1ubuntu0.1~esm41:4.1.45-1ubuntu0.1~esm61:4.1.45-1ubuntu0.1~esm7 |
None known |
nettyUbuntu:Pro:22.04:LTS |
All versions, plus listed versions 1:4.1.48-41:4.1.48-4+deb11u1build0.22.04.11:4.1.48-4+deb11u2build0.22.04.11:4.1.48-4+deb11u2ubuntu0.1~esm11:4.1.48-4+deb11u2ubuntu0.1~esm2 Show 5 moreShow less1:4.1.48-4+deb11u2ubuntu0.11:4.1.48-4+deb11u2ubuntu0.1+esm11:4.1.48-4+deb11u2ubuntu0.1+esm31:4.1.48-4+deb11u2ubuntu0.21:4.1.48-4+deb11u2ubuntu0.2+esm1 |
None known |
Show 4 moreShow less
| Package | Affected | Fixed |
|---|---|---|
nettyUbuntu:Pro:24.04:LTS |
All versions, plus listed versions 1:4.1.48-71:4.1.48-81:4.1.48-91:4.1.48-9ubuntu0.1~esm11:4.1.48-9ubuntu0.1~esm2 Show 6 moreShow less1:4.1.48-9ubuntu0.11:4.1.48-9ubuntu0.1+esm11:4.1.48-9ubuntu0.1+esm31:4.1.48-9ubuntu0.21:4.1.48-9ubuntu0.2+esm11:4.1.48-9ubuntu0.2+esm2 |
None known |
nettyUbuntu:25.10 |
All versions, plus listed versions 1:4.1.48-101:4.1.48-10ubuntu0.25.10.11:4.1.48-10ubuntu0.25.10.2 |
None known |
nettyUbuntu:26.10 |
All versions, plus listed versions 1:4.1.48-161:4.1.48-16ubuntu1 |
None known |
nettyUbuntu:Pro:26.04:LTS |
All versions, plus listed versions 1:4.1.48-101:4.1.48-111:4.1.48-121:4.1.48-131:4.1.48-141:4.1.48-161:4.1.48-16ubuntu0.1~esm2 |
None known |
History
| Recorded | Changed | Sources |
|---|---|---|
| first indexed | CVE List, EUVD, GitHub Advisories, NVD, OSV |
Dates are when Every CVE recorded each change. Upstream dates may differ.
In short
CVE-2026-44894 is a high vulnerability (CVSS 7.5) in Netty, published June 8, 2026. No source lists public exploit code. EPSS puts the chance of exploitation in the next 30 days at 0.14%, the 3rd percentile. Fixed in io.netty:netty-codec-classes-quic 4.2.15.Final.
References
github.com/netty/netty/security/advisories/GHSA-cmm3-54f8-px4j
github.com/netty/netty/releases/tag/netty-4.2.15.Final
access.redhat.com/security/cve/CVE-2026-44894
bugzilla.redhat.com/show_bug.cgi?id=2488380
security.access.redhat.com/data/csaf/v2/vex/2026/cve-2026-44894.json
nvd.nist.gov/vuln/detail/CVE-2026-44894