CVE-2026-93572: Netty: netty-codec-redis: io.netty/netty-codec-redis: netty: redisarrayaggregator nested resp headers multiply patched preallocation limits
Summary RedisArrayAggregator recently added maxElements and maxNestedArrayDepth limits to fix public Redis resource-exhaustion advisories. The limits are independent, but the allocator remains eager: every positive nested RESP array header creates new ArrayList<RedisMessage>(length) before any child element exists. With the default constructor, an attacker can send nested array headers with length 1,000,000 until the default nesting limit of 1024 is reached. This can reserve up to 1,024,000,000 child slots from roughly 12 KB of RESP input. This is backing capacity, not logical list size: ArrayList(int) constructs an empty list with the specified initial capacity. Technical Details Current decodeRedisArrayHeader(...) checks the two limits independently: java if (header.length() > maxElements) { throw new CodecException("this codec doesn't support longer length than " + maxElements); } if (depths.size() >= maxNestedArrayDepth) { releaseAndClearDepths(); throw new CodecException("max nested array depth exceeded: " + maxNestedArrayDepth); } depths.push(new AggregateState((int) header.length())); AggregateState i
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
netty-codec-redis (io.netty:netty-codec-redis)to a version that resolves this vulnerability.Fixed in 4.2.15.FinalPatch GHSA-5w86-c3rq-vjj7 - Upgrade
Upgrade
netty-codec-redis (io.netty:netty-codec-redis)to a version that resolves this vulnerability.Fixed in 4.1.135.FinalPatch GHSA-5w86-c3rq-vjj7 - Upgrade
Upgrade
netty-codec-redis (io.netty:netty-codec-redis)to a version that resolves this vulnerability.Fixed in 4.2.15.FinalPatch GHSA-3244-j874-rhc2 - Upgrade
Upgrade
netty-codec-redis (io.netty:netty-codec-redis)to a version that resolves this vulnerability.Fixed in 4.1.135.FinalPatch GHSA-3244-j874-rhc2
Event History
Frequently Asked Questions
Is the default configuration affected?
Yes. With the default constructor, nested RESP array headers can be accepted up to the default nesting limit of 1,024, and each positive-length header can eagerly allocate backing capacity.
What does an attacker need to send to trigger excessive allocation?
An attacker can send nested RESP array headers with a declared length of 1,000,000. The headers do not need child elements to cause allocation, because each positive nested header creates an ArrayList with the declared initial capacity.
How large can the allocation be relative to the request size?
Up to 1,024 nested headers with a length of 1,000,000 can reserve up to 1,024,000,000 child slots. The described input needed to reach this condition is roughly 12 KB of RESP data.
Do the existing element-count and nesting-depth limits prevent this behavior?
No. The limits are checked independently, so an array length that is within maxElements can still be used at every permitted nesting level, causing repeated eager preallocation.