CVE-2026-59902: Memory Exhaustion in Netty SctpMessageCompletionHandler

The Stream Control Transmission Protocol (SCTP) is a transport-layer protocol designed to support message-oriented data transmission across packet networks. Within the Netty framework, the netty-transport-sctp module handles these connections. Specifically, the SctpMessageCompletionHandler class manages the reassembly of fragmented SCTP user data chunks. It buffers inbound fragments until a complete message is reconstructed and passed up the application channel pipeline.

This architecture exposes an attack surface centered around resource allocation. Because SCTP natively supports message fragmentation, receivers must temporarily store incomplete message fragments in memory. The vulnerability resides in the way Netty manages this temporary buffer memory. Unauthenticated remote network clients can exploit the allocation logic to trigger a complete service shutdown.

This vulnerability is classified under CWE-400 (Uncontrolled Resource Consumption) and carries a CVSS base score of 7.5. An attacker does not require system privileges or user interaction to exploit this flaw. The impact is isolated to service availability, where successful exploitation results in an uncontrolled process exit via memory exhaustion.

To understand the root cause, it is necessary to examine how SctpMessageCompletionHandler buffers fragmented messages. The handler maintains an internal map called incompleteSctpMessages to store incoming fragments, keyed by stream identifier. Each entry in this map contains a list of ByteBuf references representing the individual fragments received so far.

While a prior patch for CVE-2026-46340 established boundaries on the quantity of incoming data, those restrictions were structurally incomplete. The previous controls enforced boundaries on the maximum number of concurrent incomplete messages (maxIncompleteSctpMessages, default 128) and the maximum number of fragments permitted per message (maxFragments, default 128). Crucially, these parameters only tracked the count of elements rather than their actual physical sizes in memory.

Under default configurations, an attacker can transmit chunks containing up to 64 KB of user payload. A single connection can hold 128 incomplete messages, with each message containing 128 individual fragments. Calculating the cumulative memory footprint reveals that a single client connection can force the allocation of approximately 1.05 GB of heap or direct memory (128 concurrent messages * 128 fragments * 65,536 bytes). By initiating multiple concurrent SCTP associations, an attacker can rapidly exceed the JVM maximum heap threshold, triggering an unrecoverable OutOfMemoryError (OOM).

The vulnerability was mitigated in Netty commit 1b5abc6443b63726c72cdd285af2feb7ddbb8ff7. The fix introduces a strict byte-budget limitation that prevents unbounded heap allocation during fragment reassembly. Below is an analysis of the structural changes implemented in SctpMessageCompletionHandler.java.

public class SctpMessageCompletionHandler extends MessageToMessageDecoder<SctpMessage> {
    // Introduces a hard ceiling of 16 MB of cumulative memory for incomplete fragments
    private static final int DEFAULT_MAX_BUFFERED_BYTES = 16 * 1024 * 1024;
 
    private final IntObjectMap<List<ByteBuf>> incompleteSctpMessages = new IntObjectHashMap<>();
    private final int maxIncompleteSctpMessages;
    private final int maxFragments;
    private final int maxBufferedBytes;
    private long bufferedBytes; // Active tracker for currently allocated fragment memory

When a new fragment arrives, the handler must check the available byte budget prior to allocating and retaining the buffer. This validation step is executed via a helper function checkBufferedBytes before invoking byteBuf.retain():

// Code snippet showing budget check before fragment buffering
if (incompleteSctpMessages.size() >= maxIncompleteSctpMessages) {
    throw new CodecException("Too many incomplete sctp messages in flight: " + maxIncompleteSctpMessages);
}
checkBufferedBytes(byteBuf); // Throws exception if buffer limit is exceeded
frag = new ArrayList<>();
frag.add(byteBuf.retain());
bufferedBytes += byteBuf.readableBytes(); // Account for newly buffered bytes
incompleteSctpMessages.put(streamIdentifier, frag);

Upon successful reassembly of the complete message, or when an error causes the channel to terminate, the handler must release the tracked memory budget. The helper function removeBufferedBytes is called to decrement the counter:

private void checkBufferedBytes(ByteBuf byteBuf) {
    int readableBytes = byteBuf.readableBytes();
    if (readableBytes > maxBufferedBytes - bufferedBytes) {
        throw new CodecException("Too many buffered bytes for incomplete sctp messages: " + maxBufferedBytes);
    }
}
 
private void removeBufferedBytes(List<ByteBuf> buffers) {
    for (ByteBuf buffer : buffers) {
        bufferedBytes -= buffer.readableBytes();
    }
}

This implementation is structurally sound and complete. By verifying both individual fragment size limits and a global byte threshold, the application blocks malicious fragmentation sequences before they can exhaust JVM memory reserves.

An attack targeting CVE-2026-59902 requires no initial system authentication. The only prerequisite is network-level access to the port where the Netty-based SCTP service is listening. The attacker does not need to establish a fully compliant application-layer session, as the vulnerability is triggered during transport-layer stream processing.

The attack begins when the malicious client establishes an SCTP association with the target server. The attacker then transmits multiple SCTP DATA chunks containing fragmented payloads. Crucially, the attacker marks these chunks as incomplete by omitting the 'Ending fragment' flag (the E-bit in the SCTP chunk flags must be set to 0). This forces the Netty handler to hold the incoming data in memory indefinitely. By sending large fragments across multiple concurrent streams, the heap space is rapidly consumed until the application crashes.

The exploitation of this vulnerability leads to a complete loss of service availability. In standard Java applications, when the JVM throws an OutOfMemoryError, the runtime environment often enters an unstable state. Worker threads can terminate silently, locks may remain unreleased, and database connections can fail to close properly. In many enterprise deployment environments, the container orchestrator (such as Kubernetes) or the operating system process manager will terminate the JVM process entirely.

Because the vulnerability affects the networking transport layer, it blocks all active and incoming connections when the crash occurs. In critical environments utilizing SCTP for telecommunications protocols (such as SS7/SIGTRAN or 5G core network interfaces), a service crash can disrupt communications infrastructure. The lack of integrity or confidentiality impact limits the risk of data theft, keeping the focus entirely on service disruption.

The primary recommendation is to update the Netty dependencies to a patched version. This resolves the flaw natively by introducing the missing budget-checking mechanisms. Security administrators should audit their project configuration files to ensure compliance with the following versions:

If using the Netty 4.1.x release stream, upgrade the dependency to version 4.1.137.Final or newer. If using the Netty 4.2.x release stream, upgrade to version 4.2.17.Final or newer.

<!-- Recommended dependency upgrade in Maven pom.xml -->
<dependency>
    <groupId>io.netty</groupId>
    <artifactId>netty-transport-sctp</artifactId>
    <version>4.2.17.Final</version>
</dependency>

If patching is not immediately feasible, system administrators should implement network-level access controls. Restrict incoming SCTP traffic to trusted peer IP addresses using firewall rules or security groups. Additionally, configure connection rate-limiting policies at the operating system level to reduce the number of concurrent SCTP associations an untrusted host can maintain.