CVE-2026-56818: Netty Information Disclosure Vulnerability

CVE-2026-56818 Overview

CVE-2026-56818 is a memory leak vulnerability [CWE-401] in the Netty asynchronous, event-driven network application framework. The flaw resides in the RedisArrayAggregator Redis codec, which fails to clear retained partial aggregate state when the maxElements limit is exceeded. An unauthenticated network peer can send a crafted RESP array that triggers the security-limit exception while leaving attacker-controlled aggregate state alive across the exception. Later messages continue to accumulate into the pre-error aggregate, pinning retained pooled buffers. The issue affects Netty versions prior to 4.1.136.Final and 4.2.16.Final.

Critical Impact
Unauthenticated remote peers can pin pooled buffer memory and keep attacker-controlled decoder state alive after a security exception, leading to resource exhaustion on long-lived channels.

Affected Products

Netty versions prior to 4.1.136.Final (4.1.x branch)
Netty versions prior to 4.2.16.Final (4.2.x branch)
Applications using the RedisArrayAggregator codec that keep channels open after decoder exceptions

Discovery Timeline

2026-08-07 - CVE-2026-56818 published to NVD
2026-08-08 - Last updated in NVD database

Technical Details for CVE-2026-56818

Vulnerability Analysis

The vulnerability is a memory leak in Netty's Redis Serialization Protocol (RESP) codec. The RedisArrayAggregator handler tracks partial aggregate state as it decodes nested RESP array structures from peers. Netty enforces two sibling safety limits during decoding: maxNestedArrayDepth and maxElements. When the maxNestedArrayDepth limit is exceeded, the aggregator correctly clears any retained partial aggregate state. When the maxElements limit is exceeded, however, the same cleanup does not occur.

An attacker can start a valid RESP array, send a bulk string child, then send a nested array header longer than the configured maxElements. Netty raises a decoder exception inside decodeRedisArrayHeader, but the partial aggregate remains retained inside the handler. If the application keeps the channel alive after the exception, subsequent messages are consumed into the pre-error aggregate. This allows the peer to pin pooled buffer memory and keep decoder state alive indefinitely.

Root Cause

The root cause is asymmetric exception handling between two sibling security limits in RedisArrayAggregator. The cleanup path for maxNestedArrayDepth releases retained state, while the code path handling maxElements throws without releasing the accumulated partial aggregate. The retained ByteBuf references from Netty's pooled allocator remain reachable through the handler, preventing return to the pool.

Attack Vector

Exploitation requires only network access to a service that uses Netty's RedisArrayAggregator and keeps channels alive after decoder exceptions. No authentication or user interaction is required. The attack sequence is:

Open a connection to the target service.
Send a valid RESP array opening and a bulk string child.
Send a nested array header with a length greater than maxElements.
After the decoder exception fires, continue sending frames on the same channel.
Newly decoded frames accumulate into the pre-error aggregate, pinning pooled buffers.

By repeating this pattern across many channels, an attacker can degrade the integrity of decoder state and exhaust pooled buffer memory. The patch commits 5b68c61f37aa4a3045cba624cbea239655c9003b and bb2ff68a1fb71cb4b0eb9a9e17b66c52aff680c6 correct the cleanup path so that both limit violations release partial aggregate state. Refer to the Netty security advisory GHSA-p9jm-q85p-7mcp for the official technical description.

Detection Methods for CVE-2026-56818

Indicators of Compromise

Repeated DecoderException entries in application logs originating from io.netty.handler.codec.redis.RedisArrayAggregator and decodeRedisArrayHeader.
Growth in pooled buffer memory (PooledByteBufAllocator metrics) that does not release after decoder exceptions.
Long-lived client channels that continue to transmit frames after a Redis codec exception has been raised.

Detection Strategies

Instrument Netty pipelines with a channel-level exception listener that records maxElements-related exceptions and correlates them with continued reads on the same channel.
Track PooledByteBufAllocatorMetric retained buffer counts over time and alert on monotonic growth tied to Redis codec handlers.
Inspect RESP traffic for nested array headers declaring lengths larger than the configured maxElements setting.

Monitoring Recommendations

Monitor JVM heap and direct memory usage on services embedding Netty Redis codecs, alerting on sustained growth without corresponding traffic increases.
Log the Netty version reported at startup and flag hosts running versions earlier than 4.1.136.Final or 4.2.16.Final.
Capture per-peer counts of decoder exceptions and treat repeat offenders on a single channel as suspicious.

How to Mitigate CVE-2026-56818

Immediate Actions Required

Upgrade Netty to 4.1.136.Final or 4.2.16.Final in all affected applications and redeploy.
Audit dependency trees for transitive Netty usage; frameworks and clients often bundle Netty independently.
Configure Netty pipelines to close channels on any DecoderException from the Redis codec until the patched version is deployed.

Patch Information

The upstream fix is delivered in Netty 4.1.136.Final and 4.2.16.Final. The corrective commits are 5b68c61 and bb2ff68, merged through pull request #17065. The patches ensure that partial aggregate state is released whenever either the maxNestedArrayDepth or maxElements limit is exceeded.

Workarounds

Add a handler after RedisArrayAggregator that calls ctx.close() on any caught DecoderException, ensuring the channel and its retained buffers are released.
Lower maxElements and maxNestedArrayDepth only for trusted peers; this does not eliminate the leak but reduces the buffer size an attacker can pin per exception.
Restrict network exposure of services using the Redis codec to authenticated networks until patched builds are deployed.

bash

# Update the Netty dependency to a patched version
# Maven
mvn versions:set-property -Dproperty=netty.version -DnewVersion=4.1.136.Final

# Gradle
./gradlew dependencies --refresh-dependencies \
  -PnettyVersion=4.2.16.Final

# Verify the resolved version
mvn dependency:tree | grep io.netty