Listen to this Post
SurrealDB versions prior to 3.2.0 contain a permissions bypass vulnerability where data-modifying statements within `PERMISSIONS` clauses execute with enforcement disabled. The core issue lies in how the system processes `PERMISSIONS … WHERE` clauses: the `WHERE` clause is evaluated with permission enforcement disabled, preventing it from recursing into its own checks. However, this clause could also contain data-modifying statements (CREATE, UPDATE, DELETE, RELATE, INSERT, or UPSERT), and these ran with enforcement still off.
For example, consider the following table definition:
DEFINE TABLE post PERMISSIONS FOR update WHERE (CREATE log SET at = time::now()) OR true;
Any user allowed to update a `post` now also creates a `log` record, even with no permission on the `log` table. The clause is evaluated once per matched record, so one statement can cause several writes.
What an attacker can do:
- With permission to perform the guarded operation (a low-privileged or record user is enough), write to tables in their own database that their permissions would otherwise forbid, by triggering an operation the clause guards.
- Cause several writes from a single statement — the clause is evaluated once per matched record.
- Trigger unintended events, cascades, or data corruption on those tables.
What it can’t do:
- Escape the caller’s own namespace and database — a permission clause cannot switch namespace or database.
- Perform root- or namespace-level actions such as creating users; the caller’s role still applies.
- Read hidden data — this is an integrity issue, not disclosure.
The vulnerability is confined to the attacker’s current database and does not cross namespace or database isolation boundaries. Only databases with a `PERMISSIONS` clause that contains a write are affected;FULL,NONE, and read-only clauses are not. This flaw aligns with CWE-863 (Incorrect Authorization).
Patches: Permission clauses must now be read-only: defining or importing one that contains a write is rejected, and any write attempted while a clause is evaluated is blocked at runtime, including writes reached through a called function. Versions 3.2.0 and later are not affected by this issue.
Workarounds: Users unable to patch should review their `PERMISSIONS` clauses and remove any containingCREATE,UPDATE,DELETE,RELATE,INSERT, orUPSERT, and limit who can define schema and vet imported data.
Acknowledgements: Thank you to sondt99 for reporting this issue.
DailyCVE Form:
Platform: SurrealDB
Version: < 3.2.0
Vulnerability: Permissions Bypass
Severity: Medium (CVSS 6.5)
date: 2026-07-20
Prediction: 2026-08-20
What Undercode Say:
Analytics & Discovery Commands:
Check SurrealDB version:
surreal version
Identify tables with dangerous PERMISSIONS clauses:
INFO FOR DB; -- Manually review each table's PERMISSIONS definition
Search for write operations in PERMISSIONS clauses:
-- Look for CREATE, UPDATE, DELETE, RELATE, INSERT, UPSERT -- inside any PERMISSIONS ... WHERE block
Monitor for unauthorized writes:
-- Enable query logging to detect unexpected writes -- Review logs for patterns of writes from low-privileged users
Exploit: (Educational Purposes!)
Step 1: Identify a table with a `PERMISSIONS` clause that the attacker has permission to trigger (e.g., `UPDATE` permission on the `post` table).
Step 2: Craft a `PERMISSIONS` clause containing a write operation:
DEFINE TABLE post PERMISSIONS FOR update WHERE (CREATE log SET at = time::now()) OR true;
Step 3: As a low-privileged user with only `UPDATE` permission on post, execute an update:
UPDATE post SET content = "malicious" WHERE id = 1;
Step 4: The `WHERE` clause evaluates (CREATE log SET at = time::now()) OR true, creating a `log` record despite the user having no permission on the `log` table.
Step 5: The write succeeds because permission enforcement is disabled during clause evaluation. The attacker has now written to a table they lack explicit permission for.
Protection:
- Upgrade to SurrealDB 3.2.0 or later – This is the primary fix.
- Review all PERMISSIONS clauses – Remove any containing
CREATE,UPDATE,DELETE,RELATE,INSERT, orUPSERT. - Restrict schema definition privileges – Limit who can define or modify table schemas.
- Vet imported data – Ensure any imported schema definitions do not contain malicious `PERMISSIONS` clauses.
- Monitor database activity – Watch for unexpected writes from low-privileged users.
- Disable or drop affected PERMISSIONS clauses as a temporary workaround.
Impact:
- Unauthorized Data Modification – Attackers can write to tables they lack permission for.
- Data Corruption – Unintended writes can corrupt critical data.
- Integrity Violation – The vulnerability undermines the database’s access control mechanisms.
- Privilege Escalation – Attackers with low privileges can escalate to unauthorized write access.
- Denial of Service Potential – Multiple writes from a single statement can cause resource exhaustion.
- No Data Disclosure – This is an integrity issue, not a confidentiality breach.
- No Cross-Namespace Escape – The attack is confined to the caller’s own namespace and database.
🎯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
