Netty EUVD-2026-60314

Exploitation requires that the target application explicitly uses Netty's SCTP transport - the io.netty:netty-transport-sctp artifact must be on the classpath and the pipeline must include io.netty.handler.codec.sctp.SctpMessageCompletionHandler. SCTP is an opt-in transport not present in standard Netty HTTP, WebSocket, or TCP configurations; the vast majority of Netty deployments do not include this component. No authentication is required, and no user interaction beyond connection establishment is needed. A further environmental constraint limits real-world exploitation: SCTP is blocked or unsupported by many cloud provider networks, container networking stacks, and stateful firewalls, which prevents exploitation unless the attacker has direct network-layer SCTP access to the server. Within qualifying deployments, no non-default server configuration is required - the vulnerability manifests under default handler settings.

The CVSS 7.5 vector (AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H) accurately characterizes the attack as network-reachable and requiring no authentication, with high availability impact - these metrics are consistent with the GHSA advisory's description. EPSS data was not provided in the input and exploitation probability cannot be quantified from available signals. The vulnerability is not listed in CISA KEV, and no public exploit code has been identified, meaning the exploitation status is 'no public exploit identified at time of analysis.' Despite the absence of a known exploit, the GHSA advisory supplies a precise, reproducible attack formula, which significantly lowers the bar for independent exploitation. Real-world priority is strongly modulated by deployment context: SCTP transport is an opt-in, non-default Netty component used primarily in telecommunications and high-reliability networking infrastructure, so the majority of Netty deployments running HTTP, WebSocket, or plain TCP pipelines are entirely unaffected. Organizations actually using SctpMessageCompletionHandler should treat this as high priority given the trivial exploitation math, while others need only confirm the artifact is absent from their dependency tree.

An unauthenticated attacker opens a small number of concurrent SCTP connections to a Netty server running SctpMessageCompletionHandler and sends 128 deliberately incomplete SCTP messages per connection, each fragmented into 128 chunks of approximately 64KB, without ever completing or closing the messages. Each connection consumes roughly 1GB of JVM heap; opening even two or three such connections drives the server into OutOfMemoryError. No public POC has been identified, but the GHSA advisory provides sufficient arithmetic detail that independent reproduction is straightforward for any network-capable developer.