CVE-2026-46340: Netty SCTP Memory Exhaustion Denial of Service

Technical summary

The vulnerability exists in netty-transport-sctp's fragment reassembly logic. When an SCTP message arrives in multiple chunks without the 'complete' flag set, the handler appends each new fragment by wrapping both the prior accumulator and the new data into a fresh CompositeByteBuf. This causes pathological nesting: after N fragments, you have an N-level-deep composite buffer chain where each level holds component array references. Operations like readableBytes() and getBytes() must recurse through all N levels. No bounds exist on fragment count, total accumulated bytes, or the number of unique stream identifiers opened by an attacker. A malicious peer can repeatedly send single-byte DATA chunks across unlimited streams with the complete flag never set, causing unbounded memory growth and stack exhaustion during buffer operations.

Business impact

Services relying on Netty for SCTP communication face availability risk. An unauthenticated remote attacker can trigger denial of service—either via memory exhaustion or stack overflow—without needing valid credentials or prior access. This affects real-time protocols, telecom signaling, and other mission-critical systems using SCTP. The attack is trivial to execute (send incomplete fragments) yet difficult to rate-limit without deep protocol inspection. Production outages and service interruptions are the primary concern.

Affected systems

Netty versions prior to 4.1.135.Final and 4.2.15.Final are vulnerable, specifically the netty-transport-sctp module. Any application that uses Netty's SCTP transport for inbound message handling is at risk. This includes telecom infrastructure, signaling gateways, and custom protocol servers that rely on SCTP. Applications using only TCP or UDP transports are not affected.

Exploitability

Exploitability is high. No authentication, user interaction, or special network position is required—an attacker on the network can send malformed SCTP packets directly to a listening Netty SCTP server. The attack is deterministic and does not depend on race conditions or heap state. Proof-of-concept exploitation is straightforward: open multiple SCTP streams and send single-byte fragments with the complete flag unset repeatedly. Public tooling for SCTP packet crafting exists, lowering the barrier to weaponization.

Remediation

Upgrade netty-transport-sctp to version 4.1.135.Final (for the 4.1.x series) or 4.2.15.Final (for the 4.2.x series) or later. The patch modifies the fragment reassembly to avoid creating new composite buffers for each fragment and likely adds limits on nesting depth or total fragment count. Verify your dependency tree to confirm netty-transport-sctp is updated; it may be a transitive dependency pulled in by other libraries.

Patch guidance

Identify your current Netty version by checking your build configuration (Maven pom.xml, Gradle build.gradle, or equivalent) and runtime classpath. If using 4.1.x, upgrade to 4.1.135.Final or later. If using 4.2.x, upgrade to 4.2.15.Final or later. Test the upgrade in a staging environment to confirm compatibility with your SCTP protocol implementation. Review release notes for any breaking changes. If you cannot upgrade immediately, consider network-level mitigations: restrict SCTP access to trusted peers only, or disable SCTP if it is not actively used.

Detection guidance

Monitor Netty process memory usage for unexplained growth when handling SCTP traffic. Watch for stack traces mentioning CompositeByteBuffer and recursion depth warnings. If SCTP is used, log or monitor stream creation and fragment arrival rates; sudden spikes in the number of open streams or incomplete fragments from a single peer are red flags. Network-level detection is challenging without protocol-aware inspection, but you can alert on unusual SCTP traffic patterns (many small packets with the complete flag unset) if your monitoring tools support deep packet inspection.

Why prioritize this

This vulnerability scores 7.5 (HIGH) on CVSS v3.1 because it enables unauthenticated remote denial of service with no user interaction required. The attack surface is the SCTP listener itself, reachable from the network. Although confidentiality and integrity are unaffected, availability impact is severe. Organizations running SCTP-dependent services should patch promptly. The fact that it is not yet tracked as KEV does not diminish urgency; KEV inclusion tends to lag publication and does not reflect real-world exploitation risk.

Risk score, explained

CVSS 3.1 score of 7.5 reflects: network-accessible attack vector (AV:N), low attack complexity (AC:L), no privileges or user interaction required (PR:N, UI:N), and high availability impact (A:H). The vulnerability does not compromise confidentiality or integrity, so C and I scores are zero. The scope is unchanged (S:U). The high score is appropriate for a remotely-triggered denial-of-service vulnerability in a core networking library.

Frequently asked questions