Is there an existing issue for this?
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
Is there an existing issue for this?
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