GHSA-w3hv-x4fp-6h6j
@grackle-ai/server has Missing WebSocket Origin Header Validation
Blast Radius
Weekly download volume for affected packages — a proxy for how broadly this vulnerability is deployed.
@grackle-ai/servernpmDescription
Impact
The WebSocket upgrade handler in the server validates authentication (API key token or session cookie) but does not check the Origin header. A malicious webpage on a different origin could initiate a WebSocket connection to ws://localhost:3000/ws if it can leverage the user's session cookie (which is SameSite=Lax, allowing top-level navigations).
This enables cross-origin WebSocket hijacking — if a user visits a malicious site while a Grackle session is active, the attacker's page could open a WebSocket and subscribe to real-time events (session output, task updates, environment state).
Affected code:
packages/server/src/ws-bridge.ts:80-91— connection handler accepts WebSocket upgrades without checkingreq.headers.origin
Patches
Fix: Validate req.headers.origin against an allowlist before accepting connections:
const origin = req.headers.origin || "";
if (origin && !origin.includes("localhost") && !origin.includes("127.0.0.1")) {
ws.close(4003, "Invalid origin");
return;
}
Workarounds
Ensure the Grackle server is only accessible on 127.0.0.1 (the default). Do not use --allow-network in untrusted network environments.
Resources
- CWE-346: Origin Validation Error
- File:
packages/server/src/ws-bridge.ts
Affected Packages
| Ecosystem | Package | Vulnerable range | Fix |
|---|---|---|---|
| 📦npm | @grackle-ai/server | all versions | 0.70.3 |
Detection & mitigation playbook
Open-source dependencyDetect
Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for @grackle-ai/server. O3's reachability analysis confirms whether the vulnerable code path is actually invoked in your application, so you act on real exposure instead of every transitive match.
Fix
Update @grackle-ai/server to 0.70.3 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms GHSA-w3hv-x4fp-6h6j is resolved across your whole dependency graph.
Workarounds
If you can't upgrade right away: gate or disable the affected feature, validate untrusted input at the boundary, and avoid passing attacker-controlled data into the vulnerable path. O3's runtime protection blocks exploitation in production as an interim safeguard until the upgrade lands.
How O3 protects you
O3 pinpoints whether GHSA-w3hv-x4fp-6h6j is reachable in your code and exactly where to fix it, then blocks exploitation in production at runtime until the patched version is deployed.
Tailored to GHSA-w3hv-x4fp-6h6j. Runtime protection reduces exposure until a permanent patch is applied and verified — it complements patching, it doesn't replace it.
Frequently Asked Questions
Is GHSA-w3hv-x4fp-6h6j in your dependencies?
O3 detects GHSA-w3hv-x4fp-6h6j across npm dependencies and uses function-level reachability to confirm whether the vulnerable code path is actually reachable — not just present. No false positives.