CVE-2026-44894
HighCVSS 7.5Exploitation Probability (EPSS)
Low risk4th percentile - higher than 4% of all known CVEs
Summary
The vulnerability in the Netty library concerns the default QUIC token handler (NoQuicTokenHandler), which unconditionally accepts any token as valid. An attacker can send an Initial packet with an arbitrary token and a spoofed victim source IP, causing the server to treat the victim as validated and send full responses without the 3× amplification limit.
Risk Assessment
The risk is an amplification attack on the victim, where the Netty server sends responses (e.g., certificates) many times larger than the received packet, potentially causing network overload (DoS) for the victim.
Recommendation
Immediately update the Netty library to version 4.2.15.Final or later, which includes a fix that correctly rejects invalid tokens.
Other vulnerabilities in Netty
See all- CVE-2026-42583High
Netty prior to versions 4.2.13.Final and 4.1.133.Final has a vulnerability in Lz4FrameDecoder that allocates a ByteBuf of size decompressedLength, potentially leading to uncontrolled memory allocation. An attacker can exploit a 21-byte header and compressed data to force this allocation.
- CVE-2026-42577High
Netty, an asynchronous network application framework, has an issue in versions from 4.2.0.Final to 4.2.13.Final where the epoll transport fails to detect and close TCP connections that receive a RST after being half-closed. This leads to stale channels that are never cleaned up and, in some code paths, a 100% CPU busy-loop in the event loop thread.
- CVE-2016-4970High
In Netty versions 4.0.x before 4.0.37.Final and 4.1.x before 4.1.1.Final, a vulnerability in OpenSslEngine.java allows remote attackers to cause a denial of service (infinite loop).
- CVE-2026-75595Critical
Netty is an asynchronous, event-driven network application framework. Prior to 4.1.137.Final and 4.2.17.Final, io.netty.handler.ssl.SslClientHelloHandler#decode checks the wrong offset before reading the four-byte TLS handshake header, so a ClientHello whose handshake header spans records can cause an IndexOutOfBoundsException and invoke select(ctx, null). This selects the default SslContext instead of the SNI-specific context. In deployments where per-SNI clientAuth=REQUIRE is the sole mutual TLS gate, the default SslContext uses clientAuth=NONE or clientAuth=OPTIONAL, and no application-layer certificate verification exists, an unauthenticated remote attacker can bypass the protected route's mutual TLS requirement. This issue is fixed in versions 4.1.137.Final and 4.2.17.Final.
- CVE-2026-56817Critical
Netty versions 4.2.0.Final through 4.2.15.Final and 4.1.0.Final through 4.1.135.Final have a vulnerability in XmlDecoder where delivering XML with a DOCTYPE declaration to an AsyncXMLInputFactory without security configuration can activate DTD and entity handling, creating XML External Entity (XXE) risk.
- CVE-2021-21409Medium
Netty (io.netty:netty-codec-http2) before version 4.1.61.Final contains a vulnerability enabling request smuggling. The content-length header is not correctly validated if the request only uses a single Http2HeaderFrame with endStream set to true. This could lead to request smuggling if the request is proxied to a remote peer and translated to HTTP/1.1. This is a followup of GHSA-wm47-8v5p-wjpj/CVE-2021-21295 which missed to fix this one case. Fixed as part of 4.1.61.Final.
- CVE-2021-21295Medium
Netty (io.netty:netty-codec-http2) before version 4.1.60.Final contains a vulnerability enabling request smuggling. When an HTTP/2 request is converted to HTTP/1.1 by `Http2StreamFrameToHttpObjectCodec` and forwarded to a remote peer, the Content-Length header is not validated by `Http2MultiplexHandler`, allowing an attacker to smuggle additional requests within the body.
- CVE-2019-20445Critical
HttpObjectDecoder.java in Netty before 4.1.44 allows a Content-Length header to be accompanied by a second Content-Length header, or by a Transfer-Encoding header, which may lead to improper processing of HTTP requests.
- CVE-2019-20444Critical
HttpObjectDecoder.java in Netty before 4.1.44 allows an HTTP header that lacks a colon, which might be interpreted as a separate header with incorrect syntax or as an "invalid fold". This can lead to incorrect parsing of HTTP requests.
- CVE-2019-16869High
Netty before 4.1.42.Final mishandles whitespace before the colon in HTTP headers (such as a "Transfer-Encoding : chunked" line), which leads to HTTP request smuggling.
Original NVD description (English source)
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.
Vulnerability data from NVD (NIST) · CISA KEV · EPSS