Impact
Engine.IO servers with WebTransport enabled are vulnerable to a remotely triggerable denial of service.
A malicious unauthenticated client can send a crafted WebTransport upgrade request containing a specially chosen session ID, such as proto. Because the session ID lookup did not properly verify that the key was an own property of the clients object, the lookup could resolve to an inherited prototype property instead of a valid Engine.IO client.
This can cause a TypeError during WebTransport upgrade handling. Since the failure occurs in an asynchronous context, it may result in an unhandled Promise rejection and terminate the Node.js process on affected Node.js versions/configurations.
Successful exploitation can allow an unauthenticated remote attacker to crash the server process and cause denial of service. Under a process supervisor, repeated exploitation may cause crash loops.
Affected configurations are limited to deployments where WebTransport support is enabled. WebTransport is not enabled by default.
Affected versions:
- engine.io >= 6.5.0 < 6.6.7
Patches
The issue was fixed in:
- engine.io 6.6.7
Users should upgrade to engine.io@6.6.7 or later.
If using Socket.IO packages that depend on Engine.IO, users should update to a Socket.IO release that includes the patched Engine.IO version.
Workarounds
If upgrading immediately is not possible, affected users can mitigate the issue by disabling WebTransport support.
WebTransport is opt-in, so servers should ensure that webtransport is not included in the enabled transports list.
For example, use only the default HTTP long-polling and WebSocket transports:
js const engine = new Server({ transports: ["polling", "websocket"], });
Additional operational mitigations may include:
- Restricting access to WebTransport endpoints at the reverse proxy or HTTP/3 layer. - Disabling HTTP/3/WebTransport support until the patched version can be deployed. - Running the service under a supervisor as a partial availability mitigation, though this does not prevent repeated crash attempts.
References
- Fix commit: https://github.com/socketio/socket.io/commit/1fa1f46cd420ac5b57bb4c04c959b58f3c79158c - Engine.IO changelog entry for 6.6.7: https://github.com/socketio/socket.io/blob/main/packages/engine.io/CHANGELOG.md#667-2026-04-27 - Engine.IO package: https://www.npmjs.com/package/engine.io - Socket.IO repository: https://github.com/socketio/socket.io
Engine.IO is the implementation of transport-based cross-browser/cross-device bi-directional communication layer for Socket.IO. A specially crafted HTTP request can trigger an uncaught exception on the Engine.IO server, thus killing the Node.js process. This impacts all the users of the engine.io package, including those who uses depending packages like socket.io. There is no known workaround except upgrading to a safe version. There are patches for this issue released in versions 3.6.1 and 6.2.1.
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:
- 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:
sh 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:
js const io = new Server(httpServer, { transports: ["websocket"], });
References
- Fix commit: https://github.com/socketio/socket.io/commit/fc11285e14964c2132d122164bf130c355f60671 - engine.io changelog entry for 6.6.7: https://github.com/socketio/socket.io/blob/main/packages/engine.io/CHANGELOG.md#667-2026-04-27 - socket.io repository: https://github.com/socketio/socket.io - engine.io package: https://www.npmjs.com/package/engine.io