Netty’s STOMP codec contains a ByteBuf leak in the StompSubframeDecoder. After a STOMP frame’s declared length is fully read, the decoder holds a chunk buffer while awaiting a terminating NUL byte. If that byte never arrives, the buffer is never released because the exception thrown during the skip operation is an Error and bypasses the catch block that would normally free it. The decoder also does not release the buffer on channel teardown, allowing the leak to persist permanently for the life of the process. This bug can be triggered remotely by a peer sending a well‑formed frame body and purposely omitting the NUL terminator, causing one allocator buffer to leak per connection. With the default pooled allocator, the leaked buffers are never returned to the pool or reclaimed by garbage collection, leading to progressive memory exhaustion and potentially a denial‑of‑service condition.

The vulnerability affects Netty’s STOMP codec library (io.netty:netty-codec-stomp) across all supported releases up to and including 4.1.137.Final, and the 4.2.x line from 4.2.0.Final through 4.2.17.Final. The fix is included in 4.1.138.Final and 4.2.18.Final. Systems that use Netty for STOMP handling and run any of these affected versions are at risk.

The CVSS score of 8.7 indicates a high severity vulnerability. Although no EPSS data is available, it is inferred from the description that an attacker can trigger the leak remotely by sending a well‑formed STOMP frame that lacks the terminating NUL byte, which may lead to memory exhaustion. The vulnerability is not currently listed in the CISA KEV catalog, but the lack of a remediation path beyond a patch means the risk remains significant for any actively exposed service using the affected Netty delivery. The best mitigation is to upgrade to the fixed releases as soon as possible. Until then, monitoring memory usage and limiting connections can reduce impact but do not eliminate the threat.