Listen to this Post
How the CVE Works
SurrealDB, a multi-model database, provides an `UPDATE … PATCH` statement that allows callers to modify records using JSON Patch operations as defined in RFC 6902. Among these operations is copy, which is designed to duplicate the value from one field (from) into another field (path) within the same record.
A critical vulnerability was discovered in how SurrealDB parsed the `from` pointer of a `copy` (and move) operation. When an attacker supplied an empty string as the `from` pointer—for example, in a query like UPDATE thing:1 PATCH [{ op: 'copy', from: '', path: '/leak' }]—the database engine misinterpreted this as a directive to copy the entire record. This resulted in every field of the target record, including those the caller should not have permission to read, being duplicated into the attacker-specified destination field.
The core of the issue lies in the database’s permission and filtering mechanism. SurrealDB implements field-level `PERMISSIONS FOR select` restrictions to control which fields a user can view. Normally, the response filter knows to hide protected fields based on their original names. However, in this vulnerability, the protected data was copied to a new, attacker-chosen field name (e.g., /leak). The existing permission filter was only aware of the original field names and did not recognize the new destination as containing sensitive information. Consequently, the protected values were returned to the caller intact under the new field name, bypassing the security controls.
An authenticated user with permission to issue `UPDATE … PATCH` against a record could exploit this flaw to read the values of any field on that record, regardless of field-level `PERMISSIONS FOR select` restrictions. The impact is limited to a confidentiality breach and is bounded to the fields of the single record targeted per `PATCH` request. It does not expose other records or data outside that record’s scope.
DailyCVE Form:
Platform: SurrealDB
Version: < 3.1.0
Vulnerability: Info Disclosure
Severity: Medium
Date: 2025-04-10
Prediction: 2025-04-11
What Undercode Say:
The exploitation of this vulnerability is trivial and requires only basic knowledge of the SurrealQL `PATCH` syntax.
Example of a malicious PATCH request
UPDATE thing:1 PATCH [{ op: 'copy', from: '', path: '/leak' }];
This simple query would copy all fields of the record `thing:1` into the new field leak, exposing any protected data.
-- If the record has a protected 'secret' field, it would now be accessible as 'leak'
SELECT FROM thing:1;
-- Result: { id: thing:1, name: "public", secret: "sensitive", leak: { id: thing:1, name: "public", secret: "sensitive" } }
Exploit:
An attacker needs only authenticated access to the SurrealDB instance and permission to run `UPDATE … PATCH` queries. The exploit steps are:
1. Identify a target record (e.g., `thing:1`).
- Craft a `PATCH` request with a `copy` operation where the `from` field is an empty string.
- Set the `path` to a new, non-existent field name (e.g.,
/exfiltrated_data). - Execute the query. The response will contain the full, original record duplicated under the new field, including any protected fields.
Protection:
The primary protection is to upgrade to SurrealDB version 3.1.0 or later, where a patch has been introduced that rejects an empty `from` pointer at parse time for both `copy` and `move` operations.
For users unable to upgrade immediately, the following workarounds are recommended:
– Restrict PATCH Permissions: Limit the `UPDATE … PATCH` statement to callers who already hold `SELECT` permission on every field of the target record. For these users, the bug exposes nothing they cannot already read.
– Use Alternative Mutations: Switch to using an explicit `SET` or `MERGE` clause for mutations. These forms do not accept JSON Patch operations, thus removing the attack surface entirely.
Impact:
- Confidentiality: An authenticated user can read the values of any field on a targeted record, bypassing field-level `PERMISSIONS FOR select` restrictions.
- Integrity: None. The vulnerability is for information disclosure only.
- Availability: None. The vulnerability does not lead to a denial of service.
- Scope: The leak is bounded to the fields of the single record the caller targets per `PATCH` request. It does not expose other records on the same table or any data outside that record’s scope.
🎯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
