GHSA-whwg-vh4f-pmmf CVE-2026-49997

SurrealDB: Edge PERMISSIONS FOR delete bypassed when a connected node is deleted

Medium crates.io

Severity: 5.4 / 10; Medium · CVSS 3.1
Exploit chance (EPSS): 0.35%; Chance of exploitation in the next 30 days. Higher than 28.34% of scored vulnerabilities.
Known exploited: No; Not in CISA's catalog
Weakness: CWE-285 Improper Authorization; CWE-863 Incorrect Authorization
Fix: 3.1.0; Upgrade surrealdb to this version or later

Description

In SurrealDB, records can be connected as a graph: a RELATE statement creates an edge record between two node records. If either endpoint node is deleted, SurrealDB automatically removes the edge row to keep the graph consistent.

A user with permission to delete a node could also delete the edges connected to that node, even when the edge table's PERMISSIONS FOR delete clause should have stopped them.

The automatic edge removal (Document::purge_edges) ran with permissions disabled (opt.clone().with_perms(false)), so the edge table's PERMISSIONS FOR delete and PERMISSIONS FOR select clauses were never consulted. The removal step could also observe edge state that the edge's SELECT clause should have hidden.

Impact

What an attacker can do:

Delete any edge connected to a node they can delete, regardless of the edge table's PERMISSIONS FOR delete clause.
Observe edge contents that PERMISSIONS FOR select should have hidden, as a side effect of the same edge-removal step.

What it can't do:

Delete nodes on tables they do not hold DELETE on (the edge removal only runs from an authorised node delete).
Cross namespace or database isolation boundaries.
Escalate to root or operator-level privileges.

Patches

Document::purge_edges now propagates the caller's permission context into the edge removal. Each connected edge DELETE is evaluated against the edge table's PERMISSIONS FOR delete clause, matching a direct DELETE.

Versions 3.1.0 and later are not affected.

Workarounds

Restrict node DELETE permission to principals trusted to delete all connected edge records.
Use namespace or database isolation as the primary boundary where edge-level PERMISSIONS is load-bearing for multi-tenant separation.

Affected versions

crates.io

Package	Vulnerable	Fixed in
surrealdb	`< 3.1.0`	`3.1.0`

How to fix

Move to the fixed version or later with your package manager, update the lockfile, and run your tests. If the package only arrives through another dependency, upgrade that dependency first. If none of its releases pulls a fixed version yet, force the version with your package manager's override.

surrealdb crates.io → `3.1.0`

cargo

cargo update -p surrealdb --precise 3.1.0

Severity breakdown

CVSS 3.1 5.4

CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:L/A:N

Attack vector: Network
Attack complexity: Low
Privileges required: Low
User interaction: None
Scope: Unchanged
Confidentiality: Low
Integrity: Low
Availability: None

Weakness

CWE-285: Improper Authorization

The product does not perform or incorrectly performs an authorization check when an actor attempts to access a resource or perform an action.

How to prevent it

Architecture and Design: Divide the product into anonymous, normal, privileged, and administrative areas. Reduce the attack surface by carefully mapping roles with data and functionality. Use role-based access control (RBAC) to enforce the roles at the appropriate boundaries. Note that this approach may not protect against horizontal authorization, i.e., it will not protect a user from attacking others with the same role.
Architecture and Design: Ensure that you perform access control checks related to your business logic. These checks may be different than the access control checks that you apply to more generic resources such as files, connections, processes, memory, and database records. For example, a database may restrict access for medical records to a specific database user, but each record might only be intended to be accessible to the patient and the patient's doctor.
Architecture and Design: Use a vetted library or framework that does not allow this weakness to occur or provides constructs that make this weakness easier to avoid. For example, consider using authorization frameworks such as the JAAS Authorization Framework [REF-233] and the OWASP ESAPI Access Control feature [REF-45].
Architecture and Design: For web applications, make sure that the access control mechanism is enforced correctly at the server side on every page. Users should not be able to access any unauthorized functionality or information by simply requesting direct access to that page. One way to do this is to ensure that all pages containing sensitive information are not cached, and that all such pages restrict access to requests that are accompanied by an active and authenticated session token associated with a user who has the required permissions to access that page.
System Configuration, Installation: Use the access control capabilities of your operating system and server environment and define your access control lists accordingly. Use a "default deny" policy when defining these ACLs.

