Open actionable advisories and recorded vendor fixes. This public package view has no inventory attached and cannot establish whether your deployment is affected. A vendor fix never resolves your finding; verify your installed version and the source guidance.
Open advisories
21 actionable advisories, newest first. Withdrawn advisories and news are excluded. Coverage is partial.
Netty's CorsHandler silently overwrites existing Vary headers, enabling cache poisoning and sensitive information disclosure. Details io.netty.handler.codec.http.cors.CorsHandler#setVaryHeader overwrites any existing Vary headers set by backend applications. Because set() replaces all existing values for the header, if a backend application sets a Vary header (such as Vary: Authorization or Vary: Cookie) to ensure that intermediate caches (like CDNs) cache responses separately per user, the CorsHandler will overwrite it with Vary: origin. This causes the caching proxy to ignore the authorization context and cache the response based solely on the URL and Origin, allowing an attacker to retrieve another user's cached sensitive data. Impact This is a Cache Poisoning vulnerability that leads to Information Disclosure. It impacts any Netty-based web application that uses the CorsHandler, sets its own Vary headers to manage caching of authenticated or user-specific responses (e.g.,…
Recommended action: Upgrade to 4.2.17.Final or 4.1.137.Final by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Security Vulnerability Report: CRLF Injection via Multipart Filename in Netty HttpPostRequestEncoder 1. Vulnerability Summary | Field | Value | |-------|-------| | Product | Netty | | Version | 4.2.12.Final (and all prior versions with codec-http multipart) | | Component | io.netty.handler.codec.http.multipart.HttpPostRequestEncoder | | Vulnerability Type | CWE-93: Improper Neutralization of CRLF Sequences / CWE-113: HTTP Response Splitting | | Impact | MIME Header Injection / Content-Type Spoofing / XSS via Content-Disposition | | CVSS 3.1 Score | 8.1 (High) | | CVSS 3.1 Vector | CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:N | | Attack Vector | Network | | Attack Complexity | Low | | Privileges Required | Low (attacker must be able to upload files with controlled filenames) | | User Interaction | None | | Scope | Unchanged | | Confidentiality Impact | High | | Integrity Impact | High | | Availability Impact | None | 2. Affected Components The following classes in the codec-http…
Recommended action: Upgrade to 4.2.16.Final or 4.1.136.Final by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact HttpContentEncoder (the superclass of the production handler HttpContentCompressor) maintains a per-channel ArrayDeque<CharSequence named acceptEncodingQueue that accumulates attacker-controlled data without any size limit. The queue is filled on the I/O thread for every inbound HTTP request and drained only when the application later writes a non-1xx response. This creates a resource exhaustion vulnerability when an attacker exploits HTTP/1.1 pipelining to flood the connection with requests faster than the application produces responses.
Recommended action: Upgrade to 4.2.16.Final or 4.1.136.Final by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
An attacker can force WebSocket upgrade via the lax V07 (or V08) handshaker by sending Sec-WebSocket-Version: 7 and omitting Connection: Upgrade / Upgrade: websocket headers, completing a protocol switch that a proxy would not recognize as an Upgrade request and enabling HTTP request smuggling / protocol-confusion attacks.
Recommended action: Upgrade to 4.2.16.Final or 4.1.136.Final by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Netty's CorsHandler provides a shortCircuit() configuration designed to reject unauthorized cross-origin requests immediately, acting as a security control before requests reach the application. However, due to a logical operator error in the origin evaluation process, this protection can be entirely bypassed. An attacker can bypass the short-circuit mechanism by sending a request with an Origin: null header. This failure forwards unauthorized requests to the backend application, bypassing intended access controls. Details In io.netty.handler.codec.http.cors.CorsHandler#channelRead, the short-circuit logic relies on the configuration returned by getForOrigin(origin) to determine if an origin is authorized. If getForOrigin returns a configuration object, the short-circuit check (!(origin == null || config != null)) is bypassed, and the request proceeds to the backend. The vulnerability is located in the getForOrigin method: If an attacker sends Origin: null,…
Recommended action: Upgrade to 4.2.16.Final or 4.1.136.Final by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
The SpdyHttpDecoder handler in Netty's SPDY-to-HTTP codec allocates a pooled ByteBuf when processing a client-initiated SYNSTREAM frame with FLAGFIN=0, storing the partially-constructed FullHttpRequest in an internal map (messageMap) to accumulate subsequent DATA frames. When the remote peer sends an RSTSTREAM for that stream, or when the accumulated content exceeds maxContentLength, the decoder removes the entry from the map but never releases the pooled ByteBuf, permanently leaking the allocated memory.
Recommended action: Upgrade to 4.2.16.Final or 4.1.136.Final by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Netty SPDY header decoding continues inflating zlib-compressed header blocks after the raw header parser has already exceeded maxHeaderSize and marked the frame truncated. At commit b2d2137c4404af425bf9d5d601a62576f5c06925, a 12,253-byte compressed SPDY header block can declare and inflate a 12 MiB header-name field with maxHeaderSize=16, forcing compression-amplified decode and skip work in a reachable SpdyFrameCodec pipeline. PoC poc.zip run with: expected output: The fingerprint means the compressed input was fully consumed while the raw header parser ended with truncated=true and invalid=false after processing the oversized decoded name. That specific state distinguishes this bug from a generic setup failure: the maxHeaderSize guard fired, but the zlib/raw decode path still inflated and skipped the full 12 MiB declared name. Impact A remote unauthenticated peer that can speak SPDY to a Netty pipeline containing SpdyFrameCodec can send a small compressed HEADERS block that…
Recommended action: Upgrade to 4.2.16.Final or 4.1.136.Final by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Netty's SPDY SETTINGS decoder accepts a peer-declared SETTINGS entry count up to the 24-bit frame-length limit and materializes every unique setting ID in DefaultSpdySettingsFrame without an implementation-level count cap. A remote SPDY/3.1 peer can send one syntactically valid roughly 2 MiB SETTINGS frame that creates 262144 map entries, amplifying network input into heap growth and ordered-map insertion work. Details Inbound SPDY bytes enter SpdyFrameCodec.decode() and are passed directly to the frame decoder. The decoder reads the peer-controlled flags and 24-bit frame length from the common header, then accepts SETTINGS frames with only length = 4. For SETTINGS payloads, it reads the peer-controlled numSettings field and validates only that the remaining payload is divisible into 8-byte entries and exactly matches that count. Each accepted entry then supplies an attacker-controlled 24-bit ID and value, and the normal delegate path forwards it into…
Recommended action: Upgrade to 4.2.16.Final or 4.1.136.Final by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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. Affected Code | File | Lines | Role | |------|-------|------| | codec-http/src/main/java/io/netty/handler/codec/http/HttpObjectDecoder.java | 1298–1313 | ISOCONTROLORWHITESPACE static initialiser — marks all ISO control chars | | codec-http/src/main/java/io/netty/handler/codec/http/HttpObjectDecoder.java | 1307–1313 | SKIPCONTROLCHARSBYTES ByteProcessor — skips the entire set | |…
Recommended action: Upgrade to 4.2.15.Final or 4.1.135.Final by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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. Details HttpContentDecompressor stores the maxAllocation value at construction time (HttpContentDecompressor.java:89) and uses it in newContentDecoder() to create the appropriate decompression handler. For gzip/deflate, maxAllocation is forwarded to ZlibCodecFactory.newZlibDecoder(): ZlibDecoder.prepareDecompressBuffer() enforces this as a hard cap by setting the buffer's…
Recommended action: Upgrade to 4.2.13.Final or 4.1.133.Final by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Netty incorrectly parses malformed Transfer-Encoding, enabling request smuggling attacks. Details Netty incorrectly marks a request as chunked when malformed "Transfer-Encoding: chunked, identity" is present. According to RFC https://datatracker.ietf.org/doc/html/rfc9112#name-message-body-length " If a Transfer-Encoding header field is present in a request and the chunked transfer coding is not the final encoding, the message body length cannot be determined reliably; the server MUST respond with the 400 (Bad Request) status code and then close the connection. " A possible scenario is when Netty is behind a proxy that doesn't reject requests with "Transfer-Encoding: chunked, identity", but prefers "Content-Length" and forwards the content to Netty. PoC The test below shows Netty successfully parsing the second request, demonstrating how an attacker can smuggle a second request inside a request body. Impact HTTP Request Smuggling: Attacker injects arbitrary HTTP requests
Recommended action: Upgrade to 4.2.13.Final or 4.1.133.Final by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
If HttpClientCodec is configured, there are use cases when a response body from one request, can be parsed as another's. Details 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. Prerequisites - HTTP/1.1 pipelining - HEAD in the pipeline - The server sends 1xx PoC Impact Integrity/availability of HTTP parsing on that connection, unsafe reuse of the socket.
Recommended action: Upgrade to 4.2.13.Final or 4.1.133.Final by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
NETTY HTTP/1.0 TE+CL Coexistence Bypasses Smuggling Sanitization | Field | Value | |-----------|-------| | Library | io.netty:netty-codec-http | | Component | codec-http — HttpObjectDecoder | | Severity | HIGH | | Affects | HEAD, commit 4f3533ae confirmed | --- Summary 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. --- Root Cause The conflict-resolution path is gated on message.protocolVersion() == HttpVersion.HTTP11. When the request declares HTTP/1.0, the condition is false,…
Recommended action: Upgrade to 4.2.13.Final or 4.1.133.Final by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Netty's chunk size parser silently overflows int, enabling request smuggling attacks. Details io.netty.handler.codec.http.HttpObjectDecoder#getChunkSize silently overflows int. The size is accumulated as follows: result = 16; result += digit; The result is checked only for negative values. However, with a carefully crafted chunk size, the result can be a valid size. PoC The test below shows Netty successfully parsing the second request, demonstrating how an attacker can smuggle a second request inside a chunked body. Impact HTTP Request Smuggling: Attacker injects arbitrary HTTP requests
Recommended action: Upgrade to 4.2.13.Final or 4.1.133.Final by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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 RTSP requests. In practice, this leads to HTTP request smuggling / desynchronization on the HTTP side and request injection on the RTSP side. Details The root issue is that URI validation exists only on the constructor path, but not on the public setter path. - io.netty.handler.codec.http.DefaultHttpRequest - The constructor calls HttpUtil.validateRequestLineTokens(method, uri) - setUri(String uri) only performs checkNotNull and does not validate -…
Recommended action: Upgrade to 4.2.13.Final or 4.1.133.Final by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Netty incorrectly parses quoted strings in HTTP/1.1 chunked transfer encoding extension values, enabling request smuggling attacks. Background This vulnerability is a new variant discovered during research into the "Funky Chunks" HTTP request smuggling techniques: - <https://w4ke.info/2025/06/18/funky-chunks.html - <https://w4ke.info/2025/10/29/funky-chunks-2.html The original research tested various chunk extension parsing differentials but did not cover quoted-string handling within extension values. Technical Details RFC 9110 Section 7.1.1 defines chunked transfer encoding: RFC 9110 Section 5.6.4 defines quoted-string: Critically, the allowed character ranges within a quoted-string are: CR (%x0D) and LF (%x0A) bytes fall outside all of these ranges and are therefore not permitted inside chunk extensions—whether quoted or unquoted. A strictly compliant parser should reject any request containing CR or LF bytes before the actual line terminator within a chunk extension with…
Recommended action: Upgrade to 4.2.10.Final or 4.1.132.Final by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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. Details The HttpRequestEncoder simply UTF8 encodes the uri without sanitization (buf.writeByte(SP).writeCharSequence(uriCharSequence, CharsetUtil.UTF8);) The default implementation of HTTP headers guards against such possibility already with a validator making it impossible with headers. PoC Simple reproducer: Impact Any application / framework using HttpRequestEncoder can be subject to be abused to perform request smuggling using CRLF injection.
Recommended action: Upgrade to 4.2.8.Final or 4.1.129.Final by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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. Details When encountering a newline character (LF) while parsing a chunk extension, netty interprets the newline as the end of the chunk-size line regardless of whether a preceding carriage return (CR) was found. This is in violation of the HTTP 1.1 standard which specifies that the chunk extension is terminated by a CRLF sequence (see the RFC). This is by itself harmless, but consider an intermediary with a similar parsing flaw: while parsing a chunk extension, the intermediary interprets an LF without a preceding CR as simply part of the chunk extension (this is also in violation of the RFC, because whitespace characters are not allowed in chunk extensions). We can use this discrepancy to construct an HTTP request that the intermediary will interpret as one request but netty will interpret as two (all lines ending with…
Recommended action: Upgrade to 4.2.5.Final or 4.1.125.Final by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
The HttpPostRequestDecoder can be tricked to accumulate data. I have spotted currently two attack vectors Details 1. While the decoder can store items on the disk if configured so, there are no limits to the number of fields the form can have, an attacher can send a chunked post consisting of many small fields that will be accumulated in the bodyListHttpData list. 2. The decoder cumulates bytes in the undecodedChunk buffer until it can decode a field, this field can cumulate data without limits PoC Here is a Netty branch that provides a fix + tests : https://github.com/vietj/netty/tree/post-request-decoder Here is a reproducer with Vert.x (which uses this decoder) https://gist.github.com/vietj/f558b8ea81ec6505f1e9a6ca283c9ae3 Impact Any Netty based HTTP server that uses the HttpPostRequestDecoder to decode a form.
Recommended action: Upgrade to 4.1.108.Final or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact When calling DefaultHttpHeaders.set with an iterator of values (as opposed to a single given value), header value validation was not performed, allowing malicious header values in the iterator to perform HTTP Response Splitting. Patches The necessary validation was added in Netty 4.1.86.Final. Workarounds Integrators can work around the issue by changing the DefaultHttpHeaders.set(CharSequence, Iterator<?) call, into a remove() call, and call add() in a loop over the iterator of values. References HTTP Response Splitting CWE-113: Improper Neutralization of CRLF Sequences in HTTP Headers For more information If you have any questions or comments about this advisory: Open an issue in example link to repo Email us at netty-security@googlegroups.com
Recommended action: Upgrade to 4.1.86.Final or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
GHSA-5mcr-gq6c-3hq2 (CVE-2021-21290) contains an insufficient fix for the vulnerability identified. Impact 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. This only impacts applications running on Java version 6 and lower. Additionally, this vulnerability impacts code running on Unix-like systems, and very old versions of Mac OSX and Windows as they all share the system temporary directory between all users. Vulnerability Details To fix the vulnerability the code was changed to the following: Unfortunately, this logic path was left vulnerable: This file is still readable by all local users. Patches Update to 4.1.77.Final Workarounds Specify your own java.io.tmpdir when you start the JVM or use DefaultHttpDataFactory.setBaseDir(...) to set the directory to something that is only readable by the current user or update to Java 7 or…
Recommended action: Upgrade to 4.1.77.Final or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.