Listen to this Post
When a Netty server processes a Redis client connection, it parses incoming data using the RESP (REdis Serialization Protocol) codec. This vulnerability (CVE-2026-50011) arises specifically within the `RedisArrayAggregator` component, which is responsible for reassembling RESP arrays from fragmented network packets.
The flaw triggers when the aggregator receives an ArrayHeaderRedisMessage. This message contains a declared length, which tells the decoder how many elements the upcoming array will hold. The problem is that the code blindly trusts this attacker-controlled number. For any positive length, the aggregator executes the constructor: new ArrayList<>(length).
This single line of code attempts to pre‑allocate an `Object[]` array of the requested size. However, the aggregator applies no configurable maximum to this value, and more importantly, the `RedisDecoder` pipeline stage does not enforce its length limit (RedisConstants.REDIS_MESSAGE_MAX_LENGTH) on array headers. The limit is only enforced on bulk string lengths. Consequently, an attacker can send a tiny malicious header—for example, 2147483647\r\n—which claims a massive array size (over 2 billion) but contains almost no actual data.
Because the length is trusted before any child messages are received, the JVM immediately attempts to allocate a contiguous block of memory sufficient to hold that many object references. On a typical 64‑bit JVM, each reference consumes ~8 bytes, meaning a single such header could request over 16 GB of heap memory. If the server has insufficient memory, an `OutOfMemoryError` crashes the JVM instantly. Even if memory is available, the allocation itself will block the event loop, making the entire server unresponsive. Additionally, an attacker can open multiple connections and send multiple such headers simultaneously, compounding the resource exhaustion attack.
This vulnerability was assigned CVE-2026-50011 and carries a High severity rating (CVSS 7.5). The issue affects Netty versions `4.2.0.Final` through `4.2.14.Final` and versions `4.1.134.Final` and earlier. It was patched in releases `4.2.15.Final` and 4.1.135.Final.
DailyCVE Form:
Platform: Netty codec-redis
Version: ≤4.1.134 / 4.2.0-14
Vulnerability : Pre‑allocation DoS
Severity: High (7.5)
date: 2026-06-15
Prediction: Already patched (Jun 5)
(end of form)
What Undercode Say:
Check if your project uses a vulnerable version of netty-codec-redis grep -r "netty-codec-redis" pom.xml 2>/dev/null || grep -r "netty-codec-redis" build.gradle 2>/dev/null For Maven, verify the version in the dependency tree mvn dependency:tree | grep netty-codec-redis For Gradle ./gradlew dependencies | grep netty-codec-redis If the version is ≤4.1.134.Final or 4.2.0.Final–4.2.14.Final, the application is vulnerable
The following diff shows the exact vulnerable code path in `RedisArrayAggregator.decodeRedisArrayHeader()` (pseudo‑code based on the advisory):
// Vulnerable (pre‑4.1.135.Final / pre‑4.2.15.Final)
if (length > 0) {
AggregateState state = new AggregateState(length); // calls new ArrayList<>(length)
stack.push(state);
}
// Patched (4.1.135.Final / 4.2.15.Final)
if (length > 0) {
// enforce a configurable maximum array length
if (length > maxArrayLength) {
throw new RedisCodecException("Array length exceeds limit: " + length);
}
AggregateState state = new AggregateState(length);
stack.push(state);
}
Exploit:
A single malicious RESP array header forces immediate pre‑allocation of an enormous ArrayList. The following packet demonstrates the attack:
echo -e "2147483647\r\n" | nc -v target_host 6379
If the target server runs a vulnerable Netty version, the event loop thread will block while trying to allocate an array of 2,147,483,647 objects. In most JVM configurations, this triggers an `OutOfMemoryError` and terminates the process. An attacker can repeat this across many concurrent connections to saturate memory even if a single allocation does not crash the server outright. This exploit requires no prior authentication and only a few bytes of network traffic, making it extremely dangerous for any public‑facing Redis endpoint built on Netty.
Protection:
- Immediate Upgrade: Update to Netty 4.1.135.Final or 4.2.15.Final (or any later version). These versions enforce a configurable maximum on RESP array lengths.
- Network Layer Filtering: Restrict access to the Redis port to trusted networks only. Use firewall rules (e.g.,
iptables, cloud security groups) to prevent untrusted IPs from connecting. - Configuration: If you cannot upgrade immediately, implement a custom channel handler that validates array headers before they reach
RedisArrayAggregator. However, upgrading is the only complete fix. - Monitoring: Deploy memory usage and GC metrics (e.g., Prometheus + Grafana) to detect sudden pre‑allocation spikes, and set up alerts for `OutOfMemoryError` occurrences.
Impact:
- Denial of Service (DoS): Unauthenticated remote attackers can crash the Java process or make it completely unresponsive by sending a single crafted packet.
- Event Loop Blocking: Even if an allocation does not cause an immediate crash, it will block the Netty event loop thread, preventing all other channels from processing any data (including legitimate traffic).
- Resource Exhaustion: Multiple concurrent attack connections can exhaust all available heap or direct memory, leading to allocation failures for all services running in the same JVM.
- Widespread Exposure: Any application that uses Netty’s `netty-codec-redis` module to handle untrusted Redis traffic is vulnerable, including Redis proxies, Redis Cluster clients, and any custom Redis‑based service.
🎯Let’s Practice Exploiting & Learn Patching For Free:
🎓 Live Courses & Certifications:
Join Undercode Academy for Verified Certifications
🚀 Request a Custom Project:
Secure, high-velocity infrastructure and disruptive technological engineering. Contact our engineering team for high-tier development and proprietary systems:
[email protected]
💎 Smart Architecture | 🛡️ Secure by Design | ⭐ Trusted by Thousands
Sources:
Reported By: github.com
Extra Source Hub:
Undercode
