Listen to this Post
CVE-2026-63740 is an authorization bypass vulnerability affecting SurrealDB versions prior to 3.1.4. The flaw resides in how the database enforces `SELECT` permissions on individual array elements when using the `field.` syntax in `DEFINE FIELD` statements.
When a `RECORD` user queries an array field protected by element-level permissions (e.g., DEFINE FIELD field. ON table PERMISSIONS FOR select WHERE ...), the permission filter is supposed to hide denied elements from the result set. However, due to incorrect index handling during the filtering process, the query leaks a subset of denied elements instead.
The root cause is that the filter removes each denied element by index while walking the array forwards. Because removing an element shifts every later index down by one, each deletion invalidates the indices still pending in the loop. The result is that the filter skips over some elements that should have been removed—a deny-all permission returns only the odd-indexed elements, and a per-element predicate keeps and drops the wrong ones.
Field-level permissions are enforced correctly; only the element (field.) level is affected. The vulnerability is also scope-limited: it only impacts `RECORD` users, while `root` and `record-owner` sessions are not affected. The issue was patched in SurrealDB 3.1.4 by modifying the three permission-filtering paths (doc/reduce.rs, doc/output.rs, and exec/operators/scan/pipeline.rs) to remove denied elements in reverse index order, preventing the index-shift problem.
DailyCVE Form:
Platform: SurrealDB
Version: < 3.1.4
Vulnerability: Array Element Permission Bypass
Severity: Medium (CVSS 6.5)
date: 2026-07-20
Prediction: 2026-07-20 (Patched)
What Undercode Say:
Analytics & Verification
To verify whether a SurrealDB instance is vulnerable, check the version:
Check SurrealDB version surreal version
If the version is below 3.1.4, the instance is vulnerable.
To test for the vulnerability, create a test table with an array field and element-level permissions:
-- Define a table with an array field DEFINE TABLE test SCHEMAFULL; DEFINE FIELD data ON test TYPE array; DEFINE FIELD data. ON test PERMISSIONS FOR select WHERE value = 'allowed'; -- Insert test data INSERT INTO test (data) VALUES (['allowed', 'denied1', 'allowed', 'denied2']); -- Query as a RECORD user (the vulnerable path) SELECT data FROM test;
If the query returns denied elements (e.g., `denied1` or denied2), the instance is vulnerable.
Exploit: (Educational Purposes!)
An attacker with `RECORD` scope access can exploit this vulnerability by:
1. Identifying tables that use element-level (field.) `SELECT` permissions.
2. Crafting a query that selects the protected array field. Due to the forward-index removal flaw, denied elements at even indices (0-based) are leaked.
3. Recovering denied elements through both a deny-all permission and a `WHERE` predicate—the wrong elements are selected either way.
Example exploit scenario:
-- Assuming a table 'secrets' with field 'codes.' protected -- Attacker with RECORD scope runs: SELECT codes FROM secrets; -- Returns: ['secret1', 'secret3'] (denied elements at index 1 and 3 are leaked)
The attacker can read array elements that element-level permissions should deny, on any table they can already SELECT.
Protection from this CVE
1. Upgrade to SurrealDB 3.1.4 or later immediately.
- Do not rely on element-level (
field.) permissions to hide data from record users; use field-level permissions instead, which are enforced correctly. - Restrict record users from selecting tables whose schema uses element-level permissions until the fix is applied.
- Audit existing permission configurations and review all array field access patterns to identify potential exploitation vectors.
Impact
What an attacker can do:
- As a record (scope) user, read array elements that an element-level (
field.) `SELECT` permission should hide, on any table they can alreadySELECT. - Recover denied elements through both a deny-all and a `WHERE` predicate—the wrong elements are selected either way.
What it can’t do:
- Bypass field-level `SELECT` permissions, which are evaluated correctly.
- Affect root or record-owner sessions, or cross namespace/database isolation.
- Modify data, escalate privileges, or affect availability (confidentiality only).
References:
🎯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
