Listen to this Post
How CVE-2025-11060 Works
A `LIVE SELECT` subscription in SurrealDB records the user’s authentication state ($auth, $token, $session, $access) at the moment it is registered. The server then uses this recorded state—not the current session state—to evaluate table‑ and row‑level `PERMISSIONS` clauses for every subsequent notification delivered to that subscription. Critically, the recorded state is never refreshed.
When a user’s effective authentication state changes—for example, when 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 continues to deliver notifications under the old, stale authentication state. The `PERMISSIONS` that should now apply to the connection are never consulted.
An attacker whose session has been revoked, expired, signed out, or re‑authenticated on the same connection continues to receive real‑time notifications that are 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 a confidentiality‑only issue; the dispatcher does not enable writes evaluated under the stranded principal.
The patches address the problem in two key areas:
– `invalidate()` and TTL expiry – `RpcProtocol::invalidate` now calls `cleanup_lqs(session_id)` after clearing the session, dropping every `LIVE` subscription 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. If the principal has changed after the operation, the method 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. 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.
DailyCVE Form
| Field | Value |
|–|–|
| Platform | SurrealDB |
| Version | < 3.1.0 |
| Vulnerability | Stale auth state |
| Severity | Medium (CVSS 5.7) |
| Date | 2025‑09‑26 |
| Prediction | 2025‑10‑10 |
What Undercode Say: Analytics
The vulnerability stems from the server caching authentication context at subscription time and never refreshing it. Key indicators of exploitation include:
– Stale notifications – continued delivery of `LIVE SELECT` events after session invalidation or identity change.
– No permission re‑evaluation – the `PERMISSIONS` clause is not re‑checked when the auth state changes.
– Persistence – the issue persists until the connection is closed, not until the session expires.
To detect whether a deployment is affected, administrators can run the following diagnostic queries:
List all active LIVE subscriptions for a given session SELECT FROM $live_queries WHERE session_id = '<session_id>'; Check the recorded auth state for a subscription SELECT id, auth, token, session, access FROM $live_subscriptions WHERE id = '<subscription_id>';
For proactive monitoring, the following script can be used to periodically validate that the auth state of each subscription matches the current session state:
!/bin/bash Check for stale auth states in LIVE subscriptions for sub in $(surreal sql "SELECT id, session FROM $live_subscriptions"); do session_id=$(echo $sub | jq -r '.session') current_auth=$(surreal sql "SELECT auth FROM $sessions WHERE id = '$session_id'") recorded_auth=$(surreal sql "SELECT auth FROM $live_subscriptions WHERE id = '$(echo $sub | jq -r '.id')'") if [ "$current_auth" != "$recorded_auth" ]; then echo "Stale auth detected for subscription $(echo $sub | jq -r '.id')" fi done
How Exploit:
An attacker can exploit this vulnerability by:
- Establishing a connection to the SurrealDB server and authenticating as a user with read permissions on a target table.
- Registering a `LIVE SELECT` subscription on that table (e.g.,
LIVE SELECT FROM sensitive_table). - Changing their authentication state on the same connection—for example, by calling
signout,invalidate, or `authenticate` as a different user—without closing the connection. - Continuing to receive real‑time notifications for changes on the target table, even though their current session no longer has the necessary permissions.
The following SurrealQL snippet demonstrates the attack sequence:
-- Step 1: Authenticate as a user with read access AUTHENTATE 'token_with_read_access'; -- Step 2: Create a LIVE SELECT subscription LIVE SELECT FROM sensitive_table; -- Step 3: Invalidate the session (or sign out / re‑authenticate) INVALIDATE; -- Step 4: The subscription continues to deliver notifications -- even though the session is now unauthenticated.
Protection from this CVE
- Upgrade to SurrealDB version 3.1.0 or later, which includes the patches described above.
- For unpatched versions, implement the following workarounds:
- Call `reset()` or `kill` each outstanding live query ID before performing any auth‑state‑changing operation (sign out, sign in as different identity, sign up).
- Restrict `DURATION FOR SESSION` on access methods that can register `LIVE` queries to limit the TTL‑expiry window.
- Monitor for stale subscriptions by periodically comparing the recorded auth state of each `LIVE` subscription against the current session state.
- Close connections after any auth‑state change to force the cleanup of all associated subscriptions.
Impact
- Confidentiality – an attacker with a previously valid session can continue to read data they should no longer have access to, indefinitely.
- No Integrity or Availability impact – the vulnerability does not allow writes or denial of service.
- Scope – any deployment using `LIVE SELECT` subscriptions with session‑based authentication is affected if running a version prior to 3.1.0.
- Risk – medium, as it requires an existing authenticated session and does not grant new privileges, but it breaks the expected revocation semantics.
🎯Let’s Practice Exploiting & Learn Patching For Free:
🎓 Live Courses & Certifications:
Join Undercode Academy for Verified Certifications
🚀 Request a Custom Project:
Secure, high-velocity infrastructure and disruptive technological engineering. Contact our engineering team for high-tier development and proprietary systems:
[email protected]
💎 Smart Architecture | 🛡️ Secure by Design | ⭐ Trusted by Thousands
Sources:
Reported By: github.com
Extra Source Hub:
Undercode
