CVE-2026-56819: Netty memory leak in HTTP/2 content decompression

CVE-2026-56819 · Severity: high · CVSS 7.5 · Published 2026-07-21

Netty is a popular networking library used by many Java-based web servers and applications to handle data traffic. A flaw in how it handles compressed web traffic (HTTP/2) allows a remote attacker to cause a memory leak by sending specially crafted data packets. Over time, this leak will consume all available system memory, causing the application to crash and resulting in a denial of service for legitimate users.

Technologies: io.netty:netty-codec-http2 (Maven), Netty Project Netty Codec HTTP2. Vendors: Maven, Netty Project.

Quick answers

Is CVE-2026-56819 exploited in the wild?
No. Junglewise Threat Intelligence has no report of CVE-2026-56819 being exploited in the wild.
How severe is CVE-2026-56819?
High severity, with a CVSS score of 7.5, published 21 July 2026.
Which products and versions are affected?
io.netty:netty-codec-http2 (Maven) ECOSYSTEM:introduced=4.2.0,fixed=4.2.16.Final; Netty Project Netty Codec HTTP2 >= 4.2.0, <= 4.2.15.Final.
Is there a fix for CVE-2026-56819?
Yes. io.netty:netty-codec-http2 (Maven): upgrade to 4.2.16.Final or later. Junglewise finds every place you run it, drafts the upgrade and applies it once you approve.
How is CVE-2026-56819 attacked?
It is attacked over the network, in a software library.
Am I affected by CVE-2026-56819?
Check whether you run io.netty:netty-codec-http2 (Maven) or Netty Project Netty Codec HTTP2 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-http2 (Maven): upgrade to 4.2.16.Final or later
    # set io.netty:netty-codec-http2 to 4.2.16.Final in your pom.xml or build.gradle

Technical details

A memory leak exists in DelegatingDecompressorFrameListener.java within the Http2Decompressor.decompress() method. When a DATA frame is received for a stream where the decompressor has already been closed, the code calls data.retain() before writeInbound(), incrementing the reference count. If writeInbound() throws a ClosedChannelException, the error handling path fails to call data.release(), preventing the ByteBuf from ever reaching a zero reference count. An attacker can exploit this by repeatedly sending DATA frames for closed streams over a long-lived HTTP/2 connection to exhaust direct memory. The issue is fixed in Netty versions 4.1.136.Final and 4.2.16.Final.

Affected products

  • Netty netty-codec-http2 >= 4.2.0, <= 4.2.15.Final
  • Netty netty-codec-http2 >= 4.1.0.Final, <= 4.1.135.Final

Identifiers

  • CVE-2026-56819
  • GHSA-93wv-jw9v-4972

Timeline

  • 2026-07-14: disclosed
  • 2026-07-31: advisory

References

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