CVE-2026-56818: Netty RedisArrayAggregator memory leak in RESP decoding

CVE-2026-56818 · Severity: medium · CVSS 6.5 · Published 2026-08-07

Netty is a popular networking framework used to build high-performance servers and clients. A vulnerability in its Redis data processing component allows an attacker to send specially crafted messages that cause the system to retain large amounts of data in memory even after an error occurs. This can lead to excessive memory consumption or data corruption if the connection remains open, potentially impacting the stability and reliability of the service.

Technologies: io.netty:netty-codec-redis (Maven), Netty-Codec-Redis. Vendors: Maven, Netty.

Quick answers

Is CVE-2026-56818 exploited in the wild?
No. Junglewise Threat Intelligence has no report of CVE-2026-56818 being exploited in the wild.
How severe is CVE-2026-56818?
Medium severity, with a CVSS score of 6.5, published 7 August 2026.
Which products and versions are affected?
io.netty:netty-codec-redis (Maven) ECOSYSTEM:introduced=0,fixed=4.1.136.Final; Netty-Codec-Redis < 4.1.136.Final, >= 4.2.0-Final, < 4.2.16.Final.
Is there a fix for CVE-2026-56818?
Yes. io.netty:netty-codec-redis (Maven): upgrade to 4.1.136.Final or later. Junglewise finds every place you run it, drafts the upgrade and applies it once you approve.
How is CVE-2026-56818 attacked?
It is attacked over the network, in a software library.
Am I affected by CVE-2026-56818?
Check whether you run io.netty:netty-codec-redis (Maven) or Netty-Codec-Redis at an affected version. Junglewise does that check for you around the clock: connect your code, cloud and domains, and it matches new vulnerabilities like this one against what you actually run and tells you when one reaches you.

How to fix

  • io.netty:netty-codec-redis (Maven): upgrade to 4.1.136.Final or later
    # set io.netty:netty-codec-redis to 4.1.136.Final in your pom.xml or build.gradle

Technical details

A vulnerability exists in the RedisArrayAggregator component of Netty's Redis codec where the decodeRedisArrayHeader method fails to call releaseAndClearDepths() when a header length exceeds the maxElements limit. While the sibling maxNestedArrayDepth check correctly performs cleanup, the maxElements branch throws a CodecException immediately without releasing retained ByteBuf references. An unauthenticated remote attacker can exploit this by sending a valid RESP array followed by a nested array header that exceeds the limit. If the application does not close the channel upon receiving the exception, the stale aggregate state remains active, pinning pooled buffers and potentially consuming subsequent messages into the corrupted state. Patches are available in versions 4.1.136.Final and 4.2.16.Final.

Affected products

  • Netty netty-codec-redis < 4.1.136.Final, >= 4.2.0-Final, < 4.2.16.Final

Identifiers

  • CVE-2026-56818
  • GHSA-p9jm-q85p-7mcp

Timeline

  • 2026-08-04: disclosed: Published to netty/netty repository
  • 2026-08-07: advisory: GitHub Advisory GHSA-p9jm-q85p-7mcp published

References

This page as Markdown. Free to reuse under CC BY 4.0 with a link back.