Skip to content

← Public intelligence

Maven package

io.netty:netty-transport-sctp

Open actionable advisories and recorded vendor fixes. This public package view has no inventory attached and cannot establish whether your deployment is affected. A vendor fix never resolves your finding; verify your installed version and the source guidance.

Open advisories

2 actionable advisories, newest first. Withdrawn advisories and news are excluded. Coverage is partial.

  1. High, CVSS 7.5MavenAmendedPublished

    Netty: Memory Exhaustion in SctpMessageCompletionHandler

    CVE-2026-59902 · GHSA-2qj4-mmr9-4v2f

    Affected
    • Maven io.netty:netty-transport-sctp >= 4.2.0.Final, <= 4.2.16.Final; <= 4.1.136.Final
    Fixed in
    4.2.17.Final4.1.137.Final· Vendor fix available
    Issue
    SctpMessageCompletionHandler does not limit the total size of buffered fragments, allowing an unauthenticated attacker to cause an OutOfMemoryError by sending large SCTP fragments. Details io.netty.handler.codec.sctp.SctpMessageCompletionHandler buffers fragments for incomplete SCTP messages. The fix for CVE-2026-46340 fixed unbounded memory growth by introducing limits on the number of concurrent incomplete messages (maxIncompleteSctpMessages) and the number of fragments per message (maxFragments). While the count of fragments is now bounded, the handler still does not enforce a maximum size in bytes. With the default limits of 128 messages and 128 fragments, and a typical max SCTP chunk size of 64KB, an attacker can consume up to ~1GB per connection. By opening a small number of concurrent connections, an attacker can easily exhaust the server's memory, causing an OutOfMemoryError. Impact Memory Exhaustion. Any application using Netty's SCTP transport with…

    Recommended action: Upgrade to 4.2.17.Final or 4.1.137.Final by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.

    Sources:osv.dev (1)github.com (2)Source checked Evidence →
  2. High, CVSS 7.5MavenPublished

    Netty: SCTP reassembly nests buffers without bound

    CVE-2026-46340 · GHSA-5xrh-qmmq-w6ch

    Affected
    • Maven io.netty:netty-transport-sctp >= 4.2.0.Final, <= 4.2.14.Final; <= 4.1.134.Final
    Fixed in
    4.2.15.Final4.1.135.Final· Vendor fix available
    Issue
    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.

    Recommended action: Upgrade to 4.2.15.Final or 4.1.135.Final by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.

    Sources:github.comSource checked Evidence →