CWE-863: Incorrect Authorization

The product performs an authorization check when an actor attempts to access a resource or perform an action, but it does not correctly perform the check.

How to prevent it

Architecture and Design: Divide the product into anonymous, normal, privileged, and administrative areas. Reduce the attack surface by carefully mapping roles with data and functionality. Use role-based access control (RBAC) [REF-229] to enforce the roles at the appropriate boundaries. Note that this approach may not protect against horizontal authorization, i.e., it will not protect a user from attacking others with the same role.
Architecture and Design: Ensure that access control checks are performed related to the business logic. These checks may be different than the access control checks that are applied to more generic resources such as files, connections, processes, memory, and database records. For example, a database may restrict access for medical records to a specific database user, but each record might only be intended to be accessible to the patient and the patient's doctor [REF-7].
Architecture and Design: Use a vetted library or framework that does not allow this weakness to occur or provides constructs that make this weakness easier to avoid. For example, consider using authorization frameworks such as the JAAS Authorization Framework [REF-233] and the OWASP ESAPI Access Control feature [REF-45].
Architecture and Design: For web applications, make sure that the access control mechanism is enforced correctly at the server side on every page. Users should not be able to access any unauthorized functionality or information by simply requesting direct access to that page. One way to do this is to ensure that all pages containing sensitive information are not cached, and that all such pages restrict access to requests that are accompanied by an active and authenticated session token associated with a user who has the required permissions to access that page.
System Configuration, Installation: Use the access control capabilities of your operating system and server environment and define your access control lists accordingly. Use a "default deny" policy when defining these ACLs.

References

Advisories

nvd.nist.gov/vuln/detail/CVE-2026-49997

Packages

github.com/surrealdb/surrealdb

Timeline

Jul 1, 2026 Published
Jul 20, 2026 Last updated by the source
Oct 31, 2026 Latest EPSS score

Advisory	Severity	Why it's related
GHSA-8rw6-p7m8-63jp SurrealDB: Array element-level (field.*) SELECT permissions leak denied elements to record users	High	Also affects surrealdb
GHSA-848m-r628-vrxw SurrealDB: Custom API route lets authenticated callers override namespace/database scope via URL path	High	Also affects surrealdb
GHSA-m3c3-78fh-w3w7 SurrealDB allows bypass of deny-net flags via DNS resolution	High	Also affects SurrealDB
GHSA-fwg2-gr34-q3w8 SurrealDB: ES512 silently downgraded to ES384 due to jsonwebtoken crate limitation	Medium	Also affects surrealdb
GHSA-c8jx-96c9-8xrp SurrealDB: Field-level SELECT permissions bypassed via indexed COUNT fast paths	Medium	Also affects surrealdb
GHSA-wp87-mgvq-5j93 SurrealDB: USE NS/DB implicit creation bypasses DEFINE authorization	Medium	Also affects surrealdb
GHSA-97vg-427p-8hx5 SurrealDB: Port-specific --deny-net rules silently bypassed on HTTP redirect	Medium	Also affects surrealdb
GHSA-6wqw-vhfr-9999 SurrealDB: Authenticated subscribers can read records hidden by SELECT permissions via LIVE subscriptions	Medium	Also affects surrealdb

Is this in your code?

MergeHarbor checks every repository's dependencies against this database, ranks what matters by exploitability and reachability, routes it to the owning team and opens the fix pull request.

Check your repos with MergeHarbor