CVE-2026-59902: Netty SCTP Handler DOS Vulnerability

CVE-2026-59902 Overview

CVE-2026-59902 is a resource exhaustion vulnerability [CWE-400] in Netty, an asynchronous, event-driven network application framework widely embedded in Java-based servers and clients. The io.netty.handler.codec.sctp.SctpMessageCompletionHandler class limits incomplete messages and fragment counts but fails to enforce a maxBufferedBytes cap. Unauthenticated peers can send large Stream Control Transmission Protocol (SCTP) fragments to exhaust JVM heap memory. The issue affects Netty releases prior to 4.1.137.Final and 4.2.17.Final.

Critical Impact
Remote unauthenticated attackers can trigger denial of service against any Netty-based service that processes SCTP traffic by buffering unbounded fragmented messages until memory is exhausted.

Affected Products

Netty versions prior to 4.1.137.Final (4.1.x branch)
Netty versions prior to 4.2.17.Final (4.2.x branch)
Applications using io.netty.handler.codec.sctp.SctpMessageCompletionHandler

Discovery Timeline

2026-08-17 - CVE-2026-59902 published to the National Vulnerability Database (NVD)
2026-08-18 - Last updated in NVD database

Technical Details for CVE-2026-59902

Vulnerability Analysis

The defect lives in Netty's SCTP codec, specifically in SctpMessageCompletionHandler. The handler reassembles fragmented SCTP messages by buffering fragments per stream until the message is complete. Existing safeguards cap the number of concurrent incomplete messages and the fragment count per message, but they never sum the byte size of buffered payloads. An attacker who can reach the SCTP endpoint may open one or more associations and stream large fragments that never finalize. Because the handler retains fragment payloads in memory pending completion, buffered bytes grow unbounded, driving the Java Virtual Machine (JVM) toward OutOfMemoryError and service termination.

Root Cause

The root cause is missing enforcement of a maxBufferedBytes threshold in SctpMessageCompletionHandler. Counting messages and fragments is insufficient when individual fragments can be arbitrarily large. This is a classic uncontrolled resource consumption issue tracked under [CWE-400].

Attack Vector

Exploitation requires network reach to an SCTP listener that uses the vulnerable handler. No authentication or user interaction is needed. An attacker sends oversized or numerous SCTP data chunks that Netty holds in reassembly buffers. Sustained delivery inflates heap usage until the process crashes or garbage-collection thrashing renders the service unresponsive. The impact is limited to availability; confidentiality and integrity are not affected.

No public proof-of-concept exploit is available. Technical details are described in the Netty Security Advisory GHSA-2qj4-mmr9-4v2f and the fixing changes in Netty Pull Request #17213 and Netty Pull Request #17217.

Detection Methods for CVE-2026-59902

Indicators of Compromise

Sustained JVM heap growth on services exposing SCTP listeners, followed by java.lang.OutOfMemoryError entries in application logs.
Repeated inbound SCTP associations from a single peer delivering large data chunks that never complete a message.
Abnormally large retained sizes on SctpMessageCompletionHandler instances observed in heap dumps.

Detection Strategies

Inventory Java applications and identify direct or transitive dependencies on io.netty:netty-all, netty-codec, or netty-transport-sctp at versions below 4.1.137.Final or 4.2.17.Final.
Use software composition analysis (SCA) tooling to flag vulnerable Netty coordinates in build manifests and runtime artifacts.
Correlate SCTP traffic anomalies from network telemetry with JVM memory pressure metrics on the corresponding hosts.

Monitoring Recommendations

Alert on JVM heap utilization exceeding baseline thresholds sustained across multiple garbage-collection cycles.
Monitor SCTP association counts, per-peer fragment volume, and average message completion latency on exposed endpoints.
Capture and review heap histograms periodically for services that terminate SCTP traffic.

How to Mitigate CVE-2026-59902

Immediate Actions Required

Upgrade Netty to 4.1.137.Final or 4.2.17.Final in all affected artifacts and redeploy dependent services.
Restrict network access to SCTP listeners so only trusted peers can establish associations.
Audit the dependency tree of Java services for shaded or relocated Netty copies that may require separate remediation.

Patch Information

The issue is fixed in Netty Release 4.1.137 and Netty Release 4.2.17. The corrective changes are tracked in the Netty Commit Update, Netty Pull Request #17213, and Netty Pull Request #17217, which introduce byte-level accounting for buffered SCTP fragments.

Workarounds

Remove SctpMessageCompletionHandler from pipelines that do not require SCTP fragment reassembly.
Terminate SCTP connections at an upstream device that enforces per-peer bandwidth and message size limits.
Apply operating-system-level firewall rules to allowlist SCTP source addresses until patched versions are deployed.

Sample patch context from the upstream fix commit — the same merge tightens related codec input validation, illustrating the defensive style applied across Netty's protocol handlers:

java

// codec-mqtt/src/main/java/io/netty/handler/codec/mqtt/MqttCodecUtil.java
static boolean isValidPublishTopicName(String topicName) {
    if (topicName == null) {
        return false;
    }
    // publish topic name must not contain any wildcard
    for (int i = 0; i < topicName.length(); i++) {
        char c = topicName.charAt(i);
        if (c == '#' || c == '+' || c == '\0') {
            return false;
        }
    }
    // ...
}

Source: Netty Commit 1b5abc6