Netty netty-codec-redis EUVD-2026-54558

Two conditions must both be true for exploitation to succeed. First, the target application must include the io.netty:netty-codec-redis artifact in its pipeline with RedisArrayAggregator configured - applications using Netty only for HTTP, WebSocket, or other codecs are entirely unaffected. Second, the application must keep the channel alive after receiving a CodecException from the Redis decoder rather than closing or replacing the channel; this is an explicit application-level decision, not a Netty default, and applications that correctly propagate codec exceptions to channel closure are immune even on vulnerable Netty versions. Authentication is not required at the codec level (CVSS PR:N); the attacker only needs TCP connectivity to the Netty port. Exploitation is bounded in impact to memory exhaustion and stale-aggregate state corruption - remote code execution is not indicated by the description or CVSS vector (no C impact, no scope change).

The CVSS 3.1 vector (AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:L, score 6.5) correctly characterises the attack as network-reachable and unauthenticated with low complexity. Real-world impact severity is highly conditional: the vulnerability is only exploitable if the application continues using the channel after receiving a CodecException from the Redis decoder. Applications that close or replace the channel on any codec error - the defensive pattern recommended by Netty's own exception-handling guidance - are not affected even on vulnerable versions. No EPSS score was provided in the input data, so probability-of-exploitation cannot be quantified numerically. The public PoC in the GHSA advisory lowers the bar for exploitation meaningfully, but the application-level precondition limits blast radius compared to a raw network-reachable flaw. The absence of Confidentiality impact (C:N) is consistent with the description; Integrity impact (I:L) reflects stale aggregate consuming legitimate post-error messages, and Availability impact (A:L) reflects pooled buffer exhaustion. No KEV listing, so active exploitation is not confirmed. This is a real operational risk for high-throughput Redis-codec deployments that implement connection-keep-alive semantics post-exception, not a theoretical concern.

An unauthenticated attacker with network access to a Netty Redis codec endpoint sends a crafted RESP sequence: a valid array header followed by a bulk-string child (which gets retained in the aggregator's depth stack), then a nested array header with a length exceeding the configured maxElements limit. Netty throws a CodecException, but the bulk-string ByteBuf remains pinned and the partial aggregate frame stays on the depth stack. Because the application keeps the channel alive for reconnect resilience, the attacker then floods the channel with additional messages, each being consumed into the stale aggregate rather than a fresh frame, progressively exhausting Netty's pooled buffer allocator until the service degrades. A PoC test demonstrating refcount retention and post-exception continuation is publicly available in the GHSA advisory.