CVE-2026-90584: Java-WebSocket DOS Vulnerability

CVE-2026-90584 Overview

CVE-2026-90584 is a resource allocation vulnerability [CWE-400] in the TooTallNate Java-WebSocket library through version 1.6.1. The flaw resides in the processFrameContinuousAndNonFin function within Draft_6455.java, part of the Fragmentation Handler component. A remote attacker can send crafted WebSocket fragmented frames that trigger uncontrolled resource allocation on the server side. Public exploit code is available, and a pull request to remediate the issue is pending upstream acceptance.

Critical Impact
Remote unauthenticated attackers can trigger resource exhaustion against applications embedding Java-WebSocket, affecting availability of dependent services.

Affected Products

TooTallNate Java-WebSocket versions up to and including 1.6.1
Applications embedding the vulnerable Draft_6455.java fragmentation handler
Java services exposing WebSocket endpoints built on Java-WebSocket

Discovery Timeline

2026-09-13 - CVE-2026-90584 published to NVD
2026-09-14 - Last updated in NVD database

Technical Details for CVE-2026-90584

Vulnerability Analysis

The vulnerability affects how Java-WebSocket processes continuation frames in fragmented WebSocket messages. The processFrameContinuousAndNonFin method in Draft_6455.java accumulates payload data from successive non-final frames without enforcing an upper bound on aggregate size or the count of pending fragments. An attacker can open a WebSocket session and stream continuation frames indefinitely, forcing the library to allocate buffers proportional to attacker-supplied input. The condition maps to [CWE-400] Uncontrolled Resource Consumption.

Because the attack is performed over the network with no authentication or user interaction, any exposed WebSocket endpoint built on the library becomes a target. The impact is limited to availability; confidentiality and integrity of data are not affected.

Root Cause

The fragmentation handler lacks strict limits on the cumulative payload size assembled from continuation frames. The library trusts the incoming frame sequence and continues buffering data as long as the FIN bit remains unset. Without a ceiling enforced at frame reassembly time, sustained fragment delivery leads to heap growth and eventual memory pressure or OutOfMemory conditions in the host JVM.

Attack Vector

A remote attacker connects to an exposed WebSocket endpoint and initiates a fragmented message by sending an initial frame with FIN=0. The attacker then transmits an arbitrary number of continuation frames, each also carrying FIN=0, without ever sending the final frame. The server buffers each fragment through processFrameContinuousAndNonFin, growing memory usage until the service degrades or crashes. The public exploit demonstrates this pattern against unpatched instances.

See the GitHub Java-WebSocket Issue #1508 and VulDB CVE-2026-90584 entry for reproduction details.

Detection Methods for CVE-2026-90584

Indicators of Compromise

Sustained WebSocket connections transmitting continuation frames without a terminating FIN=1 frame
Rapid JVM heap growth correlated with active WebSocket sessions on Java-WebSocket versions ≤ 1.6.1
OutOfMemoryError or garbage collection thrashing in application logs tied to the WebSocket worker threads
Unusually long-lived WebSocket sessions from a single remote source pushing large aggregate payloads

Detection Strategies

Inspect application dependency manifests (pom.xml, build.gradle) for org.java-websocket:Java-WebSocket versions at or below 1.6.1
Deploy WebSocket-aware proxies or gateways to inspect frame sequences and flag abnormally long fragment chains
Correlate JVM memory telemetry with WebSocket session metrics to identify session-level memory anomalies

Monitoring Recommendations

Monitor heap utilization, GC pause duration, and allocation rate on hosts running Java-WebSocket services
Track per-connection byte counts and fragment counts for WebSocket sessions; alert on outliers
Capture and review connection duration and source IP distributions for WebSocket endpoints exposed to the internet

How to Mitigate CVE-2026-90584

Immediate Actions Required

Inventory all Java applications and services that depend on TooTallNate Java-WebSocket 1.6.1 or earlier
Restrict exposure of WebSocket endpoints to trusted networks where feasible until a patched release is available
Apply application-layer limits on maximum message size and fragment count in code that consumes the library
Configure reverse proxies to terminate WebSocket sessions that exceed size or duration thresholds

Patch Information

At the time of publication, no fixed release is available. The upstream pull request tracked as GitHub Java-WebSocket PR #1509 is pending acceptance. Consumers should monitor the Java-WebSocket repository for a tagged release incorporating the fix and upgrade promptly once available.

Workarounds

Wrap WebSocketServer implementations with logic that enforces a maximum cumulative payload size across continuation frames and closes offending sessions
Set idle and read timeouts on WebSocket sessions to bound resource retention by any single client
Place a WebSocket-aware gateway or load balancer in front of the service to enforce message size caps and connection quotas
Constrain JVM heap and enable resource isolation (containers, cgroups) so a single service degradation does not cascade

bash

# Configuration example: enforce a per-connection fragment cap in a WebSocketServer subclass
# Pseudocode illustrating a defensive wrapper around onWebsocketMessageFragment
#
# private static final long MAX_AGGREGATE_BYTES = 1_048_576; // 1 MiB
# private final Map<WebSocket, Long> bytesSoFar = new ConcurrentHashMap<>();
#
# @Override
# public void onWebsocketMessageFragment(WebSocket conn, Framedata frame) {
#     long total = bytesSoFar.merge(conn, (long) frame.getPayloadData().remaining(), Long::sum);
#     if (total > MAX_AGGREGATE_BYTES) {
#         conn.close(CloseFrame.TOOBIG, "fragment aggregate exceeds limit");
#         bytesSoFar.remove(conn);
#         return;
#     }
#     super.onWebsocketMessageFragment(conn, frame);
# }