Advisories for Maven/Io.netty/Netty-Codec-Http package

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 …

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. …

Netty incorrectly parses malformed Transfer-Encoding, enabling request smuggling attacks.

Netty's chunk size parser silently overflows int, enabling request smuggling attacks.

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.

If HttpClientCodec is configured, there are use cases when a response body from one request, can be parsed as another's.

Netty allows request-line validation to be bypassed when a DefaultHttpRequest or DefaultFullHttpRequest is created first and its URI is later changed via setUri(). The constructors reject CRLF and whitespace characters that would break the start-line, but setUri() does not apply the same validation. HttpRequestEncoder and RtspEncoder then write the URI into the request line verbatim. If attacker-controlled input reaches setUri(), this enables CRLF injection and insertion of additional HTTP or …

Netty incorrectly parses quoted strings in HTTP/1.1 chunked transfer encoding extension values, enabling request smuggling attacks.

The io.netty.handler.codec.http.HttpRequestEncoder CRLF injection with the request uri when constructing a request. This leads to request smuggling when HttpRequestEncoder is used without proper sanitization of the uri.

A flaw in netty's parsing of chunk extensions in HTTP/1.1 messages with chunked encoding can lead to request smuggling issues with some reverse proxies.

The HttpPostRequestDecoder can be tricked to accumulate data. I have spotted currently two attack vectors

Netty project is an event-driven asynchronous network application framework. In versions prior to 4.1.86.Final, when calling DefaultHttpHeadesr.set with an iterator of values, header value validation was not performed, allowing malicious header values in the iterator to perform HTTP Response Splitting. This issue has been patched in version 4.1.86.Final. Integrators can work around the issue by changing the DefaultHttpHeaders.set(CharSequence, Iterator<?>) call, into a remove() call, and call add() in a loop …

This advisory has been marked as a false positive.

This advisory has been marked as False Positive and moved to netty-common.

Netty is an asynchronous event-driven network application framework for rapid development of maintainable high performance protocol servers & clients. Netty skips control chars when they are present at the beginning / end of the header name. It should instead fail fast as these are not allowed by the spec and could lead to HTTP request smuggling. Failing to do the validation might cause netty to sanitize header names before it …

Netty is an open-source, asynchronous event-driven network application framework for rapid development of maintainable high performance protocol servers & clients. In Netty (io.netty:netty-codec-http2) Final there is a vulnerability that enables request smuggling. The content-length header is not correctly validated if the request only uses a single Http2HeaderFrame with the endStream set to to true. This could lead to request smuggling if the request is proxied to a remote peer and …

Netty is an open-source, asynchronous event-driven network application framework for rapid development of maintainable high performance protocol servers. There is a vulnerability on Unix-like systems involving an insecure temp file. When netty's multipart decoders are used local information disclosure can occur via the local system temporary directory if temporary storing uploads on the disk is enabled. On unix-like systems, the temporary directory is shared between all user. As such, writing …

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 an incorrect syntax, or might be interpreted as an "invalid fold."

HttpObjectDecoder.java in Netty allows a Content-Length header to be accompanied by a second Content-Length header, or by a Transfer-Encoding header.

Netty allows HTTP Request Smuggling because it mishandles Transfer-Encoding whitespace (such as a [space]Transfer-Encoding:chunked line) and a later Content-Length header.

Netty mishandles whitespace before the colon in HTTP headers (such as a Transfer-Encoding : chunked line), which leads to HTTP request smuggling.