Unbounded SCTP Fragment Reassembly in Netty
CVE-2026-46340 is a resource-exhaustion vulnerability in Netty's netty-transport-sctp component, affecting versions before 4.1.135.Final in the 4.1.x branch and before 4.2.15.Final in the 4.2.x branch. During fragmented SCTP message reassembly, SctpMessageCompletionHandler repeatedly wraps the previous accumulator and each new fragment in a new CompositeByteBuf. After N fragments, the accumulator forms an N-level nested buffer structure, retaining component arrays and buffer references and requiring recursive traversal for operations such as readableBytes() and getBytes(). The vulnerable implementation does not bound fragment counts, total buffered bytes, or retained incomplete-message entries keyed by stream identifier. A remote peer can cause indefinite resource growth by sending tiny fragments without completing their messages.
What it means and what to do now: patch path, interim mitigations, and the assume-compromise checklist.
What an attacker gets, and what they’ve been doing with it.
An attacker can exhaust application memory and increase buffer-processing overhead, causing denial of service in applications that use the affected SCTP reassembly handler. Very small fragment payloads can accumulate substantial bookkeeping and nested-buffer overhead. Availability is affected; confidentiality compromise, data modification, and code execution are not established.
If you can’t patch tonight, do this now.
No vulnerability-specific vendor workaround is identified. As interim exposure-reduction measures, restrict SCTP connectivity to trusted peers or disable the affected SCTP functionality where it is unnecessary. These measures do not correct the vulnerable reassembly implementation.
Patch, then assume compromise.
Upgrade netty-transport-sctp to at least 4.1.135.Final or 4.2.15.Final in the corresponding release branch. These releases introduce limits on concurrent incomplete messages and fragments per message. However, those count-based limits do not fully constrain retained byte sizes: a separate follow-up issue permits memory exhaustion using large fragments. Prefer 4.1.137.Final or later, or 4.2.17.Final or later, which additionally enforce a cumulative buffered-byte limit, defaulting to 16 MiB. For bundled dependencies, deploy the applicable vendor release containing the fixes.
No public exploits tracked yet. Mallory keeps watching.
Products and vendors Mallory has correlated with this vulnerability. Open in Mallory to drill down to specific CPE configurations and version ranges.
31 sources tracked across advisories, community write-ups, and news. New activity surfaces here as Mallory finds it.