Description

Netty is an asynchronous, event-driven network application framework. Prior to 4.1.136.Final and 4.2.16.Final, the RedisArrayAggregator Redis codec 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 in decodeRedisArrayHeader, 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, allowing an unauthenticated peer to keep attacker-controlled aggregate state alive across a security-limit exception and pin retained pooled buffers. This issue is fixed in versions 4.1.136.Final and 4.2.16.Final.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "6.5",
  "pubDate": "2026-08-07T18:17:19.100Z",
  "pubdate": "2026-08-07T18:17:19.100Z",
  "executiveSummary": "An improper state cleanup vulnerability exists in the RedisArrayAggregator Redis codec within the Netty asynchronous event-driven network application framework. The vulnerability allows an unauthenticated remote peer to exploit error-handling logic when processing RESP arrays containing sibling elements that exceed configured security limits. Specifically, while Netty correctly clears retained partial aggregate state when the maxNestedArrayDepth limit is exceeded, it fails to perform the same cleanup operation when the maxElements limit is violated. When decodeRedisArrayHeader throws a decoder exception, the partial aggregate remains retained within the handler instance. If the affected application maintains the network channel in an active state following the exception, subsequent incoming messages continue to be consumed into the pre-error aggregate buffer. This behavior enables unauthenticated attackers to preserve attacker-controlled aggregate state across security-limit exceptions, resulting in pinned pooled buffers and potential resource exhaustion. The vulnerability affects Netty versions prior to 4.1.136.Final and 4.2.16.Final, and exploitation requires the ability to send network traffic to an exposed Netty-based Redis codec endpoint that leaves channels open after encountering decoder exceptions.",
  "technicalDetails": "The vulnerability resides in the RedisArrayAggregator component of Netty's Redis codec implementation. Netty provides asynchronous networking primitives and protocol decoders, including parsers for the Redis Serialization Protocol (RESP). The RedisArrayAggregator is responsible for aggregating RESP arrays and nested array structures up to configured boundaries, specifically controlled by the maxNestedArrayDepth and maxElements safety limits designed to prevent resource exhaustion and excessive memory consumption.\nThe root cause of the vulnerability is an asymmetric state management flaw during validation exception handling. When a peer attempts to violate the maxNestedArrayDepth threshold, the decoder correctly identifies the limit breach, throws a decoder exception, and clears the retained partial aggregate state to ensure subsequent data is not appended to corrupted structures. However, when a peer exceeds the sibling maxElements limit, the decodeRedisArrayHeader function similarly throws a decoder exception, but the implementation fails to clear the corresponding retained partial aggregate state in the handler.\nThe attack flow proceeds as follows: an unauthenticated remote peer initiates a connection to a vulnerable Netty-based service utilizing the Redis codec and starts a valid RESP array. The peer then sends a bulk string child followed by a nested array header containing a number of elements that exceeds the configured maxElements security limit. Upon processing this oversized header, Netty detects the violation, throws a decoder exception via decodeRedisArrayHeader, and halts normal parsing of that specific frame. Because the handler fails to clear the partial aggregate state, the internal state machine retains the partially constructed aggregate buffer.\nIf the vulnerable application architecture leaves the network channel alive after catching the decoder exception rather than immediately terminating the connection, subsequent messages sent over the same channel are still consumed into the pre-error aggregate state. This payload behavior allows an unauthenticated attacker to keep attacker-controlled aggregate state alive across security-limit exceptions, effectively pinning retained pooled buffers in memory. The post-exploitation impact includes memory leaks, resource exhaustion, and potential denial-of-service conditions through the continuous retention and allocation of pooled direct or heap buffers within Netty's buffer allocator framework.\nThe vulnerable component is the RedisArrayAggregator within Netty. Affected software versions include all Netty releases prior to 4.1.136.Final and 4.2.16.Final. Exploitation requires network exposure of the Netty application service and the ability to send malformed or limit-exceeding RESP payloads over an active TCP or network channel where connections are not forcefully closed upon decoder exceptions."
}