`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
Analysis
Analysis and contextual insights are available on OpenCVE Cloud.
Default status is the baseline for the product, each version can override it (e.g. patched versions marked unaffected).
| Vendor | Product | Default status | Versions |
|---|---|---|---|
| Red Hat | Red Hat build of Apache Camel for Spring Boot 4 | affected | — |
| Red Hat | Red Hat Fuse 7 | affected | — |
| Red Hat | Red Hat JBoss Enterprise Application Platform 7 | affected | — |
| Red Hat | Red Hat JBoss Enterprise Application Platform 7 | affected | — |
| Red Hat | Red Hat JBoss Enterprise Application Platform 7 | affected | — |
| Red Hat | Red Hat JBoss Enterprise Application Platform 7 | affected | — |
| Red Hat | Red Hat Single Sign-On 7 | affected | — |
No data.
No data.
No data available yet.
Vendor Workaround
See https://github.com/netty/netty/security/advisories/GHSA-r4xx-7fpg-j8xg for fixed versions and remediation guidance.
Tracking
Sign in to view the affected projects.
No advisories yet.
Fri, 18 Sep 2026 13:45:00 +0000
| Type | Values Removed | Values Added |
|---|---|---|
| Title | Netty: netty-codec-redis: io.netty/netty-codec-redis: netty: redisarrayaggregator nested resp headers multiply patched preallocation limits | Io.netty/netty-codec-redis: netty: redisarrayaggregator nested resp headers multiply patched preallocation limits |
Fri, 18 Sep 2026 13:15:00 +0000
| Type | Values Removed | Values Added |
|---|---|---|
| Metrics |
cvssV3_1
|
Fri, 18 Sep 2026 11:00:00 +0000
| Type | Values Removed | Values Added |
|---|---|---|
| Description | ## 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 | |
| Title | Netty: netty-codec-redis: io.netty/netty-codec-redis: netty: redisarrayaggregator nested resp headers multiply patched preallocation limits | |
| First Time appeared |
Redhat
Redhat camel Spring Boot Redhat jboss Enterprise Application Platform Redhat jboss Fuse Redhat red Hat Single Sign On |
|
| Weaknesses | CWE-770 | |
| CPEs | cpe:/a:redhat:camel_spring_boot:4 cpe:/a:redhat:jboss_enterprise_application_platform:7 cpe:/a:redhat:jboss_fuse:7 cpe:/a:redhat:red_hat_single_sign_on:7 |
|
| Vendors & Products |
Redhat
Redhat camel Spring Boot Redhat jboss Enterprise Application Platform Redhat jboss Fuse Redhat red Hat Single Sign On |
|
| References |
|
MITRE
Status: PUBLISHED
Assigner: redhat
Published:
Updated: 2026-09-18T13:32:55.440Z
Reserved: 2026-09-18T10:29:10.414Z
Link: CVE-2026-93572
Vulnrichment
No data.
NVD
Status : Received
Published: 2026-09-18T11:17:21.900
Modified: 2026-09-18T13:18:39.030
Link: CVE-2026-93572
Redhat
No data.
OpenCVE Enrichment
No data.
-
CWE-770
Allocation of Resources Without Limits or Throttling