GHSA-4m82-p8cx-f94j is a medium-severity (CVSS 4.3) vulnerability in surrealdb. O3 Security confirms whether GHSA-4m82-p8cx-f94j is actually reachable in your code before you act, and blocks exploitation at runtime until you patch.
SurrealDB: LIVE query subscriptions survive session state changes, bypassing access controls
Real-World Exposure
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
A LIVE SELECT subscription records the user's auth state ($auth, $token, $session, $access) when it is registered, and the server uses that recorded state to evaluate the table- and row-level PERMISSIONS clauses for every subsequent notification. The recorded state is never refreshed.
When something changes the user's effective auth state — the originating session is invalidated, the session's TTL expires, or the user signs in, signs up, or authenticates as a different identity on the same connection — the subscription keeps delivering notifications under the old, stale auth state, and the PERMISSIONS that should now apply to the connection are never consulted.
Impact
A user whose session has been revoked, expired, signed out of, or re-authenticated on the same connection continues to receive real-time notifications evaluated against the prior principal. The attacker does not gain access to new resources — only continued access to resources the prior principal was already permitted to read — but that continued access persists past the point the principal change should have ended it, and persists indefinitely until the originating connection is closed.
This is confidentiality-only: the dispatcher does not enable writes evaluated under the stranded principal.
Patches
invalidate()and TTL expiry —RpcProtocol::invalidatenow callscleanup_lqs(session_id)after clearing the session, dropping every LIVE owned by the now-invalidated session. The notification dispatcher additionally reads the originating session'sexpand skips delivery once it has passed, closing the TTL-expiry leg without requiring theSessionobject to remain in memory.- Principal change on
signin/signup/authenticate/refresh— each of these RPC methods now snapshots the session's auth principal (Auth::id()+Auth::level()) before mutating the session and, if the principal has changed after the operation, callscleanup_lqs(session_id). Token refresh against the same identity is therefore preserved; identity change tears stranded subscriptions down.
Versions 3.1.0 and later are not affected by this issue.
Workarounds
For unpatched versions, clients should call reset() (which tears down all LIVE queries owned by the session) or kill each outstanding live query ID before signing out, signing in as a different identity, or signing up on an existing connection. There is no client-side workaround for the TTL-expiry leg; deployments concerned about it should restrict DURATION FOR SESSION on access methods that have permission to register LIVE queries.
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-4m82-p8cx-f94j 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-4m82-p8cx-f94j 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-4m82-p8cx-f94j. 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-4m82-p8cx-f94j in your dependencies?
O3 detects GHSA-4m82-p8cx-f94j 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.