Vulnerabilities

Netty versions 4.1.133.Final through 4.1.137.Final and 4.2.13.Final through 4.2.17.Final fail to correctly validate the final transfer coding in the HTTP Transfer-Encoding header (CWE-444, inconsistent interpretation of HTTP requests). An attacker triggers the flaw by sending a request whose Transfer-Encoding header is split across multiple lines or contains malformed values such as 'chunked, xchunked', causing Netty to decode the message as chunked even though the final coding is not chunked. This creates a desynchronization between front-end proxies and the Netty-based backend, enabling request smuggling that can bypass access controls, poison caches, or interfere with other users' requests (low confidentiality and integrity impact per the CVSS 4.0 score of 6.9). Any application or product embedding an affected Netty version is affected, including consumers of frameworks and servers that bundle Netty. Exploitation has not been confirmed in the wild (not in CISA KEV, EPSS 0.2%), but the technique is publicly documented in the vendor advisory GHSA-hcvj-94mj-jp5c.

Do: Upgrade Netty to the first release after 4.1.137.Final on the 4.1 branch and after 4.2.17.Final on the 4.2 branch (fixed versions are listed in advisory GHSA-hcvj-94mj-jp5c), and audit transitive dependencies with 'mvn dependency:tree' or 'gradle dependencies' since most exposure comes via frameworks that bundle Netty. Until patched, configure any front-end proxy in front of Netty services to reject ambiguous Transfer-Encoding headers (duplicated, split across lines, or containing unrecognized codings) so the proxy and backend cannot desync.

Netty (io.netty:netty-codec-socks) versions 4.2.0.Final through 4.2.16.Final and 4.1.x through 4.1.136.Final contain null byte, CRLF, and credential injection vulnerabilities in the SOCKS4 (Socks4ClientEncoder) and SOCKS5 (Socks5ClientEncoder) client encoders, which fail to validate domain address and authentication (username/password) fields. An attacker able to control these fields can inject null bytes or CRLF characters to truncate or alter values, potentially enabling domain spoofing, SOCKS4 userid truncation, authentication data injection, and protocol confusion. Fixed in 4.2.17.Final and 4.1.137.Final.

Netty is an asynchronous, event-driven network application framework. Prior to versions 4.1.136.Final and 4.2.16.Final, the `Bzip2Decoder` handler in Netty's compression codec pipeline is vulnerable to a denial-of-service attack through a malformed bzip2 stream that permanently captures the event-loop thread in an infinite loop. The vulnerability exists in the run-length encoding (RLE) state machine within [`Bzip2BlockDecompressor.read()`]. This issue has been fixed in versions 4.1.136.Final and 4.2.16.Final.

Netty is an asynchronous, event-driven network application framework. Prior to versions 4.1.136.Final and 4.2.16.Final, HttpPostRequestEncoder constructs multipart HTTP request bodies by directly concatenating user-supplied filenames and field names into Content-Disposition MIME headers without validating or sanitizing CRLF characters (\r\n). Since MIME headers are delimited by CRLF, an attacker who controls the filename can inject arbitrary MIME headers into the multipart body part. The root cause is that neither the encoder nor the FileUpload implementations' setFilename() methods, which only check for null, neutralize CRLF characters before the filename is embedded into the header. This issue has been fixed in versions 4.1.136.Final and 4.2.16.Final.

Netty is a network application framework for development of protocol servers and clients. In versions 4.2.0.Final through 4.2.15.Final and prior to 4.1.135.Final, `OcspClient` does not validate that the `CertificateID` in an OCSP response matches the requested `CertificateID`, which can lead to replay attack. `OcspClient.validateResponse` accepts a legitimately signed `GOOD` status response for an unrelated certificate issued by the same CA, allowing bypass of revocation checks for another certificate. This issue is fixed in versions 4.1.136.Final and 4.2.16.Final.

Netty is a network application framework for development of protocol servers and clients. Prior to 4.1.136.Final and 4.2.16.Final, io.netty.handler.codec.stomp.StompSubframeDecoder fails to limit the total number of headers or their cumulative size per frame, and the maxLineLength parameter only restricts individual header lines. An attacker can send a large number of short headers that are accumulated in memory inside DefaultStompHeadersSubframe until the JVM throws an OutOfMemoryError, causing denial of service for servers exposing a STOMP endpoint based on StompSubframeDecoder. This issue is fixed in versions 4.1.136.Final and 4.2.16.Final.