SurrealDB: Array element-level (field.*) SELECT permissions leak denied elements to record users
SurrealDB versions prior to 3.1.4 contain a vulnerability where array element-level SELECT permissions (field.*) are not properly enforced for record users. This causes denied array elements to be partially leaked instead of hidden. The issue affects only record users and does not impact root or record-owner sessions. The vulnerability allows unauthorized reading of certain array elements but does not permit privilege escalation, data modification, or availability impact. A fix is available in SurrealDB 3.1.4.
AI Analysis
Technical Summary
SurrealDB has a flaw in enforcing SELECT permissions defined on array elements (field.*) for record users. The permission filter removes denied elements by iterating forward through the array and deleting elements by index, which shifts subsequent elements and causes some denied elements to remain visible. This results in leaking a subset of denied array elements during queries. Field-level permissions and root/record-owner sessions are unaffected. The issue is fixed by changing the removal order to reverse index order, preventing index shifting during filtering. The fix is included in SurrealDB 3.1.4.
Potential Impact
Record users can read array elements that should be hidden by element-level SELECT permissions, leading to confidentiality loss of some data elements. The vulnerability does not allow bypassing field-level permissions, does not affect root or record-owner sessions, and does not enable data modification, privilege escalation, or denial of service.
Mitigation Recommendations
A patch is available in SurrealDB version 3.1.4 that corrects the enforcement of element-level SELECT permissions. Users should upgrade to version 3.1.4 or later. As a workaround, avoid relying on element-level permissions to hide data from record users and instead use field-level permissions, which are enforced correctly. Additionally, restrict record users from selecting tables that use element-level permissions until patched.
SurrealDB: Array element-level (field.*) SELECT permissions leak denied elements to record users
Description
SurrealDB versions prior to 3.1.4 contain a vulnerability where array element-level SELECT permissions (field.*) are not properly enforced for record users. This causes denied array elements to be partially leaked instead of hidden. The issue affects only record users and does not impact root or record-owner sessions. The vulnerability allows unauthorized reading of certain array elements but does not permit privilege escalation, data modification, or availability impact. A fix is available in SurrealDB 3.1.4.
CVSS v3.1
Score 6.5medium
Affected software
Run on your own infrastructure? Check whether these packages are installed with threat-finder — our free open-source scanner.
Weaknesses
AI-Powered Analysis
Machine-generated threat intelligence
Technical Analysis
SurrealDB has a flaw in enforcing SELECT permissions defined on array elements (field.*) for record users. The permission filter removes denied elements by iterating forward through the array and deleting elements by index, which shifts subsequent elements and causes some denied elements to remain visible. This results in leaking a subset of denied array elements during queries. Field-level permissions and root/record-owner sessions are unaffected. The issue is fixed by changing the removal order to reverse index order, preventing index shifting during filtering. The fix is included in SurrealDB 3.1.4.
Potential Impact
Record users can read array elements that should be hidden by element-level SELECT permissions, leading to confidentiality loss of some data elements. The vulnerability does not allow bypassing field-level permissions, does not affect root or record-owner sessions, and does not enable data modification, privilege escalation, or denial of service.
Mitigation Recommendations
A patch is available in SurrealDB version 3.1.4 that corrects the enforcement of element-level SELECT permissions. Users should upgrade to version 3.1.4 or later. As a workaround, avoid relying on element-level permissions to hide data from record users and instead use field-level permissions, which are enforced correctly. Additionally, restrict record users from selecting tables that use element-level permissions until patched.
Technical Details
- Gcve Source
- db.gcve.eu
- Osv Id
- GHSA-8rw6-p7m8-63jp
- Osv Schema Version
- 1.4.0
- Aliases
- []
- Ecosystems
- ["crates.io"]
- Database Specific Severity
- MODERATE
- Cvss Version
- 3.1
Threat ID: 6a7ff5f6bf8831d539880084
Added to database: 08/15/2026, 05:15:34 UTC
Last enriched: 08/15/2026, 05:42:26 UTC
Last updated: 08/15/2026, 06:57:17 UTC
Views: 3
Community Reviews
0 reviewsCrowdsource mitigation strategies, share intel context, and vote on the most helpful responses. Sign in to add your voice and help keep defenders ahead.
Want to contribute mitigation steps or threat intel context? Sign in or create an account to join the community discussion.
Actions
Updates to AI analysis require Pro Console access. Upgrade inside Console → Billing.
External Links
Need more coverage?
Upgrade to Pro Console for AI refresh and higher limits.
For incident response and remediation, OffSeq services can help resolve threats faster.
Latest Threats
Check if your credentials are on the dark web
Instant breach scanning across billions of leaked records. Free tier available.