Summary
SurrealDB before 3.3.0 contains an authorization bypass that can expose fields restricted by SELECT permissions when JSON Patch operations resolve pointers against the unreduced record. A caller with table-level write permission may be able to disclose hidden values through copy or move behavior, or through information revealed by test mismatch errors.
SurrealDB before 3.3.0 contains an authorization bypass that can expose fields restricted by SELECT permissions when JSON Patch operations resolve pointers against the unreduced record. A caller with table-level write permission may be able to disclose hidden values through copy or move behavior, or through information revealed by test mismatch errors.
Affected context
The issue occurs in SurrealDB deployments where callers have write access to a table while field-level SELECT restrictions are also used. It becomes risky when JSON Patch processing operates on the complete underlying record before applying the intended visibility reduction, allowing write-capable callers to interact indirectly with fields they cannot normally read.
The issue occurs in SurrealDB deployments where callers have write access to a table while field-level SELECT restrictions are also used. It becomes risky when JSON Patch processing operates on the complete underlying record before applying the intended visibility reduction, allowing write-capable callers to interact indirectly with fields they cannot normally read.
Exploit preconditions
- Attack surface: JSON Patch handling for records in SurrealDB
- Required access: Table-level write permission; direct read permission for restricted fields is not required
- Trigger point: Processing of PATCH copy, move, or test operations
- Why exploitation is possible: JSON Patch pointers may be resolved against the unreduced record, and resulting values or mismatch errors can reveal restricted data
- Attack surface: JSON Patch handling for records in SurrealDB
- Required access: Table-level write permission; direct read permission for restricted fields is not required
- Trigger point: Processing of PATCH copy, move, or test operations
- Why exploitation is possible: JSON Patch pointers may be resolved against the unreduced record, and resulting values or mismatch errors can reveal restricted data
Why this happens
The underlying bug is an authorization boundary failure in which field-level visibility is enforced after JSON Patch pointer resolution rather than before all operations that can expose record content. This allows a caller with write authority to cause hidden fields to be copied into readable locations or indirectly reflected in error behavior. The issue maps to CWE-200 because information is disclosed to an actor without the intended authorization.
The underlying bug is an authorization boundary failure in which field-level visibility is enforced after JSON Patch pointer resolution rather than before all operations that can expose record content. This allows a caller with write authority to cause hidden fields to be copied into readable locations or indirectly reflected in error behavior. The issue maps to CWE-200 because information is disclosed to an actor without the intended authorization.
Potential impact
- Attackers may read fields restricted by SELECT permissions.
- Sensitive business, identity, or operational data could be disclosed.
- Error responses may provide an information disclosure oracle.
- Exposed records could support further abuse of application workflows.
- Attackers may read fields restricted by SELECT permissions.
- Sensitive business, identity, or operational data could be disclosed.
- Error responses may provide an information disclosure oracle.
- Exposed records could support further abuse of application workflows.
General mitigation guidance
Mitigation generally focuses on preserving field-level authorization across
every stage of mutation and validation processing.
Defensive patterns include:
- Applying visibility and authorization filtering before resolving pointers or evaluating patch operations.
- Preventing write-authorized callers from copying, moving, or testing values outside their readable field set.
- Returning uniform errors that do not reveal restricted values or distinguish sensitive conditions.
- Using explicit allowlists for patchable fields and operations.
- Applying least-privilege table and field permissions, with secure defaults that deny unnecessary read or write access.
- Treating stored records as sensitive until authorization has been evaluated rather than trusting the caller's write capability.
Mitigation generally focuses on preserving field-level authorization across
every stage of mutation and validation processing.
Defensive patterns include:
- Applying visibility and authorization filtering before resolving pointers or evaluating patch operations.
- Preventing write-authorized callers from copying, moving, or testing values outside their readable field set.
- Returning uniform errors that do not reveal restricted values or distinguish sensitive conditions.
- Using explicit allowlists for patchable fields and operations.
- Applying least-privilege table and field permissions, with secure defaults that deny unnecessary read or write access.
- Treating stored records as sensitive until authorization has been evaluated rather than trusting the caller's write capability.
How teams detect issues like this
Detection approaches may include:
- Static analysis and code review checks for authorization filtering performed after JSON pointer resolution or mutation preparation.
- Tests that combine write-only access with restricted fields and exercise copy, move, and test operations.
- Review of error paths for responses that reflect field values or reveal whether hidden values matched a condition.
- Policy enforcement requiring explicit field allowlists for patch operations.
- Runtime monitoring for unusual PATCH activity involving restricted or otherwise non-readable fields.
- Automated security testing and code review tools that model authorization checks across mutation and error-handling paths.
Detection approaches may include:
- Static analysis and code review checks for authorization filtering performed after JSON pointer resolution or mutation preparation.
- Tests that combine write-only access with restricted fields and exercise copy, move, and test operations.
- Review of error paths for responses that reflect field values or reveal whether hidden values matched a condition.
- Policy enforcement requiring explicit field allowlists for patch operations.
- Runtime monitoring for unusual PATCH activity involving restricted or otherwise non-readable fields.
- Automated security testing and code review tools that model authorization checks across mutation and error-handling paths.
