Which versions of ws are affected by CVE-2026-62389?

The ws WebSocket library for Node.js (versions before 8.21.1) has a critical availability risk: unauthenticated attackers can remotely trigger memory exhaustion and crash affected applications.. A patch is available.

How to fix or mitigate CVE-2026-62389?

Within 24 hours, inventory all applications and services using ws library versions prior to 8.21.1 and assess production exposure. Within 7 days, upgrade affected deployments to ws 8.21.1 or later, conducting staged updates in non-production environments first to validate stability and performance impact. Within 30 days, complete production deployment of the patched version, establish memory usage monitoring on WebSocket handlers, and verify through load testing that the DoS vector is eliminated.

ws CVE-2026-62389

Q: What is the CVSS score of CVE-2026-62389?

CVE-2026-62389 has a CVSS 4.0 base score of 8.7 (High). CVSS vector: CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X. EPSS exploitation probability: 0.4%.

EUVD-2026-44729 HIGH

Allocation of Resources Without Limits or Throttling (CWE-770)

2026-07-15 VulnCheck

GHSA-73jw-fp74-p77x

Denial Of Service Ws Websockets

8.7

CVSS 4.0 · Vendor: VulnCheck

Severity by source

Vendor (VulnCheck) PRIMARY

8.7 HIGH

CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X

vuln.today AI

7.5 HIGH

Network-reachable, no authentication or interaction, and trivial to trigger (AV:N/AC:L/PR:N/UI:N); impact is availability-only heap exhaustion, so C:N/I:N/A:H with unchanged scope.

3.1 AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H

4.0 AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N

Primary rating from Vendor (VulnCheck).

CVSS VectorVendor: VulnCheck

Attack Vector

Network

Attack Complexity

Low

Privileges Required

None

User Interaction

None

Scope

Lifecycle Timeline

Source Code Evidence Fetched

Jul 15, 2026 - 17:48 vuln.today

Analysis Generated

Jul 15, 2026 - 17:48 vuln.today

CVE Published

Jul 15, 2026 - 17:04 cve.org

HIGH 8.7

DescriptionCVE.org

ws before 8.21.1 contains a memory exhaustion vulnerability in lib/receiver.js where the fragment guard only triggers when fragment count reaches maxFragments, allowing attackers to exhaust memory by sending incomplete fragmented WebSocket messages. Attackers can send a text frame with FIN=0 followed by continuation frames without completing the sequence, causing each fragment to be stored as a separate Buffer object with significant overhead, enabling denial of service through heap exhaustion.

AnalysisAI

Denial of service in the ws WebSocket library for Node.js (versions before 8.21.1) allows remote unauthenticated attackers to exhaust server heap memory by opening fragmented messages that are never completed. Because the fragment guard in lib/receiver.js only fires when the fragment count reaches maxFragments, an attacker can stream continuation frames (starting with a text frame carrying FIN=0) indefinitely, and each fragment is retained as a separate Buffer with per-object overhead until the process runs out of memory. No public exploit has been identified at time of analysis, and the flaw was disclosed by VulnCheck with a vendor patch already available.

Technical ContextAI

ws is the de facto WebSocket client/server implementation for Node.js, used directly and as a transitive dependency of frameworks such as Socket.IO. The vulnerability lives in the receiver state machine (lib/receiver.js) that reassembles fragmented WebSocket data messages, a mechanism defined by RFC 6455 in which a message can be split across an initial frame with FIN=0 plus one or more continuation frames. The root cause is CWE-770 (Allocation of Resources Without Limits or Throttling): the limit check for buffered fragments was only evaluated when the accumulated count actually reached the maxFragments threshold, and empty fragments were not counted, so a peer that sends many small or empty incomplete fragments without ever setting FIN=1 accumulates unbounded per-fragment Buffer objects. Each stored Buffer carries fixed allocation overhead, so the effective memory cost is amplified well beyond the raw payload bytes, turning modest network input into large heap growth.

RemediationAI

Vendor-released patch: upgrade ws to version 8.21.1 or later, which counts empty fragments toward the limit and reduces the default values of the maxBufferedChunks and maxFragments options (fix commit f197ac65140920bdcecdab74bfc69c2d7858e55d; release notes at https://github.com/websockets/ws/releases/tag/8.21.1). Applications that pull ws transitively should rebuild their dependency tree (for example via npm update or a lockfile bump) to ensure the resolved ws version is 8.21.1+. If an immediate upgrade is not possible, explicitly set a conservative maxFragments (and maxBufferedChunks) value when constructing the WebSocket server so incomplete fragmented messages are rejected early - the trade-off is that legitimately large legitimately-fragmented messages may be cut off, so tune the limit to your real message sizes. As additional compensating controls, place WebSocket endpoints behind a reverse proxy or gateway that enforces per-connection message-size and idle timeouts and cap concurrent connections per client IP; the side effect is potential disruption to long-lived or high-throughput WebSocket clients. Reference the VulnCheck advisory (https://www.vulncheck.com/advisories/ws-default-maxfragments-allows-memory-exhaustion-dos) for confirmation.