CVE-2024-38355

What it actually does

The flaw is a remotely triggerable denial-of-service condition in Socket.IO servers. A specially crafted Socket.IO packet can reach error-handling paths that throw an uncaught exception. In typical Node.js deployments, an uncaught exception terminates the Node.js process, which can immediately drop active real-time connections and make the Socket.IO service unavailable until a supervisor, container orchestrator, or process manager restarts it. The issue is network-accessible, low-complexity, and does not require authentication or user interaction where the Socket.IO endpoint is exposed.

Why it matters to the business

Applications that rely on Socket.IO for real-time features such as chat, collaboration, live dashboards, notifications, multiplayer interactions, or device telemetry can experience abrupt outages or degraded service. Even if automatic restarts are configured, repeated malicious packets can cause crash loops, user disconnects, lost session state, increased support volume, and reduced confidence in the service. This issue is not listed in CISA KEV and currently has low EPSS likelihood, but because exploitation is unauthenticated and simple once an exposed endpoint is found, internet-facing Socket.IO services should still be upgraded during normal vulnerability remediation cycles.

How an attack unfolds

An attacker first identifies an application exposing a Socket.IO endpoint, commonly over HTTP or WebSocket paths associated with Socket.IO. The attacker then establishes or attempts a Socket.IO/Engine.IO connection and sends a malformed or specially crafted packet designed to trigger the vulnerable parser or packet handling logic. On vulnerable versions, the server throws an exception that is not caught by application or framework error handling. In Node.js, this uncaught exception can terminate the running process. If the application is managed by a restart mechanism, the attacker can repeatedly send the packet to keep the service unstable or in a crash loop. Successful exploitation primarily impacts availability, though abrupt process termination may also interrupt in-flight operations and produce partial transactions depending on application design.

How to fix it

Upgrade Socket.IO to a fixed release. The advisory states the fix is included in socket.io@4.6.2 and was also backported to the 2.x branch; the provided source-level fixed commit is 88b2cdb6abd38d6466fa4360748f2f67d8837ad4. Where dependency manifests are used, update the direct Socket.IO dependency and regenerate lockfiles so transitive packages resolve to fixed versions. Rebuild and redeploy affected Node.js services after the dependency update. If immediate upgrade is not possible, add an application-level listener for the Socket.IO "error" event to catch and handle these errors, and ensure Node.js processes are supervised by a process manager or orchestrator with rate-limited restarts. Restrict public exposure of Socket.IO endpoints where possible, require authentication as early in the connection flow as feasible, and use reverse-proxy or WAF rate limiting to reduce repeated crash attempts.

How to confirm the fix worked

Confirm the deployed dependency version is fixed by checking package.json, package-lock.json, yarn.lock, pnpm-lock.yaml, npm ls socket.io, yarn why socket.io, or equivalent software composition analysis output. For 4.x deployments, verify socket.io is at least 4.6.2. For source-based deployments, verify the fixed commit is present or that the relevant backport has been applied. Confirm running containers or serverless bundles were rebuilt after the dependency update rather than only changing source manifests. Validate that Socket.IO error handlers are registered if relying on mitigation. In staging, perform negative testing with malformed Socket.IO packets or a regression test derived from the advisory to confirm malformed input is handled without terminating the Node.js process. Operationally, verify that malformed Socket.IO traffic no longer produces uncaughtException events, process exits, container restarts, or service-level disconnect spikes.

Typical attack path

1. Discover an application exposing a Socket.IO service or endpoint over HTTP/WebSocket.
2. Determine that the endpoint accepts Socket.IO traffic and is reachable without authentication or before authentication is enforced.
3. Send a specially crafted Socket.IO packet that triggers the vulnerable exception path.
4. Cause an uncaught exception in the Socket.IO server process.
5. Force the Node.js process to terminate, dropping active real-time connections.
6. Repeat the request to create recurring outages or crash loops if the process is automatically restarted.

How to detect it

Look for evidence of unexpected Node.js process termination following Socket.IO traffic. Relevant sources include application logs, Node.js stderr/stdout, process manager logs such as PM2 or systemd, container runtime and Kubernetes events, reverse-proxy access logs, WAF logs, load balancer logs, and APM traces. Hunt for uncaught exceptions, stack traces involving Socket.IO packet parsing or packet handling, abrupt process exits, crash loops, and spikes in 4xx/5xx responses or WebSocket disconnects around requests to Socket.IO endpoints. In network and web logs, focus on unusual requests to /socket.io/ or Engine.IO query parameters such as EIO and transport, especially malformed polling or websocket traffic immediately preceding application restarts. Because public exploit maturity is not established and no specific threat actor activity is noted, detection should be behavior-based rather than relying on a single payload signature.

• /socket.io/
• EIO=
• transport=polling
• transport=websocket
• uncaughtException
• Unhandled 'error' event
• Error: packet
• socket.io-parser
• engine.io-parser
• Node.js process exited
• Process exited with code 1
• PM2 App [
• exited with code [1]
• systemd: Main process exited
• CrashLoopBackOff
• Back-off restarting failed container
• container restart count
• WebSocket connection closed unexpectedly

What your security team should do

• Inventory internet-facing and partner-facing applications using Socket.IO, including transitive use through application frameworks.
• Prioritize upgrade of exposed Socket.IO services to socket.io@4.6.2 or a vendor-confirmed fixed 2.x backport; verify lockfiles and deployed artifacts, not only source manifests.
• Add or verify Socket.IO "error" event handling and Node.js process-level monitoring for uncaught exceptions as defense in depth.
• Apply rate limiting and anomaly detection on Socket.IO and Engine.IO endpoints, especially paths such as /socket.io/.
• Monitor process restarts, container crash loops, and real-time connection drops for signs of attempted exploitation.
• If repeated crashes are observed, preserve application logs, process manager logs, reverse-proxy access logs, and packet samples before redeploying or rotating instances.
• Treat this as a high-availability remediation item for applications where real-time connectivity is customer-critical, even though it is not currently KEV-listed and has low EPSS.