Listen to this Post
How the CVE Works
In SurrealDB, the `RELATE` statement is used to create a directed edge record between two existing node records in a graph. When a `RELATE` statement is issued, SurrealDB enforces the `CREATE` permission on the target edge table for this operation. This is the intended behavior, as the operation is logically a record creation.
However, a vulnerability existed in versions prior to 3.1.0 where the permission check did not align with the actual storage operation when a custom ID was provided. An attacker could issue a `RELATE` statement that included a `SET id = edge:existing` clause, where `edge:existing` was the identifier of an edge record that already existed in the database.
Instead of failing with a “record already exists” error—which is the standard and expected behavior for a `CREATE` operation—the database’s storage layer would silently overwrite the existing edge record with the new data provided in the `RELATE` statement. This occurred because the internal code path used `set_record` instead of `put_record` when handling a `RELATE` statement on the create path.
The critical security flaw was that this overwrite happened without checking if the caller had the necessary `UPDATE` permission on the edge table. The operation was only gated by the `CREATE` permission, which the attacker possessed. An authenticated user with only `CREATE` permission on an edge table could therefore replace any existing edge record on that table, including edges they had no `UPDATE` permission for.
The impact was limited to data integrity; the attack could not be used to read data or escalate privileges beyond overwriting existing edge records. The vulnerability was addressed in version 3.1.0 by adding an explicit `Statement::Relate` arm that uses `put_record` for the create path. Conflicting writes now correctly return a `RecordExists` error. Applications that relied on the old behavior of `RELATE … SET id = …` to silently replace existing edges will need to adapt, as those calls will now fail. For “create or replace” semantics, the `UPSERT` statement should be used, which correctly enforces `UPDATE` permissions for the replacement part.
DailyCVE Form
Platform: …….
SurrealDB
Version: ……..
< 3.1.0
Vulnerability :……
Authorization Bypass
Severity: …….
Medium
date: ……….
2026-07-01
Prediction: …….
Already Patched
What Undercode Say: Analytics
The vulnerability stems from a mismatch between permission enforcement and the underlying storage operation in the `RELATE` statement.
– Permission Mismatch: The `CREATE` permission was checked, but the operation performed was an `UPDATE` (overwrite).
– Silent Failure: The database did not return an error when attempting to create a record with an existing ID, leading to unexpected data loss or corruption.
– Integrity-Only Attack: The attacker could only modify existing data, not read or delete it, limiting the scope of the damage.
Exploit
An attacker with `CREATE` permission on an edge table can exploit this vulnerability by issuing a `RELATE` statement with a `SET id` clause that points to an existing edge record.
Example Exploit Query:
-- Assume the attacker has CREATE permission on the 'follows' edge table -- And the edge 'follows:alice_follows_bob' already exists RELATE user:alice -> follows -> user:bob SET id = follows:alice_follows_bob, weight = 100;
This query would overwrite the existing `follows:alice_follows_bob` record with new data (e.g., setting weight = 100), even if the attacker lacks `UPDATE` permission on the `follows` table.
Protection
- Upgrade: The primary and most effective protection is to upgrade to SurrealDB version 3.1.0 or later, which includes the patch.
- Workaround for Unpatched Versions:
- Avoid Custom IDs: If possible, do not use the `SET id = …` clause in `RELATE` statements. Let SurrealDB auto-generate the edge ID, as this path is not affected by the vulnerability.
- Pre-flight Check: If deterministic IDs are required, perform a `SELECT` on the target edge ID before issuing the `RELATE` statement to ensure it does not already exist.
- Restrict Permissions: Limit `CREATE` permission on edge tables to only those principals who are fully trusted with `UPDATE` permissions on the same table.
Impact
- Integrity Violation: An attacker could corrupt or alter critical relationship data within the graph.
- Bypass of Access Controls: The vulnerability allows a user to modify records they should not have permission to update, effectively bypassing the database’s permission system.
- Potential for Logic Errors: Applications that rely on the uniqueness of edge IDs could experience unexpected behavior or data inconsistencies if an edge is silently overwritten.
🎯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
