Apache Camel EUVD-2026-82870

Requires the target application to use Netty's Redis codec (RedisArrayAggregator) constructed with the default constructor - i.e., the default nesting limit of 1024 and no tightened maxElements - and to feed attacker-reachable, untrusted RESP input into that decoder. Exploitation is unauthenticated and needs no user interaction (PR:N/UI:N), but is LIMITED to deployments that actually expose a Netty-based RESP/Redis-protocol parsing endpoint to untrusted clients; applications that override the limits with a stricter custom constructor, or never parse untrusted RESP, are not exposed. Impact is availability-only (heap exhaustion); no data is read or modified.

This is a genuine but bounded availability risk. The CVSS 3.1 vector (AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H, base 7.5) is internally consistent with the description: an unauthenticated remote attacker sends ~12 KB of crafted nested RESP array headers and forces up to ~1,024,000,000 ArrayList slots to be pre-allocated, an amplification attack causing memory-exhaustion DoS with no confidentiality or integrity impact. I agree with the 7.5 and the CWE-770 (allocation of resources without limits) classification. However, the real-world priority is lower than the raw score suggests: no EPSS score, no CISA KEV listing, and no public exploit are present in the input (no public exploit identified at time of analysis), and exploitation is gated on the host application actually using Netty's Redis codec with the default (untightened) maxElements/maxNestedArrayDepth and exposing the RESP decoder to untrusted input. Note the data covers only Red Hat's downstream products; the vulnerable class RedisArrayAggregator is a Netty component, so the true affected population is 'applications embedding the Netty Redis codec,' not Red Hat products alone - verify Netty upstream advisory for the fixed version, which is not provided here.

An attacker with network reach to a service that decodes untrusted RESP (Redis protocol) input via Netty's RedisArrayAggregator sends a small (~12 KB) stream of deeply nested array headers each declaring length 1,000,000, up to the default depth of 1024. The eager allocator reserves over a billion child slots before any element arrives, exhausting heap and causing an out-of-memory denial of service. No public exploit is identified in the provided data, but the technique is simple and fully described in the advisory.