CVE-2026-100657 in Netty
Summary
by MITRE • 09/26/2026
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.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Analysis
by VulDB Data Team • 09/26/2026
The vulnerability identified within the Netty STOMP codec, specifically affecting io.netty:netty-codec-stomp versions up to 4.1.137.Final and 4.2.0.Final through 4.2.17.Final, represents a critical resource management flaw rooted in improper exception handling and lifecycle state cleanup. This issue manifests as a ByteBuf memory leak within the StompSubframeDecoder class, which is responsible for parsing STOMP protocol frames from network streams. The core technical failure occurs during the decoding process when a frame's declared content-length has been fully read. At this stage, the decoder allocates a chunk buffer from the channel allocator to hold the remaining data and parks it in an instance field while waiting for the single NUL byte that terminates the STOMP frame. This design assumes that the terminating character will always arrive promptly or that any interruption during its wait can be safely handled by standard exception recovery mechanisms, which is not the case under specific adversarial conditions.
The operational impact stems from a subtle but severe bug in how errors are caught and released within the decoder logic. If the remote peer sends a complete, well-formed frame body but deliberately withholds the terminating NUL byte, the decoder enters a waiting state that eventually times out or encounters an error condition requiring it to skip past the missing character. The method responsible for this action, skipNullCharacter, throws a replay Signal of type Error rather than Exception. Because the surrounding code employs a catch block designed only to handle Exception types, the Error is not intercepted by the release path intended to free the allocated buffer. Consequently, the ByteBuf remains held in memory indefinitely. This behavior classifies as CWE-401: Missing Release of Memory after Effective Lifetime, where resources are acquired but never returned to the system due to unhandled error conditions disrupting the cleanup routine.
Furthermore, the vulnerability is exacerbated by incomplete lifecycle management within the decoder's integration with Netty's channel pipeline architecture. Even if an exception were properly caught and handled during frame processing, the buffer would still leak because StompSubframeDecoder fails to override two critical methods: handlerRemoved0 and channelInactive. These methods are essential for ensuring that any pending or partially processed buffers are released when a connection is closed or the decoder is removed from the pipeline. Without these overrides, the allocated memory survives even after the TCP connection has been terminated by either party. This means that every active connection can accumulate one unreleased allocator buffer per incomplete frame, leading to significant resource consumption over time.
From an offensive security perspective, this vulnerability aligns with ATT&CK technique T1496: Resource Hijacking, specifically in the context of Denial of Service through memory exhaustion. A remote attacker can exploit this flaw by establishing multiple connections and sending valid STOMP frames without the terminating NUL byte. With Netty's default pooled allocator configuration, which is optimized for high-throughput applications but retains allocated buffers to avoid allocation overhead, these leaked buffers are never returned to the pool or reclaimed by garbage collection. The leak accumulates linearly with the number of affected connections and persists for the lifetime of the Java process. Eventually, this leads to OutOfMemoryError conditions, causing the application to crash or become unresponsive, effectively achieving a remote denial-of-service attack without requiring authentication or complex payload construction beyond simple frame formatting.
Mitigation strategies must prioritize upgrading to patched versions immediately. The issue is resolved in Netty version 4.1.138.Final and 4.2.18.Final, where the decoder logic has been corrected to properly handle Error types during buffer release and lifecycle methods have been implemented to ensure cleanup upon channel closure. For organizations unable to upgrade instantly due to dependency constraints or testing cycles, temporary mitigations include configuring Netty to use a non-pooled allocator if memory pressure is not critical, though this may impact performance. Additionally, implementing strict timeout policies on STOMP frame reception and monitoring JVM heap usage for abnormal growth patterns can help detect exploitation attempts early. Security teams should also audit their network ingress points to ensure that incomplete or malformed protocol frames are dropped before reaching the application layer decoder, reducing the attack surface available to potential adversaries seeking to exhaust system resources.