SurrealDB before 2.0.4 Improper Authorization via SELECT Permissions

CISA KEV is observed exploitation evidence. FIRST EPSS is a dated prediction of exploitation in the next 30 days. Missing scores are unknown. This collector requests predictions only for explicit CVE aliases in the public NuGet archive; Microsoft release views retain their existing prediction scope.

No collected risk observation for these identifiers. This does not establish absence of exploitation or a zero probability.

SurrealDB versions before 2.0.4 fail to properly enforce field permissions during SELECT, UPDATE, and DELETE operations, allowing authorized users to access unauthorized field values through various query techniques. Attackers can exploit SELECT VALUE operations, field aliasing, function arguments, WHERE clause filtering, RETURN BEFORE clauses, and SET clause references to leak protected field contents despite lacking SELECT permissions.

Source published

18 Jul 2026 13:10:07 UTC

Source modified

28 Jul 2026 01:47:53 UTC

Observed here

23 Oct 2026 15:48:27 UTC

Source terms

CVE Program Terms of Use

Original source record · Cite this exact observation · Complete original publisher JSON

This view projects the publisher's source fields for reading; the original JSON retains additional fields and CVE enrichment containers. Attribution: cve-program · CVE Program Terms of Use. Source text is retained; field grouping and change labels are provided by ChangeIntel.

CVSS 4.0 · 7.1 CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:H/VI:N/VA:N/SC:N/SI:N/SA:N

SurrealDB versions before 2.0.4 fail to properly enforce field permissions during SELECT, UPDATE, and DELETE operations, allowing authorized users to access unauthorized field values through various query techniques. Attackers can exploit SELECT VALUE operations, field aliasing, function arguments, WHERE clause filtering, RETURN BEFORE clauses, and SET clause references to leak protected field contents despite lacking SELECT permissions.

Source published

Jul 18, 2026, 1:10:07 PM (timezone not stated)

Source modified

Jul 28, 2026, 1:47:53 AM (timezone not stated)

Observed here

29 Oct 2026 21:24:43 UTC

Source terms

ENISA EUVD · source terms and attribution apply

Original source record · Cite this exact observation · Complete original publisher JSON

This view projects the publisher's source fields for reading; the original JSON retains additional fields and CVE enrichment containers. Attribution: euvd · ENISA EUVD · source terms and attribution apply. Source text is retained; field grouping and change labels are provided by ChangeIntel.

EUVD CVSS 4.0 · 7.1 CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:H/VI:N/VA:N/SC:N/SI:N/SA:N

SurrealDB versions before 2.0.4 fail to properly enforce field permissions during SELECT, UPDATE, and DELETE operations, allowing authorized users to access unauthorized field values through various query techniques. Attackers can exploit SELECT VALUE operations, field aliasing, function arguments, WHERE clause filtering, RETURN BEFORE clauses, and SET clause references to leak protected field contents despite lacking SELECT permissions.

Source published

18 Jul 2026 14:17:09 UTC

Source modified

27 Oct 2026 18:10:00 UTC

Observed here

29 Oct 2026 03:27:18 UTC

Source terms

NIST NVD usage terms; underlying source attribution retained

Original source record · Cite this exact observation · Complete original publisher JSON

This view projects the publisher's source fields for reading; the original JSON retains additional fields and CVE enrichment containers. Attribution: nvd · NIST NVD usage terms; underlying source attribution retained. Source text is retained; field grouping and change labels are provided by ChangeIntel.

CVSS 4.0 · [email protected] · Secondary · 7.1 CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:H/VI:N/VA:N/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X

CVSS 3.1 · [email protected] · Primary · 6.5 CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N

Due to the order in which permissions were processed, some statements, filters and computations could lead to leaking field values or record contents to users without the required permissions. This behavior could be triggered in different scenarios: - When performing a `SELECT` operation on a table, the values that would be returned were iterated over, field permissions would be validated and any unauthorized value would be removed from the result returned. However, performing a `SELECT VALUE` operation (e.g. `SELECT VALUE private FROM data`) would result in a non-iterable value, which would not be removed from the returned result. - When aliasing a field (e.g. `SELECT private AS public FROM data`) for which the user did not have `SELECT` permissions within a `SELECT` query, permissions would be checked against the field of the resulting document containing the aliased field instead of the original document containing the original field. As a consequence, the original field value would be returned as the returned field would not match the original field where permissions had been defined. - When calling a function in the context of a `SELECT` query and passing a field with permissions as an argument to the function (e.g. `SELECT string::lowercase(private) FROM data`), the function would receive the field value before it had been removed from the document due to `SELECT` permissions. As a result, the function would have access to the value of the field regardless of field permissions. This case includes functions called from within events and other clauses that support function calling. - When executing a query containing a `WHERE` clause filtering records by a field that the querying user does not have access to `SELECT` (e.g. `SELECT public FROM data WHERE private ~ "secret"`), the response of that query would still take the value of the field into account. Even though the value of the protected field would not be returned, this behavior could be used as a side channel by the querying user to infer information about the value of the field. - When performing `UPDATE` or `DELETE` operations over a table with a user that had those permissions but no `SELECT` permission, the `RETURN BEFORE` clause could be used (e.g. `DELETE data RETURN BEFORE`) to read the contents of the records prior to the authorized update or the deletion despite the querying user not being authorized to perform `SELECT` operations. - When performing `UPDATE` operations on a table for which the user had `SELECT` and `UPDATE` permissions, the `SET` clause could reference fields that the user had `UPDATE` but no `SELECT` permission for (e.g. `UPDATE data SET public = private`) in order to update the value of a field that the user had permission to `SELECT` to the value of another field for which the user did not. ### Impact Clients that were authorized by table permissions to execute `SELECT` statements for a table but were not authorized by field permissions to run `SELECT` queries for a specific field could still have been able to gain knowledge of the value of that field. Additionally, clients that were authorized to execute `UPDATE` or `DELETE` statements for a table but not authorized to execute `SELECT` statements for the same table may have been able to gain knowledge of the contents of records in that table. This could only be exploited by users who were already authorized to execute queries on the database with the affected table or field. Due to its relationship with table and field permissions, which apply mainly to record users rather than system users, this issue mostly affects users relying on SurrealDB as a backend-as-a-service rather than SurrealDB as a traditional database backend. ### Patches The behavior when evaluating table or field permissions and filtering records or fields as a result of those evaluations has been improved to consider permissions before any changes to the document have been made and, when relevant, permissions after changes to the document have taken place. When a user is unauthorized to view record contents and field values by permissions, the returned documents will behave as if the record or field did not exist in order to prevent leaking any information. - Version 2.0.4 and later are not affected by this issue. ### Workarounds Users affected by this issue and unable to update should not rely on the authorization provided by field permissions when it comes to the `SELECT` permission. Instead, read access to fields in affected versions should be restricted at the table level. When allowing the `UPDATE` or `DELETE` operations for records via table permissions, users should not rely of the authorization provided by the `SELECT` permission. Instead, users should not allow clients to `UPDATE` or `DELETE` records that they should not be able to view.

Source published

8 Oct 2024 22:21:09 UTC

Source modified

4 Sep 2026 20:00:28 UTC

Observed here

24 Oct 2026 13:19:54 UTC

Source terms

GitHub Advisory Database · CC-BY-4.0

Original source record · Cite this exact observation · Complete original publisher JSON

This view projects the publisher's source fields for reading; the original JSON retains additional fields and CVE enrichment containers. Attribution: osv · GitHub Advisory Database · CC-BY-4.0. Source text is retained; field grouping and change labels are provided by ChangeIntel.

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

CVSS_V4 · CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:H/VI:N/VA:N/SC:N/SI:N/SA:N

Publisher rating · HIGH

## Duplicate Advisory This advisory has been withdrawn because it is a duplicate of GHSA-9722-9j67-vjcr. This link is maintained to preserve external references. ## Original Description SurrealDB versions before 2.0.4 fail to properly enforce field permissions during SELECT, UPDATE, and DELETE operations, allowing authorized users to access unauthorized field values through various query techniques. Attackers can exploit SELECT VALUE operations, field aliasing, function arguments, WHERE clause filtering, RETURN BEFORE clauses, and SET clause references to leak protected field contents despite lacking SELECT permissions.

Source published

18 Jul 2026 15:31:49 UTC

Source modified

4 Sep 2026 19:45:07 UTC

Observed here

24 Oct 2026 13:19:54 UTC

Source terms

GitHub Advisory Database · CC-BY-4.0

Original source record · Cite this exact observation · Complete original publisher JSON

This view projects the publisher's source fields for reading; the original JSON retains additional fields and CVE enrichment containers. Attribution: osv · GitHub Advisory Database · CC-BY-4.0. Source text is retained; field grouping and change labels are provided by ChangeIntel.

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

CVSS_V4 · CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:H/VI:N/VA:N/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X

Publisher rating · HIGH