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:
Content-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:
The fix ensures that invalid binary polling POST requests are explicitly rejected with an HTTP response and closed properly.
Users should upgrade to:
npm 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:
const io = new Server(httpServer, {
transports: ["websocket"],
});References
References
hibrian827 Reporter
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
POSTrequest with: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:
6.6.7The fix ensures that invalid binary polling
POSTrequests are explicitly rejected with an HTTP response and closed properly.Users should upgrade to:
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.ioversion.Workarounds
If upgrading immediately is not possible, possible mitigations include:
POSTrequests withContent-Type: application/octet-streamfor Engine.IO protocol v4 at a reverse proxy, load balancer, WAF, or application middleware.Example Socket.IO configuration to disable polling, if compatible with your clients:
References
6.6.7: https://github.com/socketio/socket.io/blob/main/packages/engine.io/CHANGELOG.md#667-2026-04-27References