CVE-2026-93572 in Apache Camel
Summary
by MITRE • 09/18/2026
## 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
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 09/18/2026
The vulnerability in RedisArrayAggregator stems from an eager memory allocation strategy that fails to account for the cumulative impact of deeply nested array headers, leading to a significant resource exhaustion risk. Although recent updates introduced limits on maximum elements and nesting depth to mitigate public advisories regarding Redis resource consumption, these safeguards operate independently without considering the compounding effect of allocating large arrays at each level of recursion. Specifically, when decoding RESP protocol data, the system instantiates an ArrayList with a capacity equal to the declared length of every nested array header before any actual child elements are processed or validated for existence. This design choice means that even if the final payload is minimal or non-existent beyond the headers themselves, the JVM allocates substantial backing memory based solely on the metadata provided by the attacker-controlled input.
In a practical attack scenario, an adversary can exploit this behavior by sending nested RESP array structures where each level declares a large length value, such as one million elements. Given that the default maximum nesting depth is set to 1024 levels, an attacker can trigger the allocation of over one billion child slots across these nested layers. This results in approximately one gigabyte of heap memory being reserved from a relatively small network payload of roughly twelve kilobytes. The critical flaw lies in the fact that ArrayList(int) constructor creates an empty list with the specified initial capacity, meaning this massive amount of virtual memory is committed immediately upon parsing the header, long before any validation checks on the actual content or subsequent depth limits can prevent the allocation. This discrepancy between logical size and physical backing capacity allows for a highly efficient denial-of-service attack that consumes server resources disproportionately to the network bandwidth used.
From a classification perspective, this vulnerability aligns with CWE-789: Memory Allocation with Externally Controlled Value, as the system allocates memory based on untrusted input without sufficient bounds checking relative to available resources. Furthermore, it relates to CWE-400: Uncontrolled Resource Consumption, specifically manifesting as resource exhaustion through inefficient allocation patterns rather than infinite loops or direct overflow attacks. In terms of MITRE ATT&CK mapping, this technique corresponds to T1496: Resource Hijacking, where the attacker aims to consume computational resources such that legitimate processes are degraded or halted due to memory pressure. The lack of lazy initialization or capacity capping during the parsing phase means that the system becomes vulnerable even if subsequent logic attempts to enforce limits on total element count, as the damage is done at the point of header decoding.
To mitigate this vulnerability, developers must modify the allocation strategy within the RedisArrayAggregator class to avoid eager instantiation of large arrays based solely on declared lengths. Implementing lazy initialization or setting a strict upper bound on the initial capacity regardless of the header value would prevent the excessive memory reservation described above. Additionally, the validation logic should consider the cumulative impact of nested allocations rather than treating depth and element count as isolated constraints. It is also advisable to implement global heap usage monitoring that can trigger early termination if allocated memory exceeds a safe threshold relative to available system resources. Regular security audits focusing on parsing libraries in high-throughput environments are essential to identify similar patterns where metadata-driven allocation outpaces actual data processing capabilities, ensuring resilience against sophisticated resource exhaustion attacks.