CVE-2026-69185

What it actually does

Socket.IO server versions before 4.2.7, 3.4.5, and 3.3.6 can be forced to allocate and retain excessive memory when processing a specially crafted Socket.IO binary packet that declares a large number of expected binary attachments. Because exploitation is network-accessible, low-complexity, requires no authentication, and does not require user interaction, an exposed Socket.IO endpoint can be driven into memory exhaustion, causing process crashes, service instability, or full denial of service. The impact is availability-only; the vulnerability does not directly provide confidentiality or integrity compromise.

Why it matters to the business

Applications that rely on vulnerable Socket.IO servers for real-time messaging, collaboration, notifications, dashboards, chat, gaming, or event streaming may become unavailable or unstable during an attack. The issue has a high availability CVSS score but currently has low EPSS likelihood, no known CISA KEV listing, no ransomware association, and no reported mature public exploitation in the supplied data. Because the issue is recently published, organizations should still prioritize internet-facing or business-critical Socket.IO services, especially where automatic restart loops or memory limits could cause cascading outages.

How an attack unfolds

An attacker first identifies an application endpoint using Socket.IO, commonly over WebSocket or HTTP long-polling. The attacker establishes a Socket.IO session and sends a malformed or abusive binary packet that claims a very large number of binary attachments are expected. Vulnerable Socket.IO versions trust this attachment count sufficiently to wait for and buffer attachment-related state. By repeating this behavior across one or more connections, the attacker can steadily increase memory pressure on the Node.js process. Once memory is exhausted or garbage collection cannot recover quickly enough, the process may crash, become unresponsive, or be restarted repeatedly by a supervisor, producing an application-level denial of service.

How to fix it

Upgrade Socket.IO to a fixed release: 4.x users should upgrade to 4.2.7 or later, 3.4.x users should upgrade to 3.4.5 or later, and 3.3.x users should upgrade to 3.3.6 or later. If direct upgrade is delayed, reduce exposure by restricting access to Socket.IO endpoints, enforcing authentication before expensive real-time workflows, applying connection and message rate limits at the reverse proxy or application layer, setting conservative request/body/message limits where supported, and running Node.js services with memory limits plus supervised restarts to contain impact. Mitigations should be treated as temporary because the root flaw is in vulnerable Socket.IO packet handling.

How to confirm the fix worked

Confirm the deployed Socket.IO server package version is fixed by inspecting application dependency manifests and runtime dependency trees, for example package-lock.json, yarn.lock, pnpm-lock.yaml, npm ls socket.io, yarn why socket.io, or pnpm why socket.io. Verify that production artifacts and containers were rebuilt with the upgraded dependency, not only the source repository. For externally exposed applications, confirm that /socket.io/ endpoints are either upgraded, protected, or intentionally inaccessible. During safe testing, monitor process memory while exercising normal Socket.IO binary messaging; memory should not grow unbounded when malformed or incomplete binary attachment sequences are rejected or safely handled. Also confirm crash loops and out-of-memory events stop after the upgrade.

Typical attack path

1. Discover a public or reachable Socket.IO endpoint, often under a path such as /socket.io/.
2. Negotiate a Socket.IO transport using WebSocket or HTTP long-polling.
3. Send a crafted Socket.IO binary packet that declares an excessive number of binary attachments.
4. Keep the connection open, repeat the packet, or open additional concurrent sessions to increase memory retention.
5. Trigger excessive heap growth, garbage collection pressure, process crashes, or application restarts.
6. Maintain the attack to keep the real-time service unavailable or degraded.

How to detect it

Look for signs of prior denial-of-service activity rather than data theft. Relevant sources include reverse proxy access logs, load balancer logs, WAF logs, application logs, Socket.IO debug logs if enabled, Node.js process logs, container/orchestrator events, host memory telemetry, and APM traces. Investigate periods with spikes in /socket.io/ requests, abnormal WebSocket upgrades, many short-lived or long-held connections, repeated malformed packet/parser errors, high Node.js heap usage, garbage collection saturation, out-of-memory terminations, process restarts, HTTP 502/503/504 responses, or Kubernetes/container OOMKilled events. Network captures or full request logs may show Socket.IO binary packet payloads beginning with binary event or binary acknowledgement markers followed by an unusually large attachment count. Because exploit maturity is reported as none and EPSS is low, prioritize correlation: suspicious Socket.IO traffic followed closely by memory exhaustion or service restart is the strongest indicator.

• /socket.io/
• transport=websocket
• transport=polling
• EIO=3
• EIO=4
• Upgrade: websocket
• OOMKilled
• JavaScript heap out of memory
• FATAL ERROR: Reached heap limit Allocation failed - JavaScript heap out of memory
• FATAL ERROR: Ineffective mark-compacts near heap limit Allocation failed - JavaScript heap out of memory
• signal: killed
• exit code 137
• HTTP 503
• HTTP 502
• HTTP 504
• Socket.IO packet payload matching regex: ^5[0-9]{6,}-
• Socket.IO packet payload matching regex: ^6[0-9]{6,}-

What your security team should do

• Inventory applications, containers, and services that include the Socket.IO server package, prioritizing internet-facing and business-critical real-time services.
• Upgrade vulnerable Socket.IO deployments to 4.2.7, 3.4.5, 3.3.6, or later as appropriate for the deployed major/minor line.
• Add or verify rate limiting, connection limits, and request/message size controls for /socket.io/ traffic at reverse proxies, gateways, and application layers.
• Review recent availability incidents, out-of-memory crashes, and abnormal Socket.IO traffic since publication on 2026-08-03, especially for exposed services.
• Add monitoring alerts for sudden increases in Socket.IO connection counts, malformed packet errors, Node.js heap usage, garbage collection pressure, and process restarts.
• Ensure runtime supervisors, orchestration platforms, and memory limits are configured to contain single-process failure without causing broader service instability.
• Track vendor advisories and dependency scanner results, but do not wait for KEV listing or EPSS movement before patching exposed production services.