Attack ChainAIDerived
Hypothetical attack flow derived from CVE metadata – not a confirmed exploit chain
-
AccessAuthenticate as low-privileged record user
-
ExploitRegister LIVE SELECT aliasing $after/$before field
-
ExecutionTrigger CREATE/UPDATE/DELETE notification
-
ImpactReceive restricted field value in notification
Vulnerability Assessment
| Weakness |
CWE
OWASP Top 10:2025
A01:2025 - Broken Access Control
ASVS 5.0
V8 - Authorization Authorization logic validation
MITRE ATT&CK
1 technique across 1 tactic: Privilege Escalation The technique list with ATT&CK links and the kill-chain view is part of the Basic plan and up. |
| Exploitation Conditions | Exploitation requires an authenticated record user (PR:L) and a deployment that actually relies on field-level SELECT permissions to hide fields; the attacker must issue a LIVE SELECT query that projects a restricted field from the unreduced $after or $before parameters under an alias, then wait for (or trigger) a CREATE, UPDATE, or DELETE on matching records to receive the exact stored value in the live notification. Limiting factors: only SurrealDB versions before 3.3.0 are affected, valid record-user credentials are mandatory, the leak is confined to fields hidden by field-level permissions on records the user can otherwise observe via live queries, and impact is read-only disclosure (no write or availability effect). |
| Impact | This is a medium-severity, confidentiality-only information-disclosure issue, not a high-priority emergency. The vendor-supplied CVSS 4.0 vector (AV:N/AC:L/AT:N/PR:L/UI:N/VC:L/VI:N/VA:N) scores 5.3 and is internally consistent with the description: network-reachable but requiring an authenticated record user (PR:L), low confidentiality impact only, and no integrity or availability impact - matching CWE-863 (incorrect authorization). No EPSS score, CISA KEV listing, or POC indicator was provided in the intelligence, so there is no public exploit identified at time of analysis and no evidence of active exploitation. The practical risk is bounded: an attacker must already hold valid record-user credentials AND the deployment must actually rely on field-level SELECT permissions to hide data, so this is primarily a multi-tenant/row-level-security data-leak concern rather than a broadly wormable flaw. Note the input provides only a CVSS 4.0 vector (no 3.1 base vector), so cross-framework comparison relies on an assessed 3.1 vector below. |
| Exploit ScenarioDerived | A multi-tenant SurrealDB application uses field-level SELECT permissions to hide a sensitive column (e.g., another user's email or token) from low-privileged record users. An authenticated record user registers a LIVE SELECT that projects the hidden field from the unreduced $after parameter under an alias; when any CREATE/UPDATE/DELETE fires a live notification, they receive the exact stored value, bypassing the field permission. No public POC was identified in the provided intelligence. |
Get an e-mail when this CVE is exploited, patched or re-scored. Free account.
Alert meAnalysisAIv1 – Oct 12, 2026
Information disclosure in SurrealDB before 3.3.0 allows an authenticated record user to read fields that field-level SELECT permissions are meant to hide, by projecting a restricted field from the unreduced $after or $before parameters of a LIVE SELECT query under an alias. The exact stored value is then delivered inside CREATE, UPDATE, or DELETE live notifications, producing a read-only confidentiality leak scoped to records the user can already observe. Exploitation requires valid record-user credentials (PR:L, authenticated) and a deployment that actually relies on field-level SELECT permissions for secrecy; only versions before 3.3.0 are affected, and no public exploit identified at time of analysis. This is a medium-severity, confidentiality-only issue, not a high-priority emergency.
RemediationAI
Upgrade to SurrealDB 3.3.0 or later, the first release in which this issue is fixed; consult the GitHub security advisory GHSA-pm6c-q8rh-92m8 (https://github.com/surrealdb/surrealdb/security/advisories/GHSA-pm6c-q8rh-92m8) for the vendor's own guidance and the VulnCheck advisory (https://www.vulncheck.com/advisories/surrealdb-before-3.3.0-field-permission-bypass-via-live-select-before-after) for exploitation notes. If an immediate upgrade is not possible, treat field-level SELECT permissions as non-confidential for any data reachable through LIVE SELECT: move genuinely sensitive values into separate tables or records whose access is governed by table-level or record-level rules that do not depend on field hiding, and restrict which record roles are permitted to open LIVE SELECT queries, since the trade-off is loss of real-time subscription functionality for those users. Additionally, audit existing LIVE SELECT statements that reference $after or $before (especially with aliases) to detect queries that could already be extracting hidden values, and rotate or reclassify any secrets that may have been exposed by such queries. No vendor-released workaround short of upgrading is documented in the available references.
Affected VersionsENISA
Affected Packages
Source: OSV (Open Source Vulnerabilities)
Affects your stack
Affects 1 package in euvd
Checking this CVE against your own stacks and servers is part of the Basic plan and up.
Technical ContextAI · show details
SurrealDB is a multi-model database that implements fine-grained, in-database authorization: permissions can be granted at the table level and at the field level, so a record user may be allowed to read a record while specific fields (PERMISSIONS FOR select) remain hidden. LIVE SELECT turns a query into a subscription that pushes notifications to the client whenever matching records change, and each notification embeds the affected row state through the $after and $before parameters, which represent the post-change and pre-change values. The root cause is CWE-863 (Incorrect Authorization): the field-level permission filter is applied to the reduced projection returned by ordinary SELECT, but the $after/$before objects supplied to live notification projections are not subjected to the same reduction, so a user can alias a restricted field (for example projecting $after.secret AS x) and receive the raw stored value in the notification stream. The affected scope is captured by CPE cpe:2.3:a:surrealdb:surrealdb:*:*:*:*:*:*:*:* covering all releases before 3.3.0. Severity is bounded: the supplied CVSS 4.0 vector (AV:N/AC:L/AT:N/PR:L/UI:N/VC:L/VI:N/VA:N) yields a 5.3 base score, and an independent CVSS 3.1 assessment of AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N agrees that this is a network-reachable but low-confidentiality, no-integrity, no-availability flaw that cannot be triggered without credentials. Triggering a leak also requires the attacker to wait for, or cause, a CREATE, UPDATE, or DELETE on matching records so that a notification is emitted.
Know when Surrealdb gets its next vulnerability
- Watch products and get an email when something new is published
- Check this CVE against your own stack and servers
- Exploit and PoC references, threat intelligence from 22 sources
No credit card · 7-day full trial
Severity by source
CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:L/VI:N/VA:N/SC:N/SI:N/SA:N
Network-reachable LIVE query but requires an authenticated record user (PR:L); low confidentiality disclosure of hidden fields only, with no integrity or availability impact.
Primary rating from Vendor (VulnCheck).
CVSS VectorVendor: VulnCheck
Lifecycle Timeline
1DescriptionCVE.org
SurrealDB before 3.3.0 contains an authorization bypass vulnerability that allows record users to read fields hidden by field-level SELECT permissions through LIVE SELECT projections. Attackers can project restricted fields from the unreduced $after or $before parameters under an alias to receive exact stored values in CREATE, UPDATE, and DELETE notifications.
Threat Intelligence Overview
How this decision was reached
The engine reads each signal below and applies a fixed list of rules from top to bottom. The first rule that matches sets the recommended action – like a statement, every line is shown.
What every action level means
SSVC AssessmentENISA
Priority Score
Attack Technique
Authentication bypass attacks exploit flaws in the verification mechanisms that control access to systems and applications.
Privilege escalation via second-order SurrealQL injection in SurrealDB before 2.0.5, 2.1.5, and 2.2.2 lets an authentica
Privilege escalation in SurrealDB before v3.1.0 lets unauthenticated attackers hijack the privileges of concurrently-act
Denial of service in SurrealDB before 3.1.0 lets an unauthenticated remote attacker crash the database with a single Web
Denial of service in SurrealDB before 3.1.0 lets an unauthenticated remote attacker crash the entire database process wi
Session hijacking in SurrealDB before 3.1.0 lets unauthenticated attackers enumerate attached session UUIDs through the
SurrealDB versions before 3.3.0 fail to validate a caller's authorization level when the SurrealQL USE statement switche
Cross-tenant data access in SurrealDB before 3.3.0 allows an authenticated namespace- or database-level SYSTEM user to b
Cross-tenant authorization bypass in SurrealDB before 3.2.0 lets any authenticated user reach custom API endpoints belon
Arbitrary file read in SurrealDB before 3.1.5 lets an authenticated database user holding the EDITOR or OWNER role discl
Confused-deputy privilege escalation in SurrealDB before 2.5.0 and before 3.0.0-beta.3 lets a low-privileged user (e.g.
Denial of service in SurrealDB before 3.1.5 lets an authenticated user with query-execution privileges crash the entire
Denial of service in SurrealDB versions before 3.3.0 lets a query-capable authenticated user with embedded JavaScript sc
EUVD-2026-97638
GHSA-578j-w8qc-q89w
NVD
CVE.org
EPSS
Exploit-DB