Address ws CVE (CVE-2026-48779) — bump to 8.21.0

[MatthewJamisonJS]

The vulnerability 🐛

GitHub advisory GHSA-96hv-2xvq-fx4p (CVE-2026-48779, HIGH) — "ws: Memory exhaustion DoS from tiny fragments and data chunks." A peer sending many tiny WebSocket fragments / data chunks can drive the server or client into out-of-memory and crash it.

Per the advisory, the 8.x line is patched in 8.21.0 (other lines: 5.2.5 / 6.2.4 / 7.5.11).

This is easy to miss: it does not show up in this repo's Dependabot alerts (the only open alert is @babel/core #128, low, with no published fix). ws reaches us only as a build/dev-time transitive dependency — engine.io@~6.5.2 and socket.io-adapter@~2.5.2 (live-reload / socket.io tooling) — so it isn't in the addon's published dist/. The advisory had to be addressed directly rather than via the Dependabot list.

We last touched ws in cd7326d (Jun 2024), pinning "ws": "^8.17.1" to fix an earlier ws CVE. That pin is insufficient for this advisory: yarn.lock was resolving ws@8.17.1, which is < 8.21.0.

Proposed Solution

Bump the existing yarn resolutions pin from ^8.17.1 to ^8.21.0 and re-resolve. yarn install moved the single ws entry in yarn.lock to 8.21.0; the diff is just the manifest line plus the one ws block (version / resolved / integrity).

• The ^ keeps future 8.x patches available while blocking anything < 8.21.0.
• ws 8.17.1 → 8.21.0 is all additive minor releases — no breaking changes. 8.21.0 itself adds the maxBufferedChunks / maxFragments options that back the fix. See the ws 8.21.0 release notes.
• Both consumers (engine.io, socket.io-adapter) request 8.x ranges, and ws is backward-compatible within the major, so the global resolution to 8.21.0 is safe.

Testing Notes

This is a build/dev-time dependency bump; no addon source changed.

• What was broken: yarn.lock resolved ws@8.17.1 (vulnerable to CVE-2026-48779).
• What success looks like: ws resolves to 8.21.0, and CI (lint + the ember test matrix: lts-previous, lts-current, release, beta) stays green.

To verify locally:

• grep -A1 '^ws@' yarn.lock → version "8.21.0"
• yarn install && yarn lint → clean

[MatthewJamisonJS]

Heads-up: the red CI checks are pre-existing, not caused by this bump

CI shows Lint green and all four Test scenarios red on this branch. I dug in, and the failures are not related to the ws change:

• The change is ws-only (one resolutions line + the single ws block in yarn.lock); git diff origin/main shows nothing else.
• Locally the dummy app builds fine with ws@8.21.0 — both yarn build and ember try:one ember-lts-current --- ember build succeed.
• The CI crash is inside the build toolchain, before any test runs — e.g. TypeError: Cannot read properties of undefined (reading 'debug') at ember-cli's EmberApp._initVendorFiles (ember-cli-build.js → EmberAddon). ws is a dev/live-reload (engine.io/socket.io-adapter) transitive dep and is never a browser vendor asset, so it can't reach that code path.

Control test: I pushed main's exact tip (no ws change) to a throwaway branch and ran CI on it today — Lint passed and all four Test scenarios failed there too (that branch failed at require() of ES Module .../testem/node_modules/execa/index.js ... not supported). The exact error varies run-to-run because ember-try re-resolves the floating ^ dep tree non-deterministically, but the root is the same: this repo pins ember-cli ~3.20 / an old testem, and that toolchain no longer installs cleanly against current npm releases. main last went green in April.

So CI is already broken on main independent of this PR. Fixing the toolchain rot (bumping ember-cli/testem, pinning execa, etc.) is a separate piece of work and out of scope for a one-line security bump.

Recommendation: review and merge the ws bump on its security merit (it does exactly what it should — moves ws to the patched 8.21.0), and track the CI toolchain rot separately.