CVE-2026-63745: SurrealDB Auth Bypass Vulnerability

CVE-2026-63745 Overview

CVE-2026-63745 is an authorization bypass vulnerability in SurrealDB versions before 3.1.0. Authenticated users can spoof composite record-id field values by writing to editable body fields. Permission rules that gate access on id components, such as tenant isolation checks, read the spoofed body field instead of the immutable id key. This flaw is tracked under CWE-639: Authorization Bypass Through User-Controlled Key and affects multi-tenant SurrealDB deployments that rely on composite record identifiers for access control.

Critical Impact
Authenticated attackers can bypass tenant isolation and access or modify records belonging to other tenants by writing spoofed field values that override permission checks.

Affected Products

SurrealDB versions prior to 3.1.0
Multi-tenant SurrealDB deployments using composite record identifiers
Applications relying on SurrealDB permission rules gated on id components

Discovery Timeline

2026-07-20 - CVE-2026-63745 published to NVD
2026-07-22 - Last updated in NVD database

Technical Details for CVE-2026-63745

Vulnerability Analysis

SurrealDB supports composite record identifiers where the id key contains multiple components, such as a tenant identifier and a record identifier. Developers commonly write permission rules that inspect these id components to enforce tenant isolation or access boundaries. The vulnerability arises because SurrealDB permission evaluation reads same-named fields from the record body rather than exclusively from the immutable id key. An authenticated user who can write to record body fields can supply a value that shadows the id component during permission evaluation.

The impact centers on horizontal privilege escalation across tenant or logical boundaries. An attacker with valid credentials for one tenant can craft records whose body contains a spoofed tenant field. Permission checks that expected to read the immutable id then evaluate the attacker-controlled body value and grant access. This defeats access control assumptions in multi-tenant architectures built on SurrealDB.

Root Cause

The root cause is inconsistent field resolution during permission rule evaluation. Composite id components are exposed to policy logic under names that collide with writable body fields. When the permission engine resolves the field reference, it selects the mutable body value instead of the immutable id key. The database does not enforce that id-derived identifiers take precedence over body fields of the same name.

Attack Vector

Exploitation requires network access and low-privilege authenticated credentials. No user interaction is required. An attacker submits a record write operation that includes a body field named identically to a composite id component. The permission rule reads the spoofed body value, evaluates the policy as satisfied, and permits access to resources owned by another tenant. The vulnerability affects confidentiality and integrity, as attackers can both read and modify cross-tenant data reachable through the affected permission rules.

See the VulnCheck Advisory on SurrealDB and the GitHub Security Advisory GHSA-6vg3-hgrw-p5gf for additional technical details.

Detection Methods for CVE-2026-63745

Indicators of Compromise

Record write operations where body field names match composite id component names such as tenant, org, or account.
Successful read or update operations that cross tenant boundaries in application audit logs.
Unexpected query results returning records outside the authenticated user's tenant scope.
SurrealDB query logs showing CREATE or UPDATE statements that set fields with the same names used inside record ids.

Detection Strategies

Audit permission rules (PERMISSIONS FOR select, update, delete) that reference field names also present in composite record ids.
Correlate authenticated user identifiers against tenant identifiers accessed to surface cross-tenant activity.
Compare id-derived tenant components against body field values in stored records to detect prior spoofing.
Review application-layer logs for API calls submitting tenant-scoped fields directly from client input.

Monitoring Recommendations

Enable query and audit logging on SurrealDB and forward events to a centralized analytics platform for correlation.
Alert when a session authenticated as tenant A performs write or read operations resolving to tenant B records.
Track write volume to fields that share names with id components as a leading indicator of exploitation attempts.

How to Mitigate CVE-2026-63745

Immediate Actions Required

Upgrade SurrealDB to version 3.1.0 or later, which addresses the field-resolution flaw.
Inventory all schemas using composite record ids and review permission rules that depend on id components.
Rotate credentials for accounts with write access if exploitation is suspected based on log review.
Validate stored records to confirm body fields with id-colliding names match their id counterparts.

Patch Information

SurrealDB resolved CVE-2026-63745 in release 3.1.0. The fix is documented in the SurrealDB GitHub Security Advisory GHSA-6vg3-hgrw-p5gf. Administrators should apply the update to all SurrealDB instances used in production and staging environments. Verify the running version after upgrade using surreal version.

Workarounds

Rewrite permission rules to reference id components explicitly via the id accessor rather than field names that may collide with body fields.
Enforce schema-level ASSERT constraints that reject body fields whose values disagree with the corresponding id component.
Restrict write permissions so untrusted users cannot set fields that participate in authorization decisions.
Introduce application-layer validation that strips tenant-scoping fields from client-supplied payloads before persisting records.

bash

# Upgrade SurrealDB to a patched version
surreal version
# Example: pull the patched container image
docker pull surrealdb/surrealdb:v3.1.0

# Example schema hardening: assert body field matches id component
DEFINE FIELD tenant ON TABLE resource
  ASSERT $value = meta::tb($this.id);