Open actionable advisories and recorded vendor fixes. This public package view has no inventory attached and cannot establish whether your deployment is affected. A vendor fix never resolves your finding; verify your installed version and the source guidance.
Open advisories
7 actionable advisories, newest first. Withdrawn advisories and news are excluded. Coverage is partial.
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 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.
Recommended action: Upgrade to 8.21.0, 7.5.11, 6.2.4 or 5.2.5 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact The websocket.close() implementation is vulnerable to uninitialized memory disclosure when a TypedArray is passed as the reason argument. Proof of concept 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
Recommended action: Upgrade to 8.20.1 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact A request with a number of headers exceeding the [server.maxHeadersCount][] threshold could be used to crash a ws server. Proof of concept Patches 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). Workarounds In vulnerable versions of ws, the issue can be mitigated in the following ways: 1. Reduce the maximum allowed length of the request headers using the [--max-http-header-size=size][] and/or the [maxHeaderSize][] options so that no more headers than the server.maxHeadersCount limit can be sent. 2. Set server.maxHeadersCount to 0 so that no limit is applied. Credits The vulnerability was reported by Ryan…
Recommended action: Upgrade to 8.17.1, 7.5.10, 6.2.3 or 5.2.4 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact A specially crafted value of the Sec-Websocket-Protocol header can be used to significantly slow down a ws server. Proof of concept Patches The vulnerability was fixed in ws@7.4.6 (https://github.com/websockets/ws/commit/00c425ec77993773d823f018f64a5c44e17023ff) and backported to ws@6.2.2 (https://github.com/websockets/ws/commit/78c676d2a1acefbc05292e9f7ea0a9457704bf1b) and ws@5.2.3 (https://github.com/websockets/ws/commit/76d47c1479002022a3e4357b3c9f0e23a68d4cd2). Workarounds In vulnerable versions of ws, the issue can be mitigated by reducing the maximum allowed length of the request headers using the --max-http-header-size=size and/or the maxHeaderSize options. Credits The vulnerability was responsibly disclosed along with a fix in private by Robert McLaughlin from University of California, Santa Barbara.
Recommended action: Upgrade to 7.4.6, 6.2.2 or 5.2.3 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Affected versions of ws can crash when a specially crafted Sec-WebSocket-Extensions header containing Object.prototype property names as extension or parameter names is sent. Proof of concept Recommendation Update to version 3.3.1 or later.
Recommended action: Upgrade to 3.3.1 or 1.1.5 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Affected versions of ws do not appropriately limit the size of incoming websocket payloads, which may result in a denial of service condition when the node process crashes after receiving a large payload. Recommendation Update to version 1.1.1 or later. Alternatively, set the maxpayload option for the ws server to a value smaller than 256MB.
Recommended action: Upgrade to 1.1.1 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Versions of ws prior to 1.0.1 are affected by a remote memory disclosure vulnerability. In certain rare circumstances, applications which allow users to control the arguments of a client.ping() call will cause ws to send the contents of an allocated but non-zero-filled buffer to the server. This may disclose sensitive information that still exists in memory after previous use of the memory for other tasks. Proof of Concept Recommendation Update to version 1.0.1 or greater.
Recommended action: Upgrade to 1.0.1 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.