GHSA-5qfp-32cf-69jh
HIGHSurrealDB: HTTP /rpc `sessions` method leaks attached session UUIDs, enabling full session hijack by anonymous callers
Blast Radius
surrealdbReal-time download stats are indexed for npm and PyPI packages. This vulnerability affects crates.io packages — download data is not available via public APIs for these ecosystems.
Description
The HTTP /rpc sessions method returned every attached session UUID without authentication, and the /rpc handler accepted an arbitrary session field with no ownership check. An anonymous caller could enumerate UUIDs and impersonate any authenticated session.
"Attached" means sessions registered via {"method":"attach"} — the only writer to the HTTP session map. Ordinary stateless /rpc requests use ephemeral per-request sessions that are filtered from sessions() and destroyed at end-of-request, so they are not enumerable.
Exposure
- Exposed: clients that issue
attach, notably the official Rust SDK'sHttp/Httpsengine (auto-attaches once perSurrealhandle). - Not exposed: REST endpoints (
/sql,/key,/signin,/export, etc.); WebSocket/rpc(per-connection scope,attachrefused); embedded / MCP usage; ad-hocPOST /rpccallers that neverattach.
Impact
For each attached and authenticated session, an unauthenticated attacker can read, write, and delete any data the session can reach, dump metadata, invalidate sessions, and escalate to that session's privilege level (up to root). An attached session that has not yet authenticated is Level::No and confers no privilege.
Patches
- HTTP
sessions()now returnsmethod_not_allowed. WebSocket retains per-connection enumeration. - The HTTP
/rpchandler gates client-supplied session IDs against the caller's request-level auth principal (actor id + level); mismatches returnsession_not_found. - Attached HTTP sessions are capped via
SURREAL_HTTP_MAX_ATTACHED_SESSIONS.
Versions 3.1.0 and later are not affected.
Workarounds
No configuration-level mitigation fully addresses this. For Users unable to upgrade:
- Avoid SDKs and client flows that call
attachagainst HTTP/rpc(notably the Rust SDK'sHttp/Httpsengine). Prefer the WebSocket transport, or REST endpoints (/sql,/signin,/key,/export) which never populate the attached-session map. - Restrict
/rpcto trusted clients at the network layer.
Affected Packages
| Ecosystem | Package | Vulnerable range | Fix |
|---|---|---|---|
| 🦀crates.io | surrealdb | all versions | 3.1.0 |
Detection & mitigation playbook
Open-source dependencyDetect
Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for surrealdb. 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 surrealdb to 3.1.0 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms GHSA-5qfp-32cf-69jh 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-5qfp-32cf-69jh 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-5qfp-32cf-69jh. 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-5qfp-32cf-69jh in your dependencies?
O3 detects GHSA-5qfp-32cf-69jh across crates.io dependencies and uses function-level reachability to confirm whether the vulnerable code path is actually reachable — not just present. No false positives.