CVE-2026-33151

What it actually does

This vulnerability is an unauthenticated network-exploitable denial-of-service flaw in Socket.IO packet parsing. A remote client can send a specially crafted Socket.IO packet that declares or implies a large number of binary attachments but does not complete them normally. Affected servers keep waiting for and buffering these attachments, which can cause unbounded memory growth. If enough malformed packets are sent, the Node.js process or host can exhaust available memory and crash, restart, or become unresponsive. The impact is availability loss only; the issue does not directly provide code execution, data theft, or privilege escalation.

Why it matters to the business

Applications that depend on Socket.IO for real-time communication can become unavailable if exposed to malicious clients, causing user-facing outages, dropped live sessions, failed notifications, degraded collaboration features, and operational disruption. The CVSS availability impact is high, but current public exploitation signals are low: EPSS is 0.00514, it is not listed in CISA KEV, and no mature public exploit is indicated in the provided data. Because Socket.IO is commonly used in web and mobile backends for real-time features, organizations should still prioritize remediation for internet-facing or high-traffic services.

How an attack unfolds

An attacker identifies a service that accepts Socket.IO connections, typically over HTTP long-polling or WebSocket transport. The attacker initiates a Socket.IO session and sends a crafted event packet that causes the parser to expect many binary attachments. Instead of sending a valid, bounded attachment sequence, the attacker sends incomplete or excessive attachment metadata and payload fragments that cause the server to retain buffered state in memory. Repeating this across one or many connections steadily increases memory consumption until garbage collection cannot recover enough memory, the Node.js process reaches its memory limit, the container is killed, or the host begins swapping and service responsiveness collapses. No authentication or user interaction is required when the Socket.IO endpoint is publicly reachable.

How to fix it

Upgrade affected Socket.IO parser components to patched versions. Based on the advisory, upgrade Socket.IO-related packages to versions 3.3.5, 3.4.4, or 4.2.6 as applicable to the major/minor release line in use, or to a later supported version. Because the affected product is identified as socket.io-parser, verify transitive dependency resolution as well as direct dependencies; update lockfiles and rebuild deployments so the patched parser version is actually packaged. If immediate upgrade is not possible, reduce exposure by restricting access to Socket.IO endpoints, enforcing authentication before expensive real-time interactions where feasible, applying rate limits and connection limits per source, setting conservative Node.js/container memory limits with safe restart behavior, and using a reverse proxy or WAF to throttle abnormal /socket.io/ traffic. Mitigations should be treated as temporary because the vulnerable parsing behavior remains present until patched.

How to confirm the fix worked

Confirm dependency versions in package manifests, lockfiles, container images, and deployed artifacts. For npm-based deployments, inspect package-lock.json, yarn.lock, pnpm-lock.yaml, or equivalent SBOM output for socket.io-parser and Socket.IO package versions, and verify they are at or above the patched release line: 3.3.5, 3.4.4, 4.2.6, or later supported versions. Restart services after updating and verify the running application image or artifact contains the fixed dependency, not only the source repository. From an exposure perspective, confirm whether /socket.io/ endpoints are reachable from untrusted networks and whether rate limiting, connection caps, and monitoring are active. Functional validation should include normal Socket.IO connection and event tests after upgrade; security validation may include controlled malformed-packet testing in a non-production environment while monitoring process memory to confirm it does not grow unbounded.

Typical attack path

1. Discover a web application or API endpoint exposing Socket.IO, commonly under /socket.io/.
2. Establish a Socket.IO connection using polling or WebSocket transport.
3. Send a malformed Socket.IO packet that advertises or triggers a large number of binary attachments.
4. Keep the attachment sequence incomplete or send attachment fragments in a way that forces the server to buffer state.
5. Repeat the request pattern across multiple connections or at high rate.
6. Exhaust server process memory, causing crashes, restarts, degraded performance, or service outage.

How to detect it

To determine whether exploitation may have occurred, review web server, reverse proxy, application, container runtime, orchestration, and host telemetry around periods of high memory usage or service instability. Look for unusual volumes of requests to Socket.IO endpoints, especially /socket.io/ with transport=polling or transport=websocket, many short-lived connections, repeated malformed packet handling errors, abnormal binary attachment parsing errors, and traffic from a small number of source IPs causing disproportionate memory growth. Correlate application logs showing Socket.IO parser errors or disconnect storms with Node.js heap out-of-memory messages, container OOMKilled events, process manager restarts, Kubernetes pod restarts, systemd restarts, or load balancer 502/503/504 responses. Because this is a denial-of-service condition, durable file artifacts are unlikely; detection depends primarily on traffic patterns, memory telemetry, crash logs, and restart events. If named threat actors are not known and KEV status is false, treat findings as suspicious activity or opportunistic probing unless additional evidence supports attribution.

• /socket.io/
• transport=polling
• transport=websocket
• EIO=
• OOMKilled
• JavaScript heap out of memory
• FATAL ERROR: Ineffective mark-compacts near heap limit Allocation failed - JavaScript heap out of memory
• Allocation failed - JavaScript heap out of memory
• socket.io-parser
• parser error
• many attachments
• binary attachments
• upstream prematurely closed connection
• connect ECONNRESET
• HTTP 502
• HTTP 503
• HTTP 504

What your security team should do

• Inventory all applications, containers, and services that use Socket.IO or socket.io-parser, including transitive dependencies in Node.js projects.
• Prioritize patching internet-facing real-time services and any high-availability application paths that rely on Socket.IO.
• Upgrade to patched versions 3.3.5, 3.4.4, 4.2.6, or later supported releases, and ensure lockfiles and deployed artifacts are refreshed.
• Add or tune rate limits, connection limits, and request-size controls for /socket.io/ endpoints while patches are rolled out.
• Monitor memory usage, process restarts, container OOM kills, and spikes in Socket.IO connection attempts for signs of exploitation or probing.
• Add dependency scanning or SBOM checks to CI/CD pipelines to detect vulnerable socket.io-parser versions in future builds.
• Review autoscaling and restart policies to ensure denial-of-service attempts do not cause cascading failures or excessive infrastructure cost.