Skip to main content
CVE Vulnerability Database
Vulnerability Database/CVE-2026-69185

CVE-2026-69185: Socket.IO DoS Vulnerability

CVE-2026-69185 is a denial of service vulnerability in Socket.IO that allows attackers to exhaust server memory through malicious packets. This article covers the technical details, affected versions, and mitigation steps.

Published:

CVE-2026-69185 Overview

CVE-2026-69185 is a memory exhaustion vulnerability in Socket.IO, a library that enables bidirectional and low-latency communication across platforms. A specially crafted Socket.IO packet can force the server to wait for a large number of binary attachments and buffer them in memory. An unauthenticated remote attacker can exploit this behavior to consume all available memory on the server, resulting in a denial-of-service condition. The flaw is classified under [CWE-20] Improper Input Validation and affects the socket.io-parser component. Maintainers fixed the issue in versions 4.2.7, 3.4.5, and 3.3.6.

Critical Impact

Unauthenticated attackers can send malformed binary packets over the network to exhaust server memory and take Socket.IO-backed services offline.

Affected Products

  • Socket.IO versions prior to 4.2.7 (4.x branch)
  • Socket.IO versions prior to 3.4.5 (3.4.x branch)
  • Socket.IO versions prior to 3.3.6 (3.3.x branch)

Discovery Timeline

  • 2026-08-03 - CVE-2026-69185 published to the National Vulnerability Database (NVD)
  • 2026-08-03 - Last updated in NVD database

Technical Details for CVE-2026-69185

Vulnerability Analysis

Socket.IO transmits binary data using a two-phase protocol. The client first sends a JSON header packet declaring the number of binary attachments that will follow. The server then instantiates a BinaryReconstructor and buffers incoming binary chunks until the declared count is reached. The parser did not validate the attachment count against a sane upper bound, nor did it correctly handle the special zero-attachment case. An attacker can send a header packet declaring an arbitrarily large number of expected attachments. The server allocates a reconstruction context and holds it open indefinitely, waiting for binary data that may never arrive. Repeating this pattern across many connections drives the process to out-of-memory conditions.

Root Cause

The root cause resides in the socket.io-parser decoder logic. When a binary event or binary acknowledgement packet was decoded, the parser created a BinaryReconstructor instance regardless of whether the declared attachment count was legitimate. The pre-patch code only shortcut-emitted a decoded event when attachments === 0, but it did not reject binary-labeled packets that carried nonsensical attachment counts. This missing input validation allowed a malicious client to influence server-side buffering behavior directly from the wire format.

Attack Vector

The attack is network-based and requires no authentication or user interaction. An attacker connects to a Socket.IO endpoint and issues one or more crafted binary packets with a header declaring a high attachments value. Each such packet causes the server to allocate a reconstruction state and hold references to received chunks. Because the server waits for remaining attachments before releasing memory, an attacker can multiply this cost across many parallel connections until the Node.js process crashes.

The upstream fix removes the flawed zero-attachment shortcut and hardens the parser against binary packets that lack valid attachments. The patched code path is shown below.

typescript
        packet.type = isBinaryEvent ? PacketType.EVENT : PacketType.ACK;
        // binary packet's json
        this.reconstructor = new BinaryReconstructor(packet);
-
-        // no attachments, labeled binary but no binary data to follow
-        if (packet.attachments === 0) {
-          super.emitReserved("decoded", packet);
-        }
      } else {
        // non-binary full packet
        super.emitReserved("decoded", packet);

Source: socketio/socket.io commit 7c6ef57

Equivalent fixes were backported to the 3.x branches in commit 9c6323e and commit ced94ff.

Detection Methods for CVE-2026-69185

Indicators of Compromise

  • Sudden growth in resident memory of Node.js processes hosting Socket.IO endpoints, followed by out-of-memory termination or unresponsive workers.
  • Elevated counts of open WebSocket or long-poll connections with idle binary-reconstruction state on the server.
  • Application logs showing repeated inbound binary event packets from a small set of source addresses without corresponding binary payload chunks.

Detection Strategies

  • Inspect Socket.IO parser telemetry for packets declaring high attachments values relative to normal client behavior.
  • Correlate spikes in heap usage on Socket.IO worker processes with connection-level events from network flow logs.
  • Monitor process supervisors (PM2, systemd, Kubernetes) for repeated Node.js restarts caused by OOM killer activity on hosts running vulnerable versions.

Monitoring Recommendations

  • Instrument Socket.IO servers with per-connection memory accounting and alert when reconstruction state persists beyond a configured threshold.
  • Enable Node.js heap snapshots on OOM events and retain them for forensic review.
  • Forward web-tier and application logs to a centralized data lake for correlation of connection sources, packet patterns, and process crashes.

How to Mitigate CVE-2026-69185

Immediate Actions Required

  • Upgrade socket.io-parser and Socket.IO to a patched release: 4.2.7 for the 4.x branch, 3.4.5 for 3.4.x, or 3.3.6 for 3.3.x.
  • Audit dependency trees with npm ls socket.io socket.io-parser to identify transitive installations of vulnerable versions.
  • Restart Node.js worker processes after upgrading to ensure no lingering reconstruction state remains in memory.

Patch Information

The Socket.IO maintainers published the GHSA-2m8v-j782-fhvr advisory describing the fix. The parser now rejects binary packets that declare zero or invalid attachment counts, closing the memory-exhaustion path. Deploy the upgrade across all Socket.IO servers, including those behind reverse proxies and load balancers.

Workarounds

  • If immediate upgrade is not possible, place a rate-limiting reverse proxy in front of Socket.IO endpoints to cap connection volume per source IP.
  • Enforce strict per-process memory limits using container runtime constraints or --max-old-space-size so a single crashed worker does not exhaust the host.
  • Restrict Socket.IO endpoints to authenticated clients where feasible, reducing the pool of actors able to send malformed packets.
bash
# Upgrade Socket.IO to a patched release
npm install socket.io@^4.2.7

# Or, for the 3.x branches
npm install socket.io@^3.4.5
npm install socket.io@^3.3.6

# Verify installed versions in the dependency tree
npm ls socket.io socket.io-parser

Disclaimer: This content was generated using AI. While we strive for accuracy, please verify critical information with official sources.

Default Legacy - Prefooter | Experience the World’s Most Advanced Cybersecurity Platform

Experience the Most Advanced Cybersecurity Platform

See how the world’s most intelligent, autonomous cybersecurity platform can protect your organization today and into the future.