Chrisvest

**Name of the Vulnerable Software and Affected Versions** Netty versions prior to 4.1.135.Final Netty versions prior to 4.2.15.Final **Description** Before reading the first request-line, the `HttpObjectDecoder` function silently skips all whitespace and every byte for which `Character.isISOControl(b)` is true (0x00–0x1F and 0x7F). This behavior deviates from RFC 9112 §2.2, which only permits servers to ignore empty CRLF lines preceding the request-line to handle HTTP/1.0 POST workarounds. By absorbing non-CRLF control characters such as NUL, SOH, and STX, the software can be exploited for request-boundary confusion in pipelined or multiplexed transports. This occurs when a front-end component, such as a load balancer or TLS terminator, treats these bytes differently than Netty, potentially leading to request-desync or smuggling attacks. **Recommendations** Update to version 4.1.135.Final. Update to version 4.2.15.Final.

**Name of the Vulnerable Software and Affected Versions** Netty versions prior to 4.1.135.Final Netty versions prior to 4.2.15.Final **Description** Netty is a network application framework used for developing protocol servers and clients. The `SimpleTrustManagerFactory.engineGetTrustManagers()` function and related paths wrap user-supplied plain X509TrustManager in X509TrustManagerWrapper. This wrapper extends X509ExtendedTrustManager but implements the 3-argument `checkServerTrusted(chain, authType, SSLEngine)` function by discarding the `SSLEngine` and calling the 2-argument delegate. Because the object is identified as an X509ExtendedTrustManager, internal wrappers from SunJSSE or Netty do not re-wrap it to add endpoint-identification. This results in a failure to perform hostname verification when a client is built using `SslContextBuilder.forClient().trustManager(somePlainX509TrustManager)`, even if `endpointIdentificationAlgorithm` is set to "HTTPS" by default, potentially enabling man-in-the-middle attacks. **Recommendations** Update to version 4.1.135.Final. Update to version 4.2.15.Final.

**Name of the Vulnerable Software and Affected Versions** Netty versions prior to 4.1.135.Final Netty versions prior to 4.2.15.Final **Description** 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 the `depths` field but lacks `channelInactive`, `handlerRemoved`, or `exceptionCaught` methods to release them during pipeline teardown. Since the leaked buffers are slices of `PooledByteBufAllocator` chunks, they prevent these chunks from returning to the JVM-wide direct-memory pool. Continuous connection churn by a network peer drains this shared pool, leading to allocation failures across all Netty channels in the process. **Recommendations** Update to version 4.1.135.Final. Update to version 4.2.15.Final.

**Name of the Vulnerable Software and Affected Versions** netty-codec-http2 versions prior to 4.1.135.Final netty-codec-http2 versions prior to 4.2.15.Final **Description** The `DelegatingDecompressorFrameListener` class manages HTTP/2 decompression by using a per-stream `EmbeddedChannel` to run decompression codecs such as gzip, deflate, or zstd. Decompressed chunks are handled as pooled `ByteBuf` objects and passed to an anonymous `ChannelInboundHandlerAdapter` tail handler responsible for their release. A remote peer can send specifically crafted frames that cause the flow-controller to throw an exception, triggering a resource leak. This leak can lead to an OutOfMemoryError (OOME), potentially crashing the Java Virtual Machine (JVM). **Recommendations** Update to version 4.1.135.Final. Update to version 4.2.15.Final.

**Name of the Vulnerable Software and Affected Versions** Netty versions prior to 4.1.135.Final Netty versions prior to 4.2.15.Final **Description** The HAProxy PROXY protocol v2 codec 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. This occurs during the successful parse path where the underlying cumulation buffer, a pooled and potentially direct `ByteBuf` allocated by the channel, remains permanently pinned even after the `HAProxyMessage` is released and the decoder removes itself. **Recommendations** Update to version 4.1.135.Final. Update to version 4.2.15.Final.

**Name of the Vulnerable Software and Affected Versions** netty-transport-sctp versions prior to 4.1.135.Final netty-transport-sctp versions prior to 4.2.15.Final **Description** Netty is a network application framework for developing protocol servers and clients. A flaw exists where the handler processes non-complete SctpMessage fragments by executing `fragments.put(streamId, Unpooled.wrappedBuffer(frag, byteBuf))`, which wraps the previous accumulator and the new slice into a new CompositeByteBuf each time. This creates an N-deep chain of composites after N fragments, causing `readableBytes()` and `getBytes()` functions to recurse N levels. Because there is no limit on the number of fragments, total bytes, or the number of `streamId` identifiers an attacker can open, a peer that never sets the `complete` flag can grow this structure indefinitely using small 1-byte DATA chunks. **Recommendations** Update to version 4.1.135.Final. Update to version 4.2.15.Final.

**Name of the Vulnerable Software and Affected Versions** Netty versions prior to 4.1.135.Final Netty versions prior to 4.2.15.Final **Description** In the network application framework, `DefaultHttp2Connection.DefaultEndpoint` initializes `maxActiveStreams` and `maxStreams` to `Integer.MAX VALUE`, while `Http2Settings` does not insert `SETTINGS MAX CONCURRENT STREAMS` by default. If the application does not explicitly call `initialSettings().maxConcurrentStreams(n)`, the HTTP/2 server advertises and enforces no limit on concurrent streams. This allows a single TCP connection to create hundreds of thousands of long-lived stream objects, as each open stream allocates a `DefaultStream` object, `PropertyMap` slots, flow-controller state, and an `IntObjectHashMap` entry. This condition also enables Rapid-Reset amplification, where the lack of a low concurrent cap increases the workload on the backend. **Recommendations** Update to version 4.1.135.Final. Update to version 4.2.15.Final. As a temporary mitigation, explicitly call `initialSettings().maxConcurrentStreams(n)` to define a limit for concurrent streams.

**Name of the Vulnerable Software and Affected Versions** netty-codec-haproxy versions prior to 4.1.135.Final netty-codec-haproxy versions prior to 4.2.15.Final **Description** An issue exists when decoding a PP2 TYPE SSL TLV (Type-Length-Value) where the `readNextTLV()` function in `HAProxyMessage` calls `header.retainedSlice(header.readerIndex(), length)` before reading the 1-byte client field and 4-byte verify field. If the TLV length is set below 5, the subsequent `readByte` or `readInt` operations trigger an IndexOutOfBoundsException. Because `HAProxyMessageDecoder` only handles `HAProxyProtocolException` during this process, the IndexOutOfBoundsException propagates, preventing the retained slice on the pooled cumulation buffer from being released. **Recommendations** Update to version 4.1.135.Final. Update to version 4.2.15.Final.

**Name of the Vulnerable Software and Affected Versions** Netty (ionettyincubatorcodecquic) (affected versions not specified) **Description** The `NoQuicTokenHandler` component fails to properly validate tokens when no specific token handler is set by the application. Specifically, the `validateToken()` function unconditionally returns 0, which the `QuicheQuicServerCodec.handlePacket()` function interprets as a valid token. This allows an attacker to spoof a victim's source IP address and include any non-empty token bytes in an Initial packet. Consequently, the server treats the victim's address as validated, bypassing the 3x anti-amplification send limit defined in RFC 9000 §8.1. This enables the server to reflect full-size handshake flights, such as certificates, toward the victim without the standard amplification restrictions. **Recommendations** At the moment, there is no information about a newer version that contains a fix for this vulnerability.

**Name of the Vulnerable Software and Affected Versions** Netty (ionetty:netty-handler) (affected versions not specified) **Description** An uncontrolled memory allocation issue exists in the `SslClientHelloHandler.decode()` function. When a ClientHello does not fit in the first record, the system eagerly allocates memory using `ctx.alloc().buffer(handshakeLength)` based on the 24-bit TLS handshake length. Because the `SniHandler`, `AbstractSniHandler`, and related constructors often set `maxClientHelloLength` and `handshakeTimeoutMillis` to 0, the length guard is disabled and no timeout is scheduled. Consequently, a request of 16 MiB or larger exceeds the default pooled chunk size, resulting in an immediate huge or unpooled allocation that is retained until the channel closes. **Recommendations** At the moment, there is no information about a newer version that contains a fix for this vulnerability.

**Name of the Vulnerable Software and Affected Versions** Netty (affected versions not specified) **Description** A file descriptor leak occurs in the `netty unix socket recvFd` function when a peer sends two file descriptors simultaneously via an SCM RIGHTS control message. The system allocates a control buffer of 24 bytes on 64-bit Linux, which exactly fits a control message containing two integers. Because the kernel installs both descriptors without triggering a `MSG CTRUNC` flag, a subsequent length check `cmsg->cmsg len == CMSG LEN(sizeof(int))` fails as it expects 20 bytes. This causes the application to skip the logic that reads the descriptor and fails to close the installed descriptors. The process then exits the read loop normally, resulting in two leaked file descriptors per message. This issue is reachable via `Epoll`/`KQueue` `DomainSocketChannel` when the application is configured with `DomainSocketReadMode.FILE DESCRIPTORS`. **Recommendations** At the moment, there is no information about a newer version that contains a fix for this vulnerability.

**Name of the Vulnerable Software and Affected Versions** Netty versions up to and including 4.1.118.Final **Description** The issue is related to an unsafe reading of environment files, which could potentially cause a denial of service in Netty. When loaded on a Windows application, Netty attempts to load a file that does not exist. If an attacker creates a large file, the Netty application may crash. A similar issue was previously reported, but the fix was incomplete, as null-bytes were not counted against the input limit. The vulnerability is related to the `BufferedReader.readLine()` function and the `InputStreamReader`, which can fill up the line-buffer with replacement characters when encountering null-bytes. **Recommendations** For Netty versions up to and including 4.1.118.Final, consider updating to a version that includes the complete fix for this issue, as the current fix is incomplete. As a temporary workaround, consider restricting access to the vulnerable `BufferedReader.readLine()` function or the `InputStreamReader` to minimize the risk of exploitation. Additionally, avoid using the `InputStreamReader` with files that may contain null-bytes, as this can trigger the vulnerability. At the moment, there is no information about a newer version that contains a fix for this vulnerability.