Skip to main content

Netty SCTP Transport CVE-2026-46340

| EUVDEUVD-2026-36451 HIGH
Allocation of Resources Without Limits or Throttling (CWE-770)
2026-06-08 https://github.com/netty/netty GHSA-5xrh-qmmq-w6ch
Denial Of Service
7.5
CVSS 3.1 · Vendor: https://github.com/netty/netty
Share

Severity by source

Vendor (https://github.com/netty/netty) PRIMARY
7.5 HIGH
AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
SUSE
HIGH
qualitative
Red Hat
7.5 HIGH
qualitative

Primary rating from Vendor (https://github.com/netty/netty).

CVSS VectorVendor: https://github.com/netty/netty

CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
Attack Vector
Network
Attack Complexity
Low
Privileges Required
None
User Interaction
None
Scope
Unchanged
Confidentiality
None
Integrity
None
Availability
High

Lifecycle Timeline

2
Source Code Evidence Fetched
Jun 08, 2026 - 23:32 vuln.today
Analysis Generated
Jun 08, 2026 - 23:32 vuln.today

Blast Radius

ecosystem impact
† from your stack dependencies † transitive graph · vuln.today resolves 4-path depth
  • 75 maven packages depend on io.netty:netty-transport-sctp (3 direct, 72 indirect)

Ecosystem-wide dependent count for version 4.2.0.Final.

DescriptionCVE.org

For each non-complete SctpMessage fragment the handler does fragments.put(streamId, Unpooled.wrappedBuffer(frag, byteBuf)), wrapping the previous accumulator and the new slice into a *new* CompositeByteBuf every time. After N fragments the accumulator is an N-deep chain of composites, each holding references and component arrays; readableBytes()/getBytes() on the final buffer recurse N levels. There is no limit on N, on total bytes, or on the number of streamIdentifiers an attacker can open (each gets its own map entry). A peer that never sets the complete flag can grow this structure indefinitely from tiny 1-byte DATA chunks.

AnalysisAI

Memory exhaustion denial-of-service in Netty's netty-transport-sctp module (versions <= 4.1.134.Final and 4.2.0.Final through 4.2.14.Final) allows remote unauthenticated attackers to crash JVM processes by sending unbounded SCTP DATA fragments that never set the complete flag. The flaw stems from the SCTP reassembly handler wrapping each new fragment into a fresh CompositeByteBuf around the prior accumulator, producing an N-deep recursive buffer chain that consumes memory and CPU per access, with no public exploit identified at time of analysis.

Technical ContextAI

The vulnerability resides in Netty's SCTP (Stream Control Transmission Protocol) transport handler, which reassembles fragmented SctpMessage payloads keyed by streamIdentifier in a per-channel map. For each incoming non-complete fragment, the handler calls Unpooled.wrappedBuffer(previousAccumulator, newSlice), producing a new CompositeByteBuf that nests the previous composite as a component. Operations such as readableBytes() and getBytes() then traverse this linked structure recursively, scaling linearly with N fragments. Because the affected CPEs are pkg:maven/io.netty:netty-transport-sctp, only applications that explicitly use SCTP transport (a niche choice typical of telecom/signaling stacks) are exposed. The root cause maps to CWE-770 (Allocation of Resources Without Limits or Throttling): no cap on fragments per stream, total bytes accumulated, or number of distinct streamIdentifiers a single peer may open.

RemediationAI

Upgrade io.netty:netty-transport-sctp to vendor-released patch 4.1.135.Final for the 4.1.x branch or 4.2.15.Final for the 4.2.x branch, as documented at https://github.com/netty/netty/releases/tag/netty-4.1.135.Final and https://github.com/netty/netty/releases/tag/netty-4.2.15.Final and the advisory at https://github.com/netty/netty/security/advisories/GHSA-5xrh-qmmq-w6ch. If immediate upgrade is not possible, compensating controls include restricting SCTP peers via firewall ACLs or IPsec to only known signaling partners, terminating SCTP at an upstream gateway that enforces fragment and stream limits, or removing the SctpMessageCompletionHandler from the pipeline if application-level reassembly is not required (this will surface raw fragments to downstream handlers, which must then enforce their own limits). Operators may also set strict JVM heap and direct-memory limits with monitoring and auto-restart so a single misbehaving peer cannot indefinitely starve other tenants, though this only contains rather than prevents the DoS.

Same weakness CWE-770 – Allocation of Resources Without Limits or Throttling

View all
CVE-2017-8779 HIGH POC
7.5
CVE-2025-53521 CRITICAL POC
9.3
CVE-2017-5850 HIGH POC
7.5
CVE-2025-26682 HIGH
7.5
CVE-2025-26466 MEDIUM
5.9
CVE-2020-37067 CRITICAL POC
9.8
CVE-2021-47875 CRITICAL POC
9.8
CVE-2023-38507 CRITICAL POC
9.8

Same technique Denial Of Service

View all
CVE-2015-5119 CRITICAL POC
9.8
CVE-2011-2462 CRITICAL POC
9.8
CVE-2011-0611 HIGH POC
8.8
CVE-2012-1889 HIGH POC
8.8
CVE-2012-0507 CRITICAL POC
9.8
CVE-2014-1761 HIGH POC
7.8
CVE-2015-5122 CRITICAL POC
9.8
CVE-2011-0609 HIGH POC
7.8

Vendor StatusVendor

SUSE

Severity: Important
Product Status
openSUSE Tumbleweed Fixed
SUSE Linux Enterprise High Performance Computing 15 SP4-ESPOS Affected
SUSE Linux Enterprise High Performance Computing 15 SP4-LTSS Affected
SUSE Linux Enterprise High Performance Computing 15 SP5-ESPOS Affected
SUSE Linux Enterprise High Performance Computing 15 SP5-LTSS Affected

Share

CVE-2026-46340 vulnerability details – vuln.today
Back

This site uses cookies essential for authentication and security. No tracking or analytics cookies are used. Privacy Policy