Listen to this Post
How CVE-2025-11060 Works
CVE-2025-11060 is an incorrect authorization vulnerability in SurrealDB’s live query subscription mechanism. The core issue lies in how `LIVE SELECT` statements handle security context when delivering real-time notifications.
SurrealDB allows clients to register `LIVE SELECT` queries that push notifications when table data changes. When a user defines a `LIVE SELECT` with a `WHERE` clause, the database is supposed to filter results based on the subscribing user’s permissions. However, due to a flaw in the notification pipeline, the permission evaluation is incorrectly performed using the security context of the user who triggered the change (e.g., the user who created, updated, or deleted the record).
This creates a dangerous scenario. An attacker with permissions to run `LIVE SELECT` subscriptions on a table can bind a malicious value to user-named variables like $value, $before, $after, or `$event` before registering the live query. When another user later modifies or deletes a record, the notification is evaluated against the attacker’s controlled input instead of the actual document. For example, an attacker could issue `LET $value = [$auth.id]` and then register LIVE SELECT FROM person. At notification time, a `SELECT` permission like `WHERE $auth.id.id() IN $value` would pass for every record on the table because `$value` has been shadowed by the attacker’s value.
The result is that a low-privileged user can receive real-time notifications for records they should never see, effectively bypassing table-level `PERMISSIONS` and `WHERE` restrictions. Only permission expressions that reference field names, $auth, or `$session` are immune. The attack is read-only and confined to a single table.
DailyCVE Form
Platform: SurrealDB
Version: <2.1.9, 2.2.x<2.2.8, 2.3.x<2.3.8
Vulnerability: Incorrect Authorization (CWE-863)
Severity: Moderate (CVSS 6.9)
date: 2025-09-11
Prediction: Already Patched (2025-09-11)
What Undercode Say
Analytics & Detection Commands
Check SurrealDB version surreal version Search for LIVE SELECT usage in database logs grep "LIVE SELECT" /var/log/surrealdb/.log Audit for permission expressions using user-named variables Look for DEFINE TABLE ... PERMISSIONS FOR SELECT WHERE ... $value|$before|$after|$event surreal sql --endpoint http://localhost:8000 --namespace test --database test --pretty \ "INFO FOR DB" | grep -E '\$(value|before|after|event)'
Vulnerable Configuration Example (Do NOT use)
-- Table definition with vulnerable permission DEFINE TABLE person PERMISSIONS FOR SELECT WHERE $auth.id.id() IN $value; -- Attacker's malicious subscription LET $value = [$auth.id]; LIVE SELECT FROM person;
Exploit
An attacker must have permissions to run `LIVE SELECT` queries on the target table. The exploitation steps are:
1. Bind a malicious value to one of the vulnerable variables ($value, $before, $after, or $event) using a `LET` statement.
2. Register a `LIVE SELECT` query on the table, optionally with a `WHERE` clause.
3. Wait for another user to create, update, or delete a record in that table.
4. Receive the notification containing the unauthorized record data, which has been evaluated against the attacker’s injected variable instead of the actual document.
The attack requires user interaction (another user must modify data) and a small amount of user privileges. It impacts confidentiality only and is limited to the table the attacker has access to.
Protection
Patch: Upgrade to a patched version immediately. The following versions are not affected:
– SurrealDB 2.1.9 and later
– SurrealDB 2.2.8 and later
– SurrealDB 2.3.8 and later
– Any release following v3.0.0-alpha.7
Workarounds (if unable to patch):
- Avoid `table-PERMISSIONS` and `LIVE WHERE` expressions that read user-named variables (
$value,$before,$after,$event) - Gate permissions on a system-derived field such as the record id
- Assess the impact of users with permissions on table records as effectively having full read access to the table, and use separate tables if required
Additional Mitigations:
- Implement role-based access control (RBAC) to reduce attack surface
- Ensure all pages with sensitive information are not cached and require authenticated sessions
Impact
- Confidentiality: High – unauthorized users can observe records they should not have access to
- Integrity: None – this is a read-only attack
- Availability: None – the attack does not disrupt service
- Scope: Limited to a single table; requires another user to trigger changes
- Attack Vector: Network – the attacker can exploit this remotely
- Privileges Required: Low – the attacker only needs permissions to run `LIVE SELECT` subscriptions
🎯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
