Summary
SurrealDB contains a confused deputy privilege escalation issue where fields with futures, functions, or closures execute under the permissions of the user who later queries them rather than the creator.
An unprivileged attacker can plant malicious logic in records that, when accessed by a higher-privileged user, runs with elevated rights and may lead to full privilege escalation and server takeover.
SurrealDB contains a confused deputy privilege escalation issue where fields with futures, functions, or closures execute under the permissions of the user who later queries them rather than the creator.
An unprivileged attacker can plant malicious logic in records that, when accessed by a higher-privileged user, runs with elevated rights and may lead to full privilege escalation and server takeover.
Affected context
This vulnerability appears in SurrealDB deployments where:
- Application logic or users allow untrusted or semi-trusted roles (such as editor/database users) to define or modify record fields containing executable constructs (futures, functions, closures)
- Higher-privileged users regularly read or write those records as part of normal operations
- The execution context for these constructs is bound to the querying user's privileges rather than their original author
It is most relevant in multi-tenant or role-based environments where different users share access to the same datasets with differing privilege levels.
This vulnerability appears in SurrealDB deployments where:
- Application logic or users allow untrusted or semi-trusted roles (such as editor/database users) to define or modify record fields containing executable constructs (futures, functions, closures)
- Higher-privileged users regularly read or write those records as part of normal operations
- The execution context for these constructs is bound to the querying user's privileges rather than their original author
It is most relevant in multi-tenant or role-based environments where different users share access to the same datasets with differing privilege levels.
Exploit preconditions
- Attack surface: Database query interface (e.g., API, client SDKs, database console)
- Required access: Ability for a lower-privileged account to create or modify records and embed futures, functions, or closures in fields
- Trigger point: A higher-privileged user (such as an administrator or owner) later reads, evaluates, or writes the affected record, causing the embedded logic to execute
- Why exploitation is possible: The system treats embedded logic as trusted and executes it under the privileges of the querying user, effectively allowing attacker-controlled logic to run with elevated rights (confused deputy pattern).
- Attack surface: Database query interface (e.g., API, client SDKs, database console)
- Required access: Ability for a lower-privileged account to create or modify records and embed futures, functions, or closures in fields
- Trigger point: A higher-privileged user (such as an administrator or owner) later reads, evaluates, or writes the affected record, causing the embedded logic to execute
- Why exploitation is possible: The system treats embedded logic as trusted and executes it under the privileges of the querying user, effectively allowing attacker-controlled logic to run with elevated rights (confused deputy pattern).
Why this happens
The underlying bug belongs to the confused deputy / authorization context mix-up class described by CWE-639: Authorization Bypass Through User-Controlled Key.
In this case, SurrealDB allows user-controllable fields to hold executable constructs (futures, functions, closures) that are evaluated in the context of another principal (the querying user).
Instead of binding the execution context to the originator of the code or treating embedded logic as unprivileged data, the database reuses the caller's authority, creating an implicit privilege escalation path.
This insecure pattern arises when authorization checks and execution context are not tightly coupled, allowing one user to indirectly cause another, more privileged, user to perform actions on their behalf.
The underlying bug belongs to the confused deputy / authorization context mix-up class described by CWE-639: Authorization Bypass Through User-Controlled Key.
In this case, SurrealDB allows user-controllable fields to hold executable constructs (futures, functions, closures) that are evaluated in the context of another principal (the querying user).
Instead of binding the execution context to the originator of the code or treating embedded logic as unprivileged data, the database reuses the caller's authority, creating an implicit privilege escalation path.
This insecure pattern arises when authorization checks and execution context are not tightly coupled, allowing one user to indirectly cause another, more privileged, user to perform actions on their behalf.
Potential impact
- Attacker-controlled logic may execute with administrator or owner privileges
- Creation or promotion of attacker accounts to root or owner roles
- Modification or deletion of sensitive data across multiple tenants or databases
- Unauthorized configuration changes leading to full server takeover
- Bypass of application-level access controls that rely on database role separation
- Attacker-controlled logic may execute with administrator or owner privileges
- Creation or promotion of attacker accounts to root or owner roles
- Modification or deletion of sensitive data across multiple tenants or databases
- Unauthorized configuration changes leading to full server takeover
- Bypass of application-level access controls that rely on database role separation
General mitigation guidance
Mitigation typically focuses on separating data from executable logic and binding execution context to the correct principal.
Common defensive patterns include:
- Disallowing untrusted roles from defining or modifying fields that can contain executable constructs (futures, functions, closures), or treating such fields as data-only for those roles
- Ensuring that any stored executable logic always runs in a least-privilege context that is independent of the querying user's permissions
- Introducing explicit, centralized authorization checks before executing user-supplied logic, with clear rules about which roles may own and invoke such constructs
- Using schema and policy constraints to distinguish between trusted system-owned fields and user-owned fields, preventing low-privileged users from influencing trusted execution paths
- Applying the principle of least privilege to database roles and avoiding overly broad editor or maintenance roles in shared environments
Mitigation typically focuses on separating data from executable logic and binding execution context to the correct principal.
Common defensive patterns include:
- Disallowing untrusted roles from defining or modifying fields that can contain executable constructs (futures, functions, closures), or treating such fields as data-only for those roles
- Ensuring that any stored executable logic always runs in a least-privilege context that is independent of the querying user's permissions
- Introducing explicit, centralized authorization checks before executing user-supplied logic, with clear rules about which roles may own and invoke such constructs
- Using schema and policy constraints to distinguish between trusted system-owned fields and user-owned fields, preventing low-privileged users from influencing trusted execution paths
- Applying the principle of least privilege to database roles and avoiding overly broad editor or maintenance roles in shared environments
How teams detect issues like this
Effective detection combines code, configuration, and behavioral analysis:
- Static analysis and schema review: Identify schema definitions and migrations where fields are allowed to store executable constructs and are writable by low-privileged roles.
- Query and audit log review: Look for patterns where editor or low-privileged accounts create or update fields with futures, functions, or closures, especially those later accessed by administrators.
- Policy enforcement: Define and enforce security policies that flag or block changes allowing executable logic in user-controlled fields.
- Automated review tools: Use database linting, configuration scanners, or security-focused CI checks to surface dangerous combinations of field capabilities and role permissions before deployment.
Effective detection combines code, configuration, and behavioral analysis:
- Static analysis and schema review: Identify schema definitions and migrations where fields are allowed to store executable constructs and are writable by low-privileged roles.
- Query and audit log review: Look for patterns where editor or low-privileged accounts create or update fields with futures, functions, or closures, especially those later accessed by administrators.
- Policy enforcement: Define and enforce security policies that flag or block changes allowing executable logic in user-controlled fields.
- Automated review tools: Use database linting, configuration scanners, or security-focused CI checks to surface dangerous combinations of field capabilities and role permissions before deployment.
