CVE-2026-56818

Netty is an asynchronous, event-driven network application framework. Prior to 4.1.136.Final and 4.2.16.Final, the RedisArrayAggregator Redis codec clears retained partial aggregate state when the maxNestedArrayDepth limit is exceeded, but it does not clear the same state when the sibling maxElements limit is exceeded. A peer can start a valid RESP array, send a bulk string child, then send a nested array header longer than the configured maxElements. Netty throws a decoder exception in decodeRedisArrayHeader, but the existing partial aggregate remains retained in the handler. If the application leaves the channel alive after the exception, later messages are still consumed into the pre-error aggregate, allowing an unauthenticated peer to keep attacker-controlled aggregate state alive across a security-limit exception and pin retained pooled buffers. This issue is fixed in versions 4.1.136.Final and 4.2.16.Final.

Summary

RedisArrayAggregator clears retained partial aggregate state when the maxNestedArrayDepth limit is exceeded, but it does not clear the same state when the sibling maxElements limit is exceeded. A peer can start a valid RESP array, send a bulk-string child, then send a nested array header longer than the configured maxElements. Netty throws a decoder exception, but the existing partial aggregate remains retained in the handler.

If the application leaves the channel alive after the exception, later messages are still consumed into the pre-error aggregate. The supplied PoV proves both the retained ByteBuf reference and the stale parser state continuation.

Technical Details

RedisArrayAggregator.decode(...) retains non-array messages before adding them to depths.peek().children. In decodeRedisArrayHeader(...), the header.length() > maxElements branch throws immediately:

if (header.length() > maxElements) {
    throw new CodecException("this codec doesn't support longer length than " + maxElements);
}

The immediately following nested-depth branch clears retained aggregate state before throwing:

if (depths.size() >= maxNestedArrayDepth) {
    releaseAndClearDepths();
    throw new CodecException("max nested array depth exceeded: " + maxNestedArrayDepth);
}

The missing cleanup in the first branch leaves retained children and aggregate state reachable after the exception.

PoC

Place the supplied RedisArrayAggregatorIncompleteCleanupPovTest.java under:

codec-redis/src/test/java/io/netty/handler/codec/redis/

Run:

./mvnw -pl codec-redis -am -Dtest=RedisArrayAggregatorIncompleteCleanupPovTest -Dsurefire.failIfNoSpecifiedTests=false -DskipNativeTests -DskipAutobahnTests test

The test suite includes:

• serialized RESP trigger through RedisDecoder, RedisBulkStringAggregator, and RedisArrayAggregator;
• direct refcount proof that max-elements overflow does not release the retained child immediately;
• post-exception continuation proof that the stale aggregate consumes a later message;
• nested-depth controls that clear the same partial aggregate state.

All five tests pass on current 4.2, 4.2.15.Final, and 4.1.135.Final.

Impact

For Redis codec pipelines that continue after codec exceptions, an unauthenticated peer can keep attacker-controlled aggregate state alive across a security-limit exception. This can pin retained pooled buffers until channel close/removal or until a later message completes the stale aggregate.

RedisBulkStringAggregator permits bulk strings up to RedisConstants.REDIS_MESSAGE_MAX_LENGTH (512MB), so the retained child can be large in deployments that aggregate untrusted Redis streams.

Applications that always close the channel or remove the handler on decoder exceptions will trigger existing cleanup; the issue is the missing immediate cleanup on the max-elements failure path while the handler remains installed.

Suggested Fix

Call releaseAndClearDepths() before throwing from the max-elements branch. Consider applying the same cleanup to all unrecoverable decodeRedisArrayHeader(...) error exits that can occur while depths is non-empty.

Affected Package/Versions

io.netty:netty-codec-redis

Confirmed on:

• current 4.2 branch head 7bae566a93e69409697fe57fa807910ba5c9720e
• 4.2.15.Final at a41f7b289ce1
• 4.1.135.Final at f05f765d8146

Advisory History

This differs from the public Redis codec advisories because it reproduces on their patched tags:

• GHSA-5w86-c3rq-vjj7
• GHSA-3244-j874-rhc2 / CVE-2026-44250
• GHSA-6jv9-x5w9-2ccm / CVE-2026-48006
• GHSA-6ghj-frrj-jjj3 / CVE-2026-44890

Why This Is Not Intended Behavior

The public API docs document RedisArrayAggregator as aggregating RedisMessage parts into ArrayRedisMessage and document a CodecException when an array header exceeds maxElements. They do not document preserving pre-exception partial…

A client might overload the server by issue frequent RST frames. This can cause a massive amount of load on the remote system and so cause a DDOS attack.

Impact

This is a DDOS attack, any http2 server is affected and so you should update as soon as possible.

Patches

This is patched in version 4.1.100.Final.

Workarounds

A user can limit the amount of RST frames that are accepted per connection over a timeframe manually using either an own Http2FrameListener implementation or an ChannelInboundHandler implementation (depending which http2 API is used).

References

• https://www.cve.org/CVERecord?id=CVE-2023-44487
• https://blog.cloudflare.com/technical-breakdown-http2-rapid-reset-ddos-attack/
• https://cloud.google.com/blog/products/identity-security/google-cloud-mitigated-largest-ddos-attack-peaking-above-398-million-rps/

Red Hat Lightwell has released io.netty:netty-codec-redis 4.1.100.Final-rhlw-00001 with backported fixes for CVE-2026-42586, CVE-2026-44250, CVE-2026-44890, CVE-2026-48006, CVE-2026-50011, and CVE-2026-56818.

CVE-2026-42586: Netty: CRLF Injection in Netty Redis Codec Encoder

CVE-2026-44250: Netty: Memory Exhaustion in RedisArrayAggregator due to Deeply Nested Arrays

CVE-2026-44890: Netty has Unbounded Direct Memory Consumption in its RedisDecoder

CVE-2026-48006: Netty's Lack of Lifecycle Cleanup Leads to Pooled ByteBuf Leak in RedisArrayAggregator

CVE-2026-50011: Netty has unbounded pre-allocation in RedisArrayAggregator from RESP array length

CVE-2026-56818: Netty: RedisArrayAggregator max-elements failure leaves retained partial aggregate state

This patched artifact is a drop-in replacement for io.netty:netty-codec-redis 4.1.100.Final from Maven Central.

Root has patched GHSA-xpw8-rcwv-8f8p in the io.root.io.netty:netty-codec-http2 package for Root:Maven. Multiple fixed versions available.

Netty is an asynchronous, event-driven network application framework. Prior to 4.1.136.Final and 4.2.16.Final, the RedisArrayAggregator Redis codec clears retained partial aggregate state when the maxNestedArrayDepth limit is exceeded, but it does not clear the same state when the sibling maxElements limit is exceeded. A peer can start a valid RESP array, send a bulk string child, then send a nested array header longer than the configured maxElements. Netty throws a decoder exception in decodeRedisArrayHeader, but the existing partial aggregate remains retained in the handler. If the application leaves the channel alive after the exception, later messages are still consumed into the pre-error aggregate, allowing an unauthenticated peer to keep attacker-controlled aggregate state alive across a security-limit exception and pin retained pooled buffers. This issue is fixed in versions 4.1.136.Final and 4.2.16.Final.

TuxCare rebuilt 47 io.netty packages to address 23 CVEs. Fixed in 4.1.135.Final-tuxcare.1.

TuxCare rebuilt 47 io.netty packages to address 23 CVEs. Fixed in 4.1.130.Final-tuxcare.3.

TuxCare rebuilt 47 io.netty packages to address 59 CVEs. Fixed in 4.1.122.Final-tuxcare.2.

TuxCare rebuilt 47 io.netty packages to address 60 CVEs. Fixed in 4.1.119.Final-tuxcare.1.

TuxCare rebuilt 47 io.netty packages to address 41 CVEs. Fixed in 4.1.112.Final-tuxcare.6.

TuxCare rebuilt 47 io.netty packages to address 62 CVEs. Fixed in 4.1.111.Final-tuxcare.1.

TuxCare rebuilt 47 io.netty packages to address 48 CVEs. Fixed in 4.1.117.Final-tuxcare.3.

TuxCare rebuilt 47 io.netty packages to address 61 CVEs. Fixed in 4.1.108.Final-tuxcare.1.

TuxCare rebuilt 47 io.netty packages to address 61 CVEs. Fixed in 4.1.107.Final-tuxcare.1.

TuxCare rebuilt 47 io.netty packages to address 62 CVEs. Fixed in 4.1.94.Final-tuxcare.1.

TuxCare rebuilt 47 io.netty packages to address 14 CVEs. Fixed in 4.1.115.Final-tuxcare.8.

TuxCare rebuilt 46 io.netty packages to address 22 CVEs. Fixed in 4.1.79.Final-tuxcare.4.

These are all security issues fixed in the netty-4.1.136-1.1 package on the GA media of openSUSE Tumbleweed.

This update for netty, netty-tcnative fixes the following issues:

Upgrade netty to upstream version 4.1.136 and netty-tcnative to version 2.0.80 Final.

Security issues fixed

• CVE-2026-44891: memory exhaustion in io.netty:netty-codec-stomp (bsc#1271435).
• CVE-2026-55831: resource exhaustion/DoS in io.netty:netty-codec-http (bsc#1271960).
• CVE-2026-55833: zip bomb in io.netty:netty-codec-http (bsc#1271961).
• CVE-2026-55851: memory exhaustion in io.netty:netty-codec-haproxy (bsc#1272253).
• CVE-2026-56745: memory exhaustion in io.netty:netty-codec-http (bsc#1272254).
• CVE-2026-56746: improper access control in io.netty:netty-codec-http (CORS) (bsc#1272255).
• CVE-2026-56817: insecure defaults in XML parsing in io.netty:netty-codec-xml (bsc#1272257).
• CVE-2026-56818: memory leak in io.netty:netty-codec-redis (bsc#1272603).
• CVE-2026-56819: memory leak in io.netty:netty-codec-http2 (bsc#1272258).
• CVE-2026-56820: improper certificate validation in io.netty:netty-handler-ssl-ocsp (bsc#1272259).
• CVE-2026-56821: improper certificate revocation check in io.netty:netty-handler-ssl-ocsp (bsc#1272299).
• CVE-2026-56822: time-of-check/time-of-use in io.netty:netty-handler-ssl-ocsp (bsc#1272300).
• CVE-2026-59898: protocol version confusion in io.netty:netty-codec-http (websocket) (bsc#1272302).
• CVE-2026-59899: memory exhaustion in io.netty:netty-codec-http (bsc#1272301).
• CVE-2026-59900: improper header neutralization in io.netty:netty-codec-http2 (bsc#1272303).
• CVE-2026-59901: infinite loop in io.netty:netty-codec-compression (bzip2) (bsc#1272304).
• CVE-2026-59919: improper CR/LF neutralization in io.netty:netty-codec-haproxy (bsc#1272305).
• CVE-2026-59920: improper CR/LF neutrolization in io.netty:netty-codec-stomp (bsc#1272306).
• CVE-2026-59921: improper CR/LF neutralization in io.netty:netty-codec-http (multipart) (bsc#1272307).
• Memory leak in io.netty:netty-codec-dns (bsc#1272519).
• Uncontrolled resource consumption in io.netty:netty-codec-xml (bsc#1272518).

Other updates and bugfixes:

• Upgrade to upstream version 4.1.136:
  • SingleThreadEventExecutor: document Throwable safety contract on run()
  • Make HTTP/2 frame hashCode consistent with equals
  • Add BlockHound exception for DnsQueryIdSpace (#16896)
  • FlowControlHandler: Fix autoRead behavior
  • Fix incorrect bounds in error message of HpackDecoder.setMaxHeaderListSize
  • MQTT: Fix MQTT decoder size check after variable header replay
  • MQTT: Make the decodeProperties early-REPLAY check actually fire
  • Reject control characters at the boundary of HTTP method names (#16723)
  • Update to latest tcnative release
  • Fix HTTP 2 PUSH_PROMISE stream association validation
  • Fix GZIP FEXTRA extra-field handling in JdkZlibDecoder
  • Add opt-in validation of mandatory pseudo-header fields for HTTP/2
  • Strictly validate MQTT UTF-8 Encoded String (#16939)
  • Stop DateFormatter trailing token from running past the parse end
  • IpFilter: Deprecate constructor which use accept by default
  • Add RFC 10008 QUERY Method support (#16966)
  • Correctly release and fail queued traffic-shaping writes on close (#16959)
  • FlowControlHandler: respect auto-read when toggled while dequeueing
  • IdleStateHandler: reset firstWriter/ReaderIdleEvent in resetWriteTimeout/resetReadTimeout (#16982)
  • Fix typo in AbstractSniHandler Javadoc
  • Reconcile AbstractCoalescingBufferQueue readableBytes when it drains, and fail stuck HTTP/2 streams instead of spinning empty DATA frames
  • Reject control characters at the boundary of the HTTP version token (#16971)
  • Reset UTF-8 decode state on CR in StompSubframeDecoder
  • HTTP2: Pass the correct number of arguments when logging goaway
  • FastLz: Guard decompression against truncated input (#17000)
  • Fix propagation of startTls for client SslContext handler
  • Reject non-token characters in HTTP/2 header names +…