fix: bump ws to 8.21.0 via override (CVE-2026-48779) (#326)#327
Conversation
ws@8.19.0 (HIGH, memory-exhaustion DoS) is pulled transitively by @supabase/realtime-js and happy-dom, failing the required Trivy Security Scan on every PR. Both parents allow 8.21.0 in-range, so an overrides entry forces all ws to the patched version. bun update ws was rejected: it added ws as a direct dep while leaving the transitive consumers pinned at 8.19.0 (still vulnerable). The override covers the whole tree. Frontend typecheck/test/build green; no runtime API change.
|
@DevanshuNEU is attempting to deploy a commit to the Dev's projects Team on Vercel. A member of the Team first needs to authorize it. |
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Repository UI Review profile: CHILL Plan: Pro Run ID: ⛔ Files ignored due to path filters (1)
📒 Files selected for processing (1)
📝 WalkthroughWalkthroughA top-level Changesws Dependency Override
Estimated code review effort🎯 1 (Trivial) | ⏱️ ~2 minutes Poem
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
Summary
Forces
wsto8.21.0across the dependency tree via a package.jsonoverrides, clearing CVE-2026-48779 (HIGH, memory-exhaustion DoS) that was failing the required TrivySecurity Scanon every PR.Closes / implements
fix/bump-ws-cve-2026-48779What changed
Frontend (
frontend/...):package.json- addoverrides: { "ws": "^8.21.0" }to force the patched version across the whole tree.bun.lock-wsresolves8.19.0 -> 8.21.0; no nested8.19.0remains.Why the override (not
bun update ws)wsis transitive only (@supabase/realtime-js -> ws@^8.18.2,happy-dom -> ws@^8.18.3).bun update wsaddedwsas a direct dep at 8.21.0 but left both transitive consumers pinned at the vulnerable8.19.0. Anoverridesentry is the correct mechanism: it rewrites everywsresolution in the tree. Verified:grep ws@8.19.0 bun.lockreturns nothing after the change.How to test
cd frontend && bun installgrep -E 'ws@8\.' bun.lock- expect onlyws@8.21.0(and@types/ws, type defs, unrelated)bun run typecheck && bun run test && bun run buildExpected: no
ws@8.19.0anywhere; typecheck clean, 13 tests pass, build succeeds. Trivy Security Scan goes green.Deployment notes
bun.lock, not the off-limitsbun.lockb)Risk and rollback
ws8.21.0 behavior change regressed the Supabase realtime WebSocket (indexing-progress events), clients would see WS reconnect issues.Summary by CodeRabbit
wslibrary.