CVE-2026-44891 in Netty
Summary
by MITRE • 07/18/2026
Netty is a network application framework for development of protocol servers and clients. Prior to 4.1.136.Final and 4.2.16.Final, io.netty.handler.codec.stomp.StompSubframeDecoder fails to limit the total number of headers or their cumulative size per frame, and the maxLineLength parameter only restricts individual header lines. An attacker can send a large number of short headers that are accumulated in memory inside DefaultStompHeadersSubframe until the JVM throws an OutOfMemoryError, causing denial of service for servers exposing a STOMP endpoint based on StompSubframeDecoder. This issue is fixed in versions 4.1.136.Final and 4.2.16.Final.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Analysis
by VulDB Data Team • 07/18/2026
The vulnerability resides within Netty's STOMP protocol implementation, specifically in the StompSubframeDecoder component that handles incoming STOMP frames. This flaw represents a classic resource exhaustion attack vector where an attacker can manipulate memory consumption through carefully crafted header sequences. The issue affects versions prior to 4.1.136.Final and 4.2.16.Final, creating a persistent security risk for applications relying on Netty's STOMP server capabilities. The vulnerability is classified under CWE-400 as improper limitation of a pathname to a known-good set, specifically manifesting as insufficient resource management in protocol parsing.
The technical implementation flaw stems from the decoder's inadequate validation mechanisms that only enforce limits on individual header line lengths through maxLineLength parameter while completely ignoring cumulative header counts and total size constraints. This design oversight allows attackers to construct malicious STOMP frames containing numerous short headers that individually remain within the acceptable length limits but collectively consume excessive memory resources. The DefaultStompHeadersSubframe container accumulates these headers in memory without proper bounds checking, creating a memory leak scenario that ultimately leads to OutOfMemoryError conditions.
Operational impact of this vulnerability extends beyond simple service disruption to encompass potential system instability and resource exhaustion across multiple application layers. Servers exposing STOMP endpoints become particularly vulnerable as they process incoming frames without adequate protection against header-based memory consumption attacks. The attack vector is relatively straightforward for adversaries to exploit since it requires only the ability to establish connections to the target server and send malformed STOMP frames. This vulnerability aligns with ATT&CK technique T1499.004 for Network Denial of Service, specifically targeting application-level resource exhaustion through protocol manipulation.
Mitigation strategies should prioritize immediate upgrade to Netty versions 4.1.136.Final or 4.2.16.Final where the fix has been implemented. Organizations should also implement additional protective measures including rate limiting for STOMP connections, monitoring for unusual memory consumption patterns, and implementing connection-level restrictions on header counts and sizes. Network segmentation and firewall rules can provide additional defense-in-depth layers by limiting access to vulnerable STOMP endpoints. The fix addresses this issue through enhanced input validation that properly bounds both individual header lengths and cumulative header resource usage, preventing the accumulation of excessive memory allocations during frame processing.