CVE-2026-48779 Overview
CVE-2026-48779 is a memory exhaustion denial-of-service vulnerability in ws, the widely used open-source WebSocket client and server library for Node.js. A remote peer can transmit a high volume of exceptionally small WebSocket fragments and data chunks over a connection with modest network throughput. Each fragment forces the receiver to allocate structural wrappers that consume far more memory than the documented message-size limit suggests. The target process eventually terminates from an out-of-memory (OOM) condition. The flaw is tracked as [CWE-400] Uncontrolled Resource Consumption and affects every release branch of ws prior to the fixed versions.
Critical Impact
Unauthenticated network attackers can crash Node.js services using ws by sending crafted micro-fragmented WebSocket traffic, causing process termination and service outage.
Affected Products
- ws versions 1.1.0 up to (but not including) 5.2.5
- ws versions 6.0.0 up to (but not including) 6.2.4
- ws versions 7.0.0 up to (but not including) 7.5.11, and 8.0.0 up to (but not including) 8.21.0
Discovery Timeline
- 2026-06-17 - CVE-2026-48779 published to NVD
- 2026-06-17 - Last updated in NVD database
Technical Details for CVE-2026-48779
Vulnerability Analysis
The ws library accepts WebSocket frames according to RFC 6455, which permits messages to be split into many fragments. The library tracks per-fragment state using JavaScript object wrappers and buffer references in its receive pipeline. An attacker exploits this bookkeeping by sending a sustained stream of tiny fragments and data chunks. The aggregate payload may stay well under any configured maxPayload limit, yet the per-fragment metadata, queue entries, and V8 heap structures balloon the resident memory footprint. The Node.js process exhausts its heap and the runtime terminates the worker. Because ws underpins frameworks such as Socket.IO and many real-time backends, a single misbehaving peer can disrupt collaborative applications, trading systems, and chat infrastructure.
Root Cause
The receiver path measured limits against payload bytes rather than against the cumulative cost of allocator objects produced per fragment. The fix, applied in commits 86d3e8a, b5372ac, bca91ad, and fd36cd8, constrains the structural overhead and rejects abusive fragmentation patterns before allocation amplification occurs.
Attack Vector
The attack requires only network reach to a WebSocket endpoint built on a vulnerable ws version. No authentication, user interaction, or elevated privileges are needed. An attacker opens a standard WebSocket handshake, then streams continuation frames carrying single-byte or empty payload chunks at a steady rate. The server allocates fragment objects faster than the garbage collector can reclaim them, and the Node.js process is killed by the OOM killer or V8's own fatal allocation handler. See the ws security advisory GHSA-96hv-2xvq-fx4p for additional technical context.
Detection Methods for CVE-2026-48779
Indicators of Compromise
- Node.js workers crashing with FATAL ERROR: Reached heap limit Allocation failed - JavaScript heap out of memory shortly after a long-lived WebSocket connection is established.
- WebSocket connections from a single source IP that remain open while transmitting unusually high frame counts with very low aggregate byte counts.
- Sudden growth in process resident set size (RSS) on Node.js services exposing /ws or /socket.io endpoints without a corresponding rise in application throughput.
Detection Strategies
- Inventory Node.js applications and identify dependencies on ws using npm ls ws or software composition analysis tooling, flagging any version below 5.2.5, 6.2.4, 7.5.11, or 8.21.0.
- Instrument WebSocket servers to log frame counts per connection and alert when the frame-to-byte ratio exceeds a baseline threshold.
- Correlate Node.js process restarts with reverse proxy logs to identify the originating client IPs of suspect WebSocket sessions.
Monitoring Recommendations
- Track per-process heap usage and OOM kill events on hosts running Node.js WebSocket workloads.
- Forward application and reverse-proxy logs to a centralized analytics platform and build dashboards for WebSocket connection lifetime, frame count, and abort reasons.
- Establish alerting on repeated unexpected Node.js worker restarts within a short time window.
How to Mitigate CVE-2026-48779
Immediate Actions Required
- Upgrade ws to 5.2.5, 6.2.4, 7.5.11, or 8.21.0 (or later) on every Node.js service that exposes WebSocket endpoints.
- Audit transitive dependencies, since libraries such as Socket.IO, Puppeteer, and various GraphQL subscription packages bundle ws.
- Restart Node.js processes after the upgrade so the patched module is loaded into memory.
Patch Information
The maintainers released fixed builds in ws versions 5.2.5, 6.2.4, 7.5.11, and 8.21.0. Refer to the GitHub Security Advisory GHSA-96hv-2xvq-fx4p and the linked commits for the exact code changes that enforce stricter limits on fragment bookkeeping.
Workarounds
- Place a WebSocket-aware reverse proxy in front of the application and enforce per-connection frame-rate and idle-timeout limits.
- Reduce the Node.js --max-old-space-size only as a containment measure to fail fast, paired with automatic restart supervision such as systemd or a container orchestrator.
- Terminate WebSocket connections that exceed a low frame-count threshold without corresponding payload bytes, using application-level middleware until patching is complete.
# Configuration example
npm install ws@^8.21.0
npm ls ws
Disclaimer: This content was generated using AI. While we strive for accuracy, please verify critical information with official sources.

