Repository navigation
Default maxFragments still allows memory-exhaustion DoS (incomplete GHSA-96hv-2xvq-fx4p fix) #2331
Description
Is there an existing issue for this?
- I've searched for any related issues and avoided creating a duplicate issue.
Description
reported via email on 4 June 2026 - no response:
The GHSA-96hv-2xvq-fx4p fix added maxFragments/maxBufferedChunks, but the defaults are high enough that a default-configured server can still be OOM-crashed by one unauthenticated peer.
In lib/receiver.js:509-531, the guard counts fragments and only fires at the limit. An attacker sends a text frame with FIN=0 plus maxFragments-2 one-byte continuation frames and never sends FIN. The message never completes, the fragment array stays just under maxFragments (default 131072) forever, _totalPayloadLength stays ~128 KB (far below maxPayload), and each 1-byte fragment is a separate Buffer view with ~100 bytes of overhead.
Validated on ws 8.21.0 (default options): 131000 fragments (~0.87 MB wire) pin ~13.5 MB of server heap (about 15x), guard never fires. A few dozen such connections (~40 MB total traffic) OOM-kill a default-heap Node process.
Suggested fix: lower the default maxFragments/maxBufferedChunks substantially, and/or add a per-connection (and ideally process-wide) cap on bytes pinned by incomplete messages rather than only a fragment count, so the per-fragment object overhead cannot be amplified.
ws version
No response
Node.js Version
No response
System
No response
Expected result
No response
Actual result
No response
Attachments
No response
Activity
lpinca commentedon Jul 6, 2026
[fix] Lower default values of `maxBufferedChunks` and `maxFragments`
[fix] Lower default values of `maxBufferedChunks` and `maxFragments`
[fix] Lower default values of `maxBufferedChunks` and `maxFragments`
[fix] Lower default values of `maxBufferedChunks` and `maxFragments`
rafael-nogueras commentedon Jul 21, 2026
@lpinca Hello! Although this fix (including all the back-ports) addresses CVE-2026-62389, the CVE fix record reports only 8.21.1 as the fix version.
What is the process to get the back-ported versions (specifically I am interested in 7.5.13) to also be considered fixes for the CVE? Thanks!
lpinca commentedon Jul 21, 2026
See https://github.com/websockets/ws/releases/tag/7.5.12, anyway I disagree with GHSA-73jw-fp74-p77x for the reasons stated above. It's a low effort duplicate of GHSA-96hv-2xvq-fx4p. I'm not sure who published that CVE. It's a shame no one reviewed it.
rafael-nogueras commentedon Jul 21, 2026
@lpinca Thanks for the reply!
I am not saying I agree with the CVE or not, but it's still the case that static code vulnerability tools are reporting ws@7.5.12 as being affected, while it shouldn't be since the fix was back-ported from 8.21.1 to 7.5.12.
Note how GHSA-96hv-2xvq-fx4p lists several fix versions: how can GHSA-73jw-fp74-p77x be modified such that it also lists the back-port fix versions?
Thanks!
lpinca commentedon Jul 22, 2026
I published GHSA-96hv-2xvq-fx4p while GHSA-73jw-fp74-p77x was not published by me so I don't know.
rafael-nogueras commentedon Jul 27, 2026
@lpinca I thought repo owners could if not directly update, at least comment on the advisory database issue / ask that it be updated to include appropriate fix versions —if not repo owners, who can?
TLDR: this vulnerability was fixed in 7.5.12, but all of us using
wsat version 7.x.x are still showing that module as vulnerable, even though we've updated to 7.5.12 and are no longer vulnerable.How does this get addressed?
lpinca commentedon Jul 28, 2026
See github/advisory-database#8789.
rafael-nogueras commentedon Jul 28, 2026
Thanks, @lpinca ! :-)
[fix] Lower default values of `maxBufferedChunks` and `maxFragments`