Source: netty Version: 1:4.1.48-16 Severity: grave Tags: security upstream Justification: user security hole X-Debbugs-Cc: [email protected], Debian Security Team <[email protected]>
Hi, The following vulnerabilities were published for netty. I feel the situation cries for a rebase of netty in unstable to the newest versions. There are some of the CVEs where it is neither unclear if they apply to the 4.1.y. So please help assess the situation with thiese floods of new CVEs affecting netty. CVE-2026-42577[0]: | Netty is an asynchronous, event-driven network application | framework. From 4.2.0.Final to 4.2.13.Final , Netty's epoll | transport fails to detect and close TCP connections that receive a | RST after being half-closed, leading to stale channels that are | never cleaned up and, in some code paths, a 100% CPU busy-loop in | the event loop thread. This vulnerability is fixed in 4.2.13.Final. CVE-2026-42578[1]: | Netty is an asynchronous, event-driven network application | framework. Prior to 4.2.13.Final and 4.1.133.Final, Netty's | HttpProxyHandler constructs HTTP CONNECT requests with header | validation explicitly disabled. The newInitialMessage() method | creates headers using | DefaultHttpHeadersFactory.headersFactory().withValidation(false), | then adds user-provided outboundHeaders without any CRLF validation. | This allows an attacker who can influence the outbound headers to | inject arbitrary HTTP headers into the CONNECT request sent to the | proxy server. This vulnerability is fixed in 4.2.13.Final and | 4.1.133.Final. CVE-2026-42579[2]: | Netty is an asynchronous, event-driven network application | framework. Prior to 4.2.13.Final and 4.1.133.Final, Netty's DNS | codec does not enforce RFC 1035 domain name constraints during | either encoding or decoding. This creates a bidirectional attack | surface: malicious DNS responses can exploit the decoder, and user- | influenced hostnames can exploit the encoder. This vulnerability is | fixed in 4.2.13.Final and 4.1.133.Final. CVE-2026-42580[3]: | Netty is an asynchronous, event-driven network application | framework. Prior to 4.2.13.Final and 4.1.133.Final, Netty's chunk | size parser silently overflows int, enabling request smuggling | attacks. This vulnerability is fixed in 4.2.13.Final and | 4.1.133.Final. CVE-2026-42581[4]: | Netty is an asynchronous, event-driven network application | framework. Prior to 4.2.13.Final and 4.1.133.Final, | HttpObjectDecoder strips a conflicting Content-Length header when a | request carries both Transfer-Encoding: chunked and Content-Length, | but only for HTTP/1.1 messages. The guard is absent for HTTP/1.0. An | attacker that sends an HTTP/1.0 request with both headers causes | Netty to decode the body as chunked while leaving Content-Length | intact in the forwarded HttpMessage. Any downstream proxy or handler | that trusts Content-Length over Transfer-Encoding will disagree on | message boundaries, enabling request smuggling. This vulnerability | is fixed in 4.2.13.Final and 4.1.133.Final. CVE-2026-42582[5]: | Netty is an asynchronous, event-driven network application | framework. Prior to 4.2.13.Final, when decoding header blocks, the | non-Huffman branch of io.netty.handler.codec.http3.QpackDecoder#deco | deHuffmanEncodedLiteral may execute new byte[length] for a string | literal before verifying that length bytes are actually present in | the compressed field section. The wire encoding allows a very large | length to be expressed in few bytes. There is no check that length | <= in.readableBytes() before new byte[length]. This vulnerability is | fixed in 4.2.13.Final. CVE-2026-42583[6]: | Netty is an asynchronous, event-driven network application | framework. Prior to 4.2.13.Final and 4.1.133.Final, Lz4FrameDecoder | allocates a ByteBuf of size decompressedLength (up to 32 MB per | block) before LZ4 runs. A peer only needs a 21-byte header plus | compressedLength payload bytes - 22 bytes if compressedLength == 1 - | to force that allocation. This vulnerability is fixed in | 4.2.13.Final and 4.1.133.Final. CVE-2026-42584[7]: | Netty is an asynchronous, event-driven network application | framework. Prior to 4.2.13.Final and 4.1.133.Final, HttpClientCodec | pairs each inbound response with an outbound request by queue.poll() | once per response, including for 1xx. If the client pipelines GET | then HEAD and the server sends 103, then 200 with GET body, then 200 | for HEAD, the queue pairs HEAD with the first 200. The HEAD rule | then skips reading that message’s body, so the GET entity bytes stay | on the stream and the following 200 is parsed from the wrong offset. | This vulnerability is fixed in 4.2.13.Final and 4.1.133.Final. CVE-2026-42585[8]: | Netty is an asynchronous, event-driven network application | framework. Prior to 4.2.13.Final and 4.1.133.Final, Netty | incorrectly parses malformed Transfer-Encoding, enabling request | smuggling attacks. This vulnerability is fixed in 4.2.13.Final and | 4.1.133.Final. CVE-2026-42586[9]: | Netty is an asynchronous, event-driven network application | framework. Prior to 4.2.13.Final and 4.1.133.Final, the Netty Redis | codec encoder (RedisEncoder) writes user-controlled string content | directly to the network output buffer without validating or | sanitizing CRLF (\r\n) characters. Since the Redis Serialization | Protocol (RESP) uses CRLF as the command/response delimiter, an | attacker who can control the content of a Redis message can inject | arbitrary Redis commands or forge fake responses. This vulnerability | is fixed in 4.2.13.Final and 4.1.133.Final. CVE-2026-42587[10]: | Netty is an asynchronous, event-driven network application | framework. Prior to 4.2.13.Final and 4.1.133.Final, | HttpContentDecompressor accepts a maxAllocation parameter to limit | decompression buffer size and prevent decompression bomb attacks. | This limit is correctly enforced for gzip and deflate encodings via | ZlibDecoder, but is silently ignored when the content encoding is br | (Brotli), zstd, or snappy. An attacker can bypass the configured | decompression limit by sending a compressed payload with Content- | Encoding: br instead of Content-Encoding: gzip, causing unbounded | memory allocation and out-of-memory denial of service. The same | vulnerability exists in DelegatingDecompressorFrameListener for | HTTP/2 connections. This vulnerability is fixed in 4.2.13.Final and | 4.1.133.Final. CVE-2026-44893[11]: | Netty is a network application framework for development of protocol | servers and clients. In netty-codec-haproxy prior to versions | 4.1.135.Final and 4.2.15.Final, when decoding a PP2_TYPE_SSL TLV, | HAProxyMessage.readNextTLV() first calls | `header.retainedSlice(header.readerIndex(), length)` and only then | reads the 1-byte client field and 4-byte verify field. If the | attacker sets the TLV length below 5, the subsequent | readByte/readInt throws IndexOutOfBoundsException. | HAProxyMessageDecoder only catches HAProxyProtocolException around | this call, so the IOOBE propagates and the retained slice on the | pooled cumulation buffer is never released. Versions 4.1.135.Final | and 4.2.15.Final patch the issue. CVE-2026-44894[12]: | 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. CVE-2026-45416[13]: | Netty is a network application framework for development of protocol | servers and clients. Prior to versions 4.1.135.Final and | 4.2.15.Final, SslClientHelloHandler.decode() reads the 24-bit TLS | handshake length and, when the ClientHello does not fit in the first | record, eagerly allocates `ctx.alloc().buffer(handshakeLength)` | (line 161). The guard at line 140 is `handshakeLength > | maxClientHelloLength && maxClientHelloLength != 0`, and the | commonly-used SniHandler/AbstractSniHandler constructors | (SniHandler(Mapping), SniHandler(AsyncMapping), | AbstractSniHandler()) pass maxClientHelloLength=0 and | handshakeTimeoutMillis=0, so the length guard is disabled and no | timeout is scheduled. A 16 MiB request exceeds the default pooled | chunk size and becomes a huge/unpooled allocation performed | immediately. The buffer is retained in the handler until the channel | closes. Versions 4.1.135.Final and 4.2.15.Final patch the issue. CVE-2026-45536[14]: | Netty is a network application framework for development of protocol | servers and clients. Prior to versions 4.1.135.Final and | 4.2.15.Final, netty_unix_socket_recvFd sets msg_control to `char | control[CMSG_SPACE(sizeof(int))]` (line 940) — 24 bytes on 64-bit | Linux. A peer-sent SCM_RIGHTS cmsg carrying two ints has cmsg_len = | CMSG_LEN(8) = 24, which fits exactly with no MSG_CTRUNC, so the | kernel installs both fds in the receiving process. The subsequent | check `cmsg->cmsg_len == CMSG_LEN(sizeof(int))` (line 972, expected | 20) fails, the branch that would read the fd is skipped, and neither | installed fd is closed. The for(;;) loop calls recvmsg again (non- | blocking → EAGAIN → Java maps to 0 → read loop exits normally), | leaving two leaked fds per message. There is no MSG_CTRUNC handling. | Reachable via Epoll/KQueue DomainSocketChannel when the application | opts into DomainSocketReadMode.FILE_DESCRIPTORS (non-default). | Versions 4.1.135.Final and 4.2.15.Final patch the issue. CVE-2026-45673[15]: | Netty is a network application framework for development of protocol | servers and clients. Prior to versions 4.1.135.Final and | 4.2.15.Final, Netty's DNS resolver uses a predictable PRNG for | generating DNS transaction IDs and defaults to a static UDP source | port. This combination reduces the entropy of DNS queries, enabling | DNS Cache Poisoning (Kaminsky attack). Versions 4.1.135.Final and | 4.2.15.Final patch the issue. CVE-2026-45674[16]: | Netty is a network application framework for development of protocol | servers and clients. Prior to versions 4.1.135.Final and | 4.2.15.Final, Netty's DnsResolveContext fails to validate the origin | (bailiwick) of CNAME records in DNS responses. Versions | 4.1.135.Final and 4.2.15.Final patch the issue. CVE-2026-46340[17]: | Netty is a network application framework for development of protocol | servers and clients. In versions of netty-transport-sctp prior to | 4.1.135.Final and 4.2.15.Final, for each non-complete SctpMessage | fragment the handler does `fragments.put(streamId, | Unpooled.wrappedBuffer(frag, byteBuf))`, wrapping the previous | accumulator and the new slice into a *new* CompositeByteBuf every | time. After N fragments the accumulator is an N-deep chain of | composites, each holding references and component arrays; | readableBytes()/getBytes() on the final buffer recurse N levels. | There is no limit on N, on total bytes, or on the number of | streamIdentifiers an attacker can open (each gets its own map | entry). A peer that never sets the `complete` flag can grow this | structure indefinitely from tiny 1-byte DATA chunks. Versions | 4.1.135.Final and 4.2.15.Final patch the issue. CVE-2026-47244[18]: | Netty is a network application framework for development of protocol | servers and clients. Prior to versions 4.1.135.Final and | 4.2.15.Final, DefaultHttp2Connection.DefaultEndpoint initialises | maxActiveStreams/maxStreams to Integer.MAX_VALUE, and Http2Settings | never inserts SETTINGS_MAX_CONCURRENT_STREAMS by default | (Http2Settings.java:305-307 only clamps a user-supplied value). | Unless the application explicitly calls | initialSettings().maxConcurrentStreams(n), a Netty HTTP/2 server | advertises no limit and enforces none locally. Each open stream | allocates a DefaultStream object, PropertyMap slots, flow-controller | state and IntObjectHashMap entry; with ~2^30 permissible odd stream | IDs a single TCP connection can create hundreds of thousands of | long-lived stream objects. This is also the precondition for | CVE-2023-44487-style Rapid-Reset amplification, where the absence of | a low concurrent cap multiplies backend work. Versions 4.1.135.Final | and 4.2.15.Final patch the issue. CVE-2026-47691[19]: | Netty is a network application framework for development of protocol | servers and clients. Prior to versions 4.1.135.Final and | 4.2.15.Final, Netty's `DnsResolveContext` insufficiently validates | the bailiwick of NS records, enabling DNS Cache Poisoning. An | attacker controlling an authoritative name server for a subdomain | can poison the cache for parent domains (like `.co.uk`). In `io.nett | y.resolver.dns.DnsResolveContext.AuthoritativeNameServerList#add` | method accepts any NS record from the AUTHORITY section as long as | the record's name is a suffix of the questionName. Subsequently, the | `handleWithAdditional` method caches the associated A records from | the ADDITIONAL section directly into the | `authoritativeDnsServerCache` under the parent domain's key. This | bypasses standard bailiwick rules, where a server authoritative for | a subdomain should not be trusted to provide authoritative records | for its parent. The poisoned cache is then used for all future | resolutions under the parent domain's key. Versions 4.1.135.Final | and 4.2.15.Final patch the issue. CVE-2026-48006[20]: | Netty is a network application framework for development of protocol | servers and clients. Prior to versions 4.1.135.Final and | 4.2.15.Final, the RedisArrayAggregator handler permanently leaks | pooled direct-memory buffers when a Redis pipeline connection closes | before a RESP array aggregate completes. The handler retains child | messages in per-handler state (`depths` field) but defines no | `channelInactive`, `handlerRemoved`, or `exceptionCaught` method to | release them when the pipeline tears down. Because the leaked | buffers are slices of `PooledByteBufAllocator` chunks, they prevent | those chunks from being returned to the JVM-wide direct-memory pool. | Repeated connection churn by any network peer monotonically drains | this shared pool, eventually causing allocation failures on all | Netty channels in the process. Versions 4.1.135.Final and | 4.2.15.Final patch the issue. CVE-2026-48043[21]: | Netty is a network application framework for development of protocol | servers and clients. In netty-codec-http2 prior to versions | 4.1.135.Final and 4.2.15.Final, the | `DelegatingDecompressorFrameListener` class orchestrates HTTP/2 | decompression by embedding a per-stream `EmbeddedChannel` that runs | the appropriate decompression codec (gzip, deflate, zstd) and | forwards decompressed chunks to a wrapped listener. Each | decompressed chunk is a pooled `ByteBuf` handed to an anonymous | `ChannelInboundHandlerAdapter` tail handler, which becomes the sole | owner responsible for releasing it. A remote peer could send frames | that would result in the flow-controller throwing and so trigger a | resource leak which at the end might take down the whole JVM due | OOME. Versions 4.1.135.Final and 4.2.15.Final patch the issue. CVE-2026-48059[22]: | Netty is a network application framework for development of protocol | servers and clients. Prior to versions 4.1.135.Final and | 4.2.15.Final, the HAProxy PROXY protocol v2 codec in netty leaks | native or heap memory on every connection when a client sends a | syntactically valid header containing nested `PP2_TYPE_SSL` TLVs | (type-length-value records) at depth two or greater. The leak occurs | on the successful parse path — no exception is thrown, the message | fires downstream, the decoder removes itself, and the application | releases the `HAProxyMessage` normally. Yet the underlying | cumulation buffer (a pooled, potentially direct `ByteBuf` allocated | by the channel) remains permanently pinned. Versions 4.1.135.Final | and 4.2.15.Final patch the issue. CVE-2026-48748[23]: | Netty is a network application framework for development of protocol | servers and clients. Prior to version 4.2.15.Final, a memory | exhaustion vulnerability in the Netty HTTP/3 codec allows the | creation of an infinite number of blocked streams, which can cause | OOM error. Version 4.2.15.Final patches the issue. CVE-2026-50009[24]: | Netty is a network application framework for development of protocol | servers and clients. Prior to version 4.2.15.Final, Netty QUIC | exposes the stateless reset token on the network path when using the | default HMAC-based connection-ID and stateless-reset-token | generators. The reset token for the server's current source | connection ID can be derived from bytes that appear as the | connection ID in QUIC headers after a source-CID rotation. An on- | path attacker observing the headers can use the token to perform a | Denial of Service by sending a spoofed Stateless Reset packet. | Version 4.2.15.Final patches the issue. CVE-2026-50010[25]: | Netty is a network application framework for development of protocol | servers and clients. Prior to versions 4.1.135.Final and | 4.2.15.Final, SimpleTrustManagerFactory.engineGetTrustManagers() and | related paths wrap any user-supplied plain X509TrustManager in | X509TrustManagerWrapper, which extends X509ExtendedTrustManager but | implements the 3-arg checkServerTrusted(chain, authType, SSLEngine) | by discarding the SSLEngine and calling the 2-arg delegate. Because | the object now IS an X509ExtendedTrustManager, neither SunJSSE's | internal AbstractTrustManagerWrapper nor Netty's own | OpenSslX509TrustManagerWrapper will re-wrap it to add endpoint- | identification. Consequently, even though Netty 4.2 sets | endpointIdentificationAlgorithm="HTTPS" by default, a client built | with `SslContextBuilder.forClient().trustManager(somePlainX509TrustM | anager)` performs no hostname verification at all. Versions | 4.1.135.Final and 4.2.15.Final patch the issue. CVE-2026-50011[26]: | Netty is a network application framework for development of protocol | servers and clients. Prior to versions 4.1.135.Final and | 4.2.15.Final, RedisArrayAggregator pre-allocates ArrayList with | initial capacity equal to the RESP array element count declared in | an array header. That count is taken from the wire before the | corresponding child messages exist. A small malicious header can | claim a huge initial capacity. Versions 4.1.135.Final and | 4.2.15.Final patch the issue. CVE-2026-50020[27]: | Netty is a network application framework for development of protocol | servers and clients. Prior to versions 4.1.135.Final and | 4.2.15.Final, before reading the first request-line, | `HttpObjectDecoder` skips every byte for which | `Character.isISOControl(b)` is `true` (0x00–0x1F and 0x7F) as well | as all whitespace. RFC 9112 §2.2 only asks servers to ignore empty | CRLF lines preceding the request-line — a carefully scoped | robustness allowance intended to handle HTTP/1.0 POST workarounds. | Silently absorbing NUL bytes, SOH, STX, and other non-CRLF control | characters goes significantly beyond this, and can be exploited for | request-boundary confusion in pipelined or multiplexed transports | where a front-end component treats those bytes differently. Versions | 4.1.135.Final and 4.2.15.Final patch the issue. CVE-2026-50560[28]: | Netty is a network application framework for development of protocol | servers and clients. Prior to versions 4.1.135.Final and | 4.2.15.Final, Netty HTTP/2 max header size handling produces an | attack similar to HTTP/2 Rapid Reset. There is a setting in the | http2 specification called `SETTINGS_MAX_HEADER_LIST_SIZE`. When a | client sends that setting to Netty, it appears that Netty will | behave as follows: read the request; proxy the request to the | origin; attempt to produce a response; and create an exception while | writing the headers for the response. Functionally, this should be | similar to the http2 reset attack, but with a different on-the-wire | signature. Versions 4.1.135.Final and 4.2.15.Final patch the issue. If you fix the vulnerabilities please also make sure to include the CVE (Common Vulnerabilities & Exposures) ids in your changelog entry. For further information see: [0] https://security-tracker.debian.org/tracker/CVE-2026-42577 https://www.cve.org/CVERecord?id=CVE-2026-42577 [1] https://security-tracker.debian.org/tracker/CVE-2026-42578 https://www.cve.org/CVERecord?id=CVE-2026-42578 [2] https://security-tracker.debian.org/tracker/CVE-2026-42579 https://www.cve.org/CVERecord?id=CVE-2026-42579 [3] https://security-tracker.debian.org/tracker/CVE-2026-42580 https://www.cve.org/CVERecord?id=CVE-2026-42580 [4] https://security-tracker.debian.org/tracker/CVE-2026-42581 https://www.cve.org/CVERecord?id=CVE-2026-42581 [5] https://security-tracker.debian.org/tracker/CVE-2026-42582 https://www.cve.org/CVERecord?id=CVE-2026-42582 [6] https://security-tracker.debian.org/tracker/CVE-2026-42583 https://www.cve.org/CVERecord?id=CVE-2026-42583 [7] https://security-tracker.debian.org/tracker/CVE-2026-42584 https://www.cve.org/CVERecord?id=CVE-2026-42584 [8] https://security-tracker.debian.org/tracker/CVE-2026-42585 https://www.cve.org/CVERecord?id=CVE-2026-42585 [9] https://security-tracker.debian.org/tracker/CVE-2026-42586 https://www.cve.org/CVERecord?id=CVE-2026-42586 [10] https://security-tracker.debian.org/tracker/CVE-2026-42587 https://www.cve.org/CVERecord?id=CVE-2026-42587 [11] https://security-tracker.debian.org/tracker/CVE-2026-44893 https://www.cve.org/CVERecord?id=CVE-2026-44893 [12] https://security-tracker.debian.org/tracker/CVE-2026-44894 https://www.cve.org/CVERecord?id=CVE-2026-44894 [13] https://security-tracker.debian.org/tracker/CVE-2026-45416 https://www.cve.org/CVERecord?id=CVE-2026-45416 [14] https://security-tracker.debian.org/tracker/CVE-2026-45536 https://www.cve.org/CVERecord?id=CVE-2026-45536 [15] https://security-tracker.debian.org/tracker/CVE-2026-45673 https://www.cve.org/CVERecord?id=CVE-2026-45673 [16] https://security-tracker.debian.org/tracker/CVE-2026-45674 https://www.cve.org/CVERecord?id=CVE-2026-45674 [17] https://security-tracker.debian.org/tracker/CVE-2026-46340 https://www.cve.org/CVERecord?id=CVE-2026-46340 [18] https://security-tracker.debian.org/tracker/CVE-2026-47244 https://www.cve.org/CVERecord?id=CVE-2026-47244 [19] https://security-tracker.debian.org/tracker/CVE-2026-47691 https://www.cve.org/CVERecord?id=CVE-2026-47691 [20] https://security-tracker.debian.org/tracker/CVE-2026-48006 https://www.cve.org/CVERecord?id=CVE-2026-48006 [21] https://security-tracker.debian.org/tracker/CVE-2026-48043 https://www.cve.org/CVERecord?id=CVE-2026-48043 [22] https://security-tracker.debian.org/tracker/CVE-2026-48059 https://www.cve.org/CVERecord?id=CVE-2026-48059 [23] https://security-tracker.debian.org/tracker/CVE-2026-48748 https://www.cve.org/CVERecord?id=CVE-2026-48748 [24] https://security-tracker.debian.org/tracker/CVE-2026-50009 https://www.cve.org/CVERecord?id=CVE-2026-50009 [25] https://security-tracker.debian.org/tracker/CVE-2026-50010 https://www.cve.org/CVERecord?id=CVE-2026-50010 [26] https://security-tracker.debian.org/tracker/CVE-2026-50011 https://www.cve.org/CVERecord?id=CVE-2026-50011 [27] https://security-tracker.debian.org/tracker/CVE-2026-50020 https://www.cve.org/CVERecord?id=CVE-2026-50020 [28] https://security-tracker.debian.org/tracker/CVE-2026-50560 https://www.cve.org/CVERecord?id=CVE-2026-50560 Regards, Salvatore
