What is the CVSS score of CVE-2026-44894?

CVE-2026-44894 has a CVSS 3.1 base score of 7.5 (High). CVSS vector: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:N. EPSS exploitation probability: 0.0%.

Which versions of Netty are affected by CVE-2026-44894?

Netty's QUIC codec (versions 4.2.0-4.2.14) contains a traffic amplification vulnerability that unauthenticated remote attackers can exploit to turn affected servers into DDoS reflectors.. A patch is available.

How to fix or mitigate CVE-2026-44894?

Within 24 hours: identify all systems and applications running Netty netty-codec-classes-quic 4.2.0.Final through 4.2.14.Final. Within 7 days: plan and stage upgrade to Netty 4.2.15.Final or later. Within 30 days: complete deployment and validate through testing on production-equivalent environment.

Netty CVE-2026-44894

EUVD-2026-36435 HIGH

Improper Verification of Source of a Communication Channel (CWE-940)

2026-06-08 https://github.com/netty/netty

GHSA-cmm3-54f8-px4j

Information Disclosure

7.5

CVSS 3.1 · Vendor: https://github.com/netty/netty

Severity by source

Vendor (https://github.com/netty/netty) PRIMARY

7.5 HIGH

AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:N

Red Hat

7.5 HIGH

qualitative

Primary rating from Vendor (https://github.com/netty/netty).

CVSS VectorVendor: https://github.com/netty/netty

CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:N

Attack Vector

Network

Attack Complexity

Low

Privileges Required

None

User Interaction

None

Scope

Unchanged

Confidentiality

None

Integrity

High

Availability

None

Lifecycle Timeline

Source Code Evidence Fetched

Jun 08, 2026 - 23:15 vuln.today

Analysis Generated

Jun 08, 2026 - 23:15 vuln.today

DescriptionCVE.org

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.

AnalysisAI

Traffic amplification in Netty's QUIC codec (io.netty:netty-codec-classes-quic versions 4.2.0.Final through 4.2.14.Final) allows remote unauthenticated attackers to weaponize Netty-based QUIC servers as DDoS reflectors. The default NoQuicTokenHandler's validateToken() unconditionally returns 0, which the server misinterprets as a successfully Retry-validated client address, bypassing RFC 9000's 3× anti-amplification limit and causing the server to reflect full-size handshake flights (including certificates) toward a spoofed victim IP. No public exploit identified at time of analysis, but the fix is published in Netty 4.2.15.Final.

Technical ContextAI

The flaw sits in Netty's QUIC transport layer, which wraps Cloudflare's quiche library via QuicheQuicServerCodec. QUIC uses a Retry packet round-trip to prove a client owns its source address before the server commits to sending large handshake responses; this defense is mandated by RFC 9000 §8.1 to prevent UDP-based amplification attacks. Netty exposes a QuicTokenHandler interface, and applications that do not configure one fall back to NoQuicTokenHandler. That default implementation correctly declines to issue Retry tokens (writeToken returns false), but its validateToken returns 0 unconditionally - and in QuicheQuicServerCodec.handlePacket, any non-negative return is treated as 'token valid, ODCID offset 0'. The server then invokes quiche_accept on the validated path and unlocks the unbounded send window. Mapped to CWE-940 (Improper Verification of Source of a Communication Channel), the root cause is a missing source-address verification step combined with a sentinel-value confusion between 'no handler configured' and 'token successfully validated'. Affected component is identified by CPE pkg:maven/io.netty:netty-codec-classes-quic.

RemediationAI

Vendor-released patch: upgrade io.netty:netty-codec-classes-quic to 4.2.15.Final or later, which is bundled with the Netty 4.2.15.Final release (https://github.com/netty/netty/releases/tag/netty-4.2.15.Final) and addresses this issue per advisory GHSA-cmm3-54f8-px4j. If immediate upgrade is not possible, configure an explicit QuicTokenHandler on the QUIC server bootstrap that actually issues and validates Retry tokens - for example Netty's InsecureQuicTokenHandler or a custom handler that returns -1 from validateToken when no genuine Retry round-trip has occurred - which forces clients through the un-validated path and reinstates the RFC 9000 3× anti-amplification cap; the trade-off is a small extra round-trip on initial connections. As a network-layer compensating control, restrict inbound UDP to the QUIC port (typically 443/udp) using BCP 38 / source-address validation upstream so spoofed Initial packets cannot reach the server, and consider rate-limiting unsolicited Initial packets per source - these reduce reflection utility but do not eliminate the underlying logic flaw.