Skip to content
Log inStart free trial

GHSA-5qfp-32cf-69jh

SurrealDB: HTTP /rpc `sessions` method leaks attached session UUIDs, enabling full session hijack by anonymous callers

High crates.io
Severity
8.8 / 10
High · CVSS 3.1
Exploit chance (EPSS)
—
No score published
Known exploited
No
Not in CISA's catalog
Weakness
CWE-384 Session Fixation
Fix
3.1.0
Upgrade surrealdb to this version or later

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's Http/Https engine (auto-attaches once per Surreal handle).
  • Not exposed: REST endpoints (/sql, /key, /signin, /export, etc.); WebSocket /rpc (per-connection scope, attach refused); embedded / MCP usage; ad-hoc POST /rpc callers that never attach.

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

  1. HTTP sessions() now returns method_not_allowed. WebSocket retains per-connection enumeration.
  2. The HTTP /rpc handler gates client-supplied session IDs against the caller's request-level auth principal (actor id + level); mismatches return session_not_found.
  3. 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 attach against HTTP /rpc (notably the Rust SDK's Http/Https engine). Prefer the WebSocket transport, or REST endpoints (/sql, /signin, /key, /export) which never populate the attached-session map.
  • Restrict /rpc to trusted clients at the network layer.

Affected versions

crates.io

PackageVulnerableFixed in
surrealdb
< 3.1.0
3.1.0

How to fix

Move to the fixed version or later with your package manager, update the lockfile, and run your tests. If the package only arrives through another dependency, upgrade that dependency first. If none of its releases pulls a fixed version yet, force the version with your package manager's override.

surrealdb crates.io → 3.1.0

cargo
cargo update -p surrealdb --precise 3.1.0

Severity breakdown

CVSS 3.1 8.8

CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H

Attack vector
Network
Attack complexity
Low
Privileges required
None
User interaction
Required
Scope
Unchanged
Confidentiality
High
Integrity
High
Availability
High

Weakness

CWE-384: Session Fixation

Authenticating a user, or otherwise establishing a new user session, without invalidating any existing session identifier gives an attacker the opportunity to steal authenticated sessions.

How to prevent it
  • Architecture and Design: Invalidate any existing session identifiers prior to authorizing a new user session.
  • Architecture and Design: For platforms such as ASP that do not generate new values for sessionid cookies, utilize a secondary cookie. In this approach, set a secondary cookie on the user's browser to a random value and set a session variable to the same value. If the session variable and the cookie value ever don't match, invalidate the session, and force the user to log on again.
  • Operation: Use an application firewall that can detect attacks against this weakness. It can be beneficial in cases in which the code cannot be fixed (because it is controlled by a third party), as an emergency prevention measure while more comprehensive software assurance measures are applied, or to provide defense in depth [REF-1481].

References

Packages

Other links

Timeline

  1. Published
  2. Last updated by the source
AdvisorySeverityWhy it's related
GHSA-8rw6-p7m8-63jp
SurrealDB: Array element-level (field.*) SELECT permissions leak denied elements to record users
High Also affects surrealdb
GHSA-848m-r628-vrxw
SurrealDB: Custom API route lets authenticated callers override namespace/database scope via URL path
High Also affects surrealdb
GHSA-m3c3-78fh-w3w7
SurrealDB allows bypass of deny-net flags via DNS resolution
High Also affects SurrealDB
GHSA-whwg-vh4f-pmmf
SurrealDB: Edge PERMISSIONS FOR delete bypassed when a connected node is deleted
Medium Also affects surrealdb
GHSA-fwg2-gr34-q3w8
SurrealDB: ES512 silently downgraded to ES384 due to jsonwebtoken crate limitation
Medium Also affects surrealdb
GHSA-c8jx-96c9-8xrp
SurrealDB: Field-level SELECT permissions bypassed via indexed COUNT fast paths
Medium Also affects surrealdb
GHSA-wp87-mgvq-5j93
SurrealDB: USE NS/DB implicit creation bypasses DEFINE authorization
Medium Also affects surrealdb
GHSA-97vg-427p-8hx5
SurrealDB: Port-specific --deny-net rules silently bypassed on HTTP redirect
Medium Also affects surrealdb
Is this in your code?

MergeHarbor checks every repository's dependencies against this database, ranks what matters by exploitability and reachability, routes it to the owning team and opens the fix pull request.

Check your repos with MergeHarbor