Socket.IO: Engine.IO Polling Transport Connection Exhaustion

Impact

An unauthenticated remote attacker can cause a denial of service in affected versions of engine.io by opening Engine.IO polling sessions and sending an invalid binary POST request with:

 1Content-Type: application/octet-stream

against an Engine.IO protocol v4 polling transport.

In the vulnerable code path, the server reports a transport error but does not properly close the HTTP response associated with the malformed request. As a result, the underlying HTTP connection may remain open, consuming one server-side socket/resource per crafted request.

An attacker can repeat this with many sessions to exhaust available HTTP connections, sockets, file descriptors, or related server resources, potentially preventing legitimate clients from connecting.

Patches

The issue was fixed in:

• engine.io 6.6.7

The fix ensures that invalid binary polling POST requests are explicitly rejected with an HTTP response and closed properly.

Users should upgrade to:

 1npm install engine.io@^6.6.7

or a later fixed version.

If using Socket.IO through the monorepo/packages, update to a Socket.IO release that depends on a fixed engine.io version.

Workarounds

If upgrading immediately is not possible, possible mitigations include:

• Block or reject polling POST requests with Content-Type: application/octet-stream for Engine.IO protocol v4 at a reverse proxy, load balancer, WAF, or application middleware.
• Disable HTTP long-polling if your deployment can use WebSocket-only transport.
• Enforce strict request/connection timeouts at the HTTP server, reverse proxy, or load balancer.
• Apply per-IP rate limits and connection limits for Engine.IO endpoints.
• Restrict access to the Socket.IO/Engine.IO endpoint where feasible.

Example Socket.IO configuration to disable polling, if compatible with your clients:

 1const io = new Server(httpServer, {
 2  transports: ["websocket"],
 3});