Vulnerability Database

362,557

Total vulnerabilities in the database

SurrealDB: LIVE query subscriptions survive session state changes, bypassing access controls — surrealdb

Insufficient Session Expiration

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 expiryRpcProtocol::invalidate now calls cleanup_lqs(session_id) after clearing the session, dropping every LIVE owned by the now-invalidated session. The notification dispatcher additionally reads the originating session's exp and skips delivery once it has passed, closing the TTL-expiry leg without requiring the Session object 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, calls cleanup_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.

  • Published: Jul 1, 2026
  • Updated: Jul 2, 2026
  • GHSA: GHSA-4m82-p8cx-f94j
  • Severity: Medium
  • Exploit:
  • CISA KEV:

CVSS v3:

  • Severity: Low
  • Score: 4.3
  • AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N

Frequently Asked Questions

A security vulnerability is a weakness in software, hardware, or configuration that can be exploited to compromise confidentiality, integrity, or availability. Many vulnerabilities are tracked as CVEs (Common Vulnerabilities and Exposures), which provide a standardized identifier so teams can coordinate patching, mitigation, and risk assessment across tools and vendors.

CVSS (Common Vulnerability Scoring System) estimates technical severity, but it doesn't automatically equal business risk. Prioritize using context like internet exposure, affected asset criticality, known exploitation (proof-of-concept or in-the-wild), and whether compensating controls exist. A "Medium" CVSS on an exposed, production system can be more urgent than a "Critical" on an isolated, non-production host.

A vulnerability is the underlying weakness. An exploit is the method or code used to take advantage of it. A zero-day is a vulnerability that is unknown to the vendor or has no publicly available fix when attackers begin using it. In practice, risk increases sharply when exploitation becomes reliable or widespread.

Recurring findings usually come from incomplete Asset Discovery, inconsistent patch management, inherited images, and configuration drift. In modern environments, you also need to watch the software supply chain: dependencies, containers, build pipelines, and third-party services can reintroduce the same weakness even after you patch a single host. Unknown or unmanaged assets (often called Shadow IT) are a common reason the same issues resurface.

Use a simple, repeatable triage model: focus first on externally exposed assets, high-value systems (identity, VPN, email, production), vulnerabilities with known exploits, and issues that enable remote code execution or privilege escalation. Then enforce patch SLAs and track progress using consistent metrics so remediation is steady, not reactive.

SynScan combines attack surface monitoring and continuous security auditing to keep your inventory current, flag high-impact vulnerabilities early, and help you turn raw findings into a practical remediation plan.