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
6 actionable advisories, newest first. Withdrawn advisories and news are excluded. Coverage is partial.
RedisArrayAggregator clears retained partial aggregate state when the maxNestedArrayDepth limit is exceeded, but it does not clear the same state when the sibling maxElements limit is exceeded. A peer can start a valid RESP array, send a bulk-string child, then send a nested array header longer than the configured maxElements. Netty throws a decoder exception, but the existing partial aggregate remains retained in the handler. If the application leaves the channel alive after the exception, later messages are still consumed into the pre-error aggregate. The supplied PoV proves both the retained ByteBuf reference and the stale parser state continuation. Technical Details RedisArrayAggregator.decode(...) retains non-array messages before adding them to depths.peek().children. In decodeRedisArrayHeader(...), the header.length() maxElements branch throws immediately: The immediately following nested-depth branch clears retained aggregate state before throwing: The missing cleanup…
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.
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. Details The aggregator starts a new aggregation level when it receives an ArrayHeaderRedisMessage. For positive lengths it pushes AggregateState, whose constructor runs new ArrayList<(length). No configurable maximum is applied in this handler, and the peer does not need to supply the array elements for the backing array allocation to occur. In the same pipeline, RedisDecoder enforces RedisConstants.REDISMESSAGEMAXLENGTH for bulk string lengths but does not apply that cap to array header lengths. Declared array sizes can therefore be extremely large while still passing decoding, and the aggregator immediately attempts Object[] reservation. io.netty.handler.codec.redis.RedisDecoder#decodeLength…
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.
Impact 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.
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.
An attacker can cause DoS by sending crafted Redis payloads across multiple connections without \r\n. This exhausts the server's direct memory pool (OutOfDirectMemoryError), preventing legitimate connections from being processed. Details io.netty.handler.codec.redis.RedisDecoder decodes the length of bulk strings and array headers using the decodeLength method. This method reads bytes from the network until it encounters a \n character. However, it does not enforce any maximum length check while buffering the bytes if the \n character is not found. An attacker can exploit this by sending a continuous stream of digits (e.g., $1111...) without ever sending a \n. To cause a true Denial of Service, an attacker must open multiple concurrent connections and distribute the unbounded payloads among them. According to the RESP specification (https://redis.io/docs/latest/develop/reference/protocol-spec/), all parts of the protocol are strictly terminated with \r\n. Furthermore, the…
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.
An attacker can cause DoS by sending a crafted Redis payload with deeply nested arrays. This forces the server to allocate a massive number of state objects and collections, leading to memory exhaustion and an OutOfMemoryError. Details io.netty.handler.codec.redis.RedisArrayAggregator aggregates RedisMessage parts into ArrayRedisMessage. It uses a Deque<AggregateState to keep track of nested arrays. However, it does not limit the maximum depth of nested arrays. When an attacker sends a continuous stream of nested array headers (e.g., 1\r\n1\r\n1\r\n...), RedisArrayAggregator pushes a new AggregateState onto the stack and allocates a new ArrayList for each header. Because there is no depth limit, an attacker can send millions of such headers. This consumes a massive amount of heap memory for the AggregateState instances and their backing ArrayLists, eventually resulting in an OutOfMemoryError. Impact Denial of Service due to memory exhaustion. Any application using Netty's…
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.
Security Vulnerability Report: CRLF Injection in Netty Redis Codec Encoder 1. Vulnerability Summary | Field | Value | |-------|-------| | Product | Netty | | Version | 4.2.12.Final (and all prior versions with codec-redis) | | Component | io.netty.handler.codec.redis.RedisEncoder | | Vulnerability Type | CWE-93: Improper Neutralization of CRLF Sequences (CRLF Injection) | | Impact | Redis Command Injection / Response Poisoning | | Attack Vector | Network | | Attack Complexity | Low | | Privileges Required | None | | User Interaction | None | | Scope | Unchanged | | Confidentiality Impact | High | | Integrity Impact | High | | Availability Impact | None | 2. Affected Components The following classes in the codec-redis module are affected: - io.netty.handler.codec.redis.RedisEncoder (encoder - no output validation) - io.netty.handler.codec.redis.InlineCommandRedisMessage (no input validation) - io.netty.handler.codec.redis.SimpleStringRedisMessage (no input validation) -…
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.