CVE-2026-44891: Netty STOMP Decoder DoS Vulnerability

CVE-2026-44891 Overview

CVE-2026-44891 is a denial-of-service vulnerability in Netty, a widely used Java network application framework for building protocol servers and clients. The flaw resides in io.netty.handler.codec.stomp.StompSubframeDecoder, which fails to enforce limits on the total number of headers or their cumulative size per Simple Text Oriented Messaging Protocol (STOMP) frame. The existing maxLineLength parameter only restricts individual header lines, leaving the aggregate memory footprint unbounded. Attackers can send frames containing many short headers that accumulate inside DefaultStompHeadersSubframe until the Java Virtual Machine (JVM) throws an OutOfMemoryError. The issue affects Netty versions prior to 4.1.136.Final and 4.2.16.Final and is tracked under [CWE-400] Uncontrolled Resource Consumption.

Critical Impact
An unauthenticated remote attacker can exhaust JVM heap memory on any server exposing a STOMP endpoint built on StompSubframeDecoder, causing a full denial of service.

Affected Products

Netty netty-all and netty-codec versions prior to 4.1.136.Final (4.1.x branch)
Netty netty-all and netty-codec versions prior to 4.2.16.Final (4.2.x branch)
Any application or middleware exposing a STOMP endpoint based on io.netty.handler.codec.stomp.StompSubframeDecoder

Discovery Timeline

2026-07-17 - CVE-2026-44891 published to the National Vulnerability Database (NVD)
2026-07-23 - Last updated in NVD database

Technical Details for CVE-2026-44891

Vulnerability Analysis

STOMP is a text-based messaging protocol where each frame consists of a command, a set of headers, and an optional body. Netty's StompSubframeDecoder parses incoming frames and stores parsed headers inside a DefaultStompHeadersSubframe instance. The decoder validates the length of each individual header line against the maxLineLength configuration parameter, but it does not track or bound the total number of headers or their combined memory footprint.

Because each header remains individually below the line-length threshold, an attacker can transmit thousands or millions of short, well-formed headers within a single frame or across multiple frames. Every header is appended to the internal collection, causing sustained heap growth. Once the JVM cannot allocate additional memory, it throws java.lang.OutOfMemoryError, terminating request processing and typically crashing the affected service.

Root Cause

The root cause is missing aggregate resource accounting inside StompSubframeDecoder. The decoder enforces per-line bounds but does not enforce a cap on header count or the cumulative byte size of all parsed headers per frame. This maps to [CWE-400] Uncontrolled Resource Consumption. The fix introduced in 4.1.136.Final and 4.2.16.Final adds explicit limits on both header count and total header size, rejecting frames that exceed these thresholds before further accumulation occurs.

Attack Vector

Exploitation requires only network reachability to a STOMP endpoint. No authentication, user interaction, or elevated privileges are needed. An attacker opens a TCP connection to the STOMP listener and sends a CONNECT or SEND frame containing a large volume of short custom headers, each ending with \n. The decoder buffers all of them until the JVM heap is exhausted. The technical details of the corrective changes are documented in the Netty Security Advisory GHSA-vhch-2wf3-m8rp and the patch pull request #17063.

Detection Methods for CVE-2026-44891

Indicators of Compromise

Repeated java.lang.OutOfMemoryError: Java heap space events in application logs originating from io.netty.handler.codec.stomp stack frames.
Abnormally large STOMP frames or connections producing thousands of header lines from a single source IP.
Sudden JVM heap growth or garbage collection pressure on services exposing STOMP over TCP or WebSocket.

Detection Strategies

Inspect Netty dependency versions across builds and container images; flag any netty-codec or netty-all artifact below 4.1.136.Final or 4.2.16.Final.
Instrument STOMP handlers with per-frame header-count metrics and alert when a single frame exceeds a reasonable threshold (for example, more than 100 headers).
Enable JVM heap dump on OutOfMemoryError and review dumps for oversized DefaultStompHeadersSubframe instances.

Monitoring Recommendations

Track TCP connections to STOMP ports and correlate high connection or byte counts with heap utilization metrics.
Forward JVM and application logs to a central analytics platform and alert on repeated OutOfMemoryError conditions tied to Netty codec classes.
Baseline normal STOMP header cardinality per client and alert on statistical outliers indicative of abuse.

How to Mitigate CVE-2026-44891

Immediate Actions Required

Upgrade Netty to 4.1.136.Final (4.1.x branch) or 4.2.16.Final (4.2.x branch) in all applications, libraries, and container images.
Audit transitive dependencies using Software Bill of Materials (SBOM) tooling to locate embedded vulnerable Netty versions.
Restrict network exposure of STOMP endpoints to trusted clients and networks until patching is complete.

Patch Information

The fixes are delivered in Netty 4.1.136.Final and Netty 4.2.16.Final. The corrective code is merged via pull request #17063 and backported through pull request #17065. Consult the GitHub Security Advisory GHSA-vhch-2wf3-m8rp for the full remediation notes.

Workarounds

Place a reverse proxy or STOMP-aware gateway in front of the service to enforce maximum header count and total frame size before traffic reaches Netty.
Configure per-client rate limits and maximum frame size at the network edge to reduce exposure while patch deployment is in progress.
Restrict STOMP endpoints to authenticated clients only, where the application architecture allows, to limit the attack surface.

bash

# Example Maven dependency override to enforce the patched Netty version
mvn dependency:tree | grep io.netty
# Update pom.xml to pin the fixed release:
#   <dependency>
#     <groupId>io.netty</groupId>
#     <artifactId>netty-all</artifactId>
#     <version>4.1.136.Final</version>
#   </dependency>
mvn -U clean verify