GHSA-5j35-xr4g-vwf4
@grackle-ai/server has a Missing Secure Flag on Session Cookie
Blast Radius
Weekly download volume for affected packages — a proxy for how broadly this vulnerability is deployed.
@grackle-ai/servernpmDescription
Impact
The session cookie is set with HttpOnly; SameSite=Lax; Path=/ but does not include the Secure flag. This means the cookie will be sent over plain HTTP connections.
Since the server binds to 127.0.0.1 by default and uses HTTP (not HTTPS), this is acceptable for localhost use. However, when --allow-network is used to bind to 0.0.0.0, cookies could be transmitted over insecure network connections and intercepted by an attacker.
Affected code:
packages/server/src/session.ts:76— cookie string lacks; Secureattribute
Patches
0.70.5
Fix: Conditionally add ; Secure when served over HTTPS or when --allow-network is enabled:
const securePart = isHttps ? "; Secure" : "";
return `${SESSION_COOKIE_NAME}=${cookieValue}; HttpOnly; SameSite=Lax; Path=/${securePart}; Max-Age=${maxAge}`;
Workarounds
Do not use --allow-network over untrusted networks without a TLS-terminating reverse proxy.
Resources
- OWASP: Secure Cookie Attribute
- File:
packages/server/src/session.ts
Affected Packages
| Ecosystem | Package | Vulnerable range | Fix |
|---|---|---|---|
| 📦npm | @grackle-ai/server | all versions | 0.70.5 |
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.5 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms GHSA-5j35-xr4g-vwf4 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-5j35-xr4g-vwf4 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-5j35-xr4g-vwf4. 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-5j35-xr4g-vwf4 in your dependencies?
O3 detects GHSA-5j35-xr4g-vwf4 across npm dependencies and uses function-level reachability to confirm whether the vulnerable code path is actually reachable — not just present. No false positives.