CVE-2026-100657: Netty before 4.1.138.Final ByteBuf Leak in StompSubframeDecoder
Rejected reason: This CVE ID has been rejected as a duplicate.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
io.netty:netty-codec-stompto a version that resolves this vulnerability.Fixed in 4.1.138.Final - Upgrade
Upgrade
io.netty:netty-codec-stompto a version that resolves this vulnerability.Fixed in 4.2.18.Final
Event History
Frequently Asked Questions
Which deployments are exposed to this issue?
Deployments using Netty's STOMP codec artifact, io.netty:netty-codec-stomp, are affected if they run versions up to and including 4.1.137.Final or versions from 4.2.0.Final through 4.2.17.Final. The issue is fixed in 4.1.138.Final and 4.2.18.Final.
What must an attacker do to trigger the leak?
A remote peer must be able to send STOMP frames to the affected decoder. It can trigger one allocator-buffer leak per connection by sending a complete, well-formed frame body with its declared content length, then withholding the final NUL terminator.
Is a non-default allocator configuration required for impact?
No. With Netty's default pooled allocator, the leaked memory is not returned to the pool or reclaimed by garbage collection, so leaked buffers accumulate for the lifetime of the process and can cause memory exhaustion.
How can I determine whether exploitation may be occurring?
Look for connections that deliver a complete STOMP frame body but do not send the required terminating NUL byte. Repeated instances across connections can correspond to allocator buffers accumulating until process memory is exhausted.