CVE-2026-44891: Netty denial of service in StompSubframeDecoder

CVE-2026-44891 · Severity: high · CVSS 7.5 · Published 2026-07-17

Netty is a widely used networking framework for building Java-based server and client applications. A vulnerability in its STOMP protocol handler allows an attacker to crash a server by sending a flood of small message headers. This can lead to a complete service outage (Denial of Service) as the server runs out of memory trying to process the malicious data.

Vendors: Maven, Netty Project.

Quick answers

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

Technical details

A vulnerability exists in the io.netty.handler.codec.stomp.StompSubframeDecoder component of Netty. The decoder fails to enforce a limit on the total number of headers or the cumulative size of headers within a single STOMP frame; the existing maxLineLength parameter only restricts individual header lines. An unauthenticated remote attacker can exploit this by sending a large number of short headers that accumulate in memory within the DefaultStompHeadersSubframe object. This eventually triggers a Java Virtual Machine (JVM) OutOfMemoryError (OOME), resulting in a Denial of Service (DoS). The issue is resolved in versions 4.1.136.Final and 4.2.16.Final by enforcing a limit on the number of headers per frame.

Affected products

  • Netty Project Netty Prior to 4.1.136.Final and 4.2.16.Final

Identifiers

  • CVE-2026-44891
  • GHSA-vhch-2wf3-m8rp

Timeline

  • 2026-07-06: patched: Initial fix merged into 4.2 branch
  • 2026-07-08: patched: Fix backported to 4.1 branch
  • 2026-07-17: disclosed: CVE published

References

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