Description

Netty's STOMP codec (io.netty:netty-codec-stomp) contains a ByteBuf leak in StompSubframeDecoder. Once a frame's declared content-length has been fully read, the decoder allocates a chunk buffer from the channel allocator and parks it in an instance field while waiting for the single NUL byte that terminates the frame. If that byte never arrives, the buffer is never released: the replay Signal thrown by skipNullCharacter extends Error rather than Exception, so the decoder's catch(Exception) release path does not run, and StompSubframeDecoder overrides neither handlerRemoved0 nor channelInactive, so the buffer also survives channel teardown. A remote peer can leak one allocator buffer per connection by sending a complete, well-formed frame body and withholding its terminating NUL byte; with the default pooled allocator the memory is never returned to the pool or reclaimed by garbage collection, so the leak accumulates for the lifetime of the process and can lead to memory exhaustion. This affects versions up to and including 4.1.137.Final and versions 4.2.0.Final through 4.2.17.Final; it is fixed in 4.1.138.Final and 4.2.18.Final.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "7.5",
  "pubDate": "2026-09-26T14:16:48.540Z",
  "pubdate": "2026-09-26T14:16:48.540Z",
  "executiveSummary": "The io.netty:netty-codec-stomp component is susceptible to a persistent memory leak vulnerability caused by improper buffer management within the StompSubframeDecoder.\nThe vulnerability occurs when the decoder fails to release allocated ByteBuf resources during specific error-handling scenarios, specifically when a STOMP frame body is fully received but the mandatory terminating NUL byte is withheld by a remote peer.\nThis flaw allows an unauthenticated remote attacker to trigger a denial-of-service (DoS) condition by exhausting the system memory through accumulated leaked buffers.\nBecause the leaked memory is managed by a pooled allocator and remains unreferenced by the decoder but not garbage-collectible, memory exhaustion persists for the entire lifetime of the application process.\nAffected versions include 4.1.137.Final and below, as well as 4.2.0.Final through 4.2.17.Final.\nThe risk is critical in high-traffic environments where an attacker can open multiple connections to rapidly consume available memory, eventually leading to process crashes due to OutOfMemoryErrors.",
  "technicalDetails": "The vulnerability resides within the StompSubframeDecoder component, specifically in how it processes incoming STOMP frames that define a Content-Length header.\nWhen a STOMP frame with a defined content-length is parsed, the decoder allocates a ByteBuf from the channel allocator to hold the frame's body. Upon reading the full length, the decoder parks this buffer in an instance field while awaiting a single NUL byte (0x00) which signifies the formal termination of the STOMP frame.\nThe root cause of the leak is an inadequate error handling strategy regarding the ReplayError signal (or equivalent Signal extending Error). In Netty, when the decoder experiences an unexpected state during the wait for the NUL byte, it throws a signal that inherits from Error rather than Exception. Because the decoder’s catch block is specifically configured to trigger a release path only for Exception types, the cleanup logic is bypassed entirely.\nFurthermore, the StompSubframeDecoder fails to implement or override critical lifecycle management methods such as handlerRemoved0 or channelInactive. Consequently, even when a connection is closed by the remote peer or terminated by the server, the trapped ByteBuf is not returned to the pooled allocator. Since the buffer remains active in the pool, it is neither reclaimed by the garbage collector nor made available for future allocations.\nThe attack flow is straightforward: 1) An attacker establishes a TCP connection to the service utilizing the vulnerable Netty STOMP codec. 2) The attacker sends a valid STOMP frame header and the complete body as specified by the Content-Length header. 3) The attacker intentionally omits the NUL terminator byte. 4) The decoder transitions into an expectant state, holding the buffer. 5) By forcing a state transition or simply closing the connection without the terminator, the attacker induces the specific error condition that bypasses the release cleanup path. 6) Repeated execution of this flow across multiple concurrent connections leads to linear, monotonic memory growth. Over time, this exhaustion of the pooled memory leads to service instability or process termination."
}