surrealdb

An authenticated user scoped to one namespace/database could invoke a custom API (DEFINE API) belonging to a different namespace/database, reaching another tenant's endpoint.

The route /api/{namespace}/{database}/{endpoint} took the namespace and database from the URL and applied them to the caller's session before the endpoint was looked up or run, without checking that the caller's authenticated scope covered them. Because a custom API handler runs with permissions disabled (definer's rights), the endpoint's own PERMISSIONS clause was the only gate — open to everyone for a PERMISSIONS FULL endpoint. The api::invoke() function was affected the same way, resolving against the session's selected namespace/database (settable via the surreal-ns / surreal-db headers or USE).

Impact

What an attacker can do:

• With valid credentials for any one namespace/database (a VIEWER is enough), invoke a custom API in another namespace/database by naming the victim scope in the URL.
• Read data that endpoint returns — including from PERMISSIONS NONE tables, since the handler runs with permissions disabled — or trigger any writes and side effects it performs.

What it can't do:

• Reach a scope without valid credentials for some namespace/database on the instance; this is not an unauthenticated bypass.
• Affect single-tenant deployments, or any deployment where callers already hold instance-wide (root) scope.

Patches

The namespace/database is now validated against the caller's authenticated level — which the request cannot change — before the endpoint is resolved or run. A target scope outside that level is rejected with 403 Forbidden, both at the HTTP entry point and at the dispatch step shared with api::invoke(). Root reaches any scope; namespace principals their namespace; database and record principals their exact namespace/database; anonymous callers remain governed by the endpoint's PERMISSIONS.

• Versions 3.2.0 and later are not affected by this issue.

Workarounds

Users unable to patch should consider the following workarounds:

• Disable the custom API HTTP route via capabilities where it is not required.
• Treat separate deployments, not namespace/database boundaries, as the tenant isolation boundary on shared instances.
• Prefer a PERMISSIONS WHERE clause that checks the authenticated identity over PERMISSIONS FULL (reduces exposure but does not restore the boundary).

Resources

• SurrealQL Documentation — DEFINE API
• SurrealDB Documentation — Capabilities
• fix(core/api): reject cross-tenant custom API access (included in SurrealDB 3.2.0)

Acknowledgements

SurrealDB thanks sondt99 for reporting this issue.

An authenticated user scoped to one namespace/database could invoke a custom API (DEFINE API) belonging to a different namespace/database, reaching another tenant's endpoint.

The route /api/{namespace}/{database}/{endpoint} took the namespace and database from the URL and applied them to the caller's session before the endpoint was looked up or run, without checking that the caller's authenticated scope covered them. Because a custom API handler runs with permissions disabled (definer's rights), the endpoint's own PERMISSIONS clause was the only gate — open to everyone for a PERMISSIONS FULL endpoint. The api::invoke() function was affected the same way, resolving against the session's selected namespace/database (settable via the surreal-ns / surreal-db headers or USE).

Impact

What an attacker can do:

• With valid credentials for any one namespace/database (a VIEWER is enough), invoke a custom API in another namespace/database by naming the victim scope in the URL.
• Read data that endpoint returns — including from PERMISSIONS NONE tables, since the handler runs with permissions disabled — or trigger any writes and side effects it performs.

What it can't do:

• Reach a scope without valid credentials for some namespace/database on the instance; this is not an unauthenticated bypass.
• Affect single-tenant deployments, or any deployment where callers already hold instance-wide (root) scope.

Patches

The namespace/database is now validated against the caller's authenticated level — which the request cannot change — before the endpoint is resolved or run. A target scope outside that level is rejected with 403 Forbidden, both at the HTTP entry point and at the dispatch step shared with api::invoke(). Root reaches any scope; namespace principals their namespace; database and record principals their exact namespace/database; anonymous callers remain governed by the endpoint's PERMISSIONS.

• Versions 3.2.0 and later are not affected by this issue.

Workarounds

Users unable to patch should consider the following workarounds:

• Disable the custom API HTTP route via capabilities where it is not required.
• Treat separate deployments, not namespace/database boundaries, as the tenant isolation boundary on shared instances.
• Prefer a PERMISSIONS WHERE clause that checks the authenticated identity over PERMISSIONS FULL (reduces exposure but does not restore the boundary).

Resources

• SurrealQL Documentation — DEFINE API
• SurrealDB Documentation — Capabilities
• fix(core/api): reject cross-tenant custom API access (included in SurrealDB 3.2.0)

Acknowledgements

SurrealDB thanks sondt99 for reporting this issue.

An authenticated user scoped to one namespace/database could invoke a custom API (DEFINE API) belonging to a different namespace/database, reaching another tenant's endpoint.

The route /api/{namespace}/{database}/{endpoint} took the namespace and database from the URL and applied them to the caller's session before the endpoint was looked up or run, without checking that the caller's authenticated scope covered them. Because a custom API handler runs with permissions disabled (definer's rights), the endpoint's own PERMISSIONS clause was the only gate — open to everyone for a PERMISSIONS FULL endpoint. The api::invoke() function was affected the same way, resolving against the session's selected namespace/database (settable via the surreal-ns / surreal-db headers or USE).

Impact

What an attacker can do:

• With valid credentials for any one namespace/database (a VIEWER is enough), invoke a custom API in another namespace/database by naming the victim scope in the URL.
• Read data that endpoint returns — including from PERMISSIONS NONE tables, since the handler runs with permissions disabled — or trigger any writes and side effects it performs.

What it can't do:

• Reach a scope without valid credentials for some namespace/database on the instance; this is not an unauthenticated bypass.
• Affect single-tenant deployments, or any deployment where callers already hold instance-wide (root) scope.

Patches

The namespace/database is now validated against the caller's authenticated level — which the request cannot change — before the endpoint is resolved or run. A target scope outside that level is rejected with 403 Forbidden, both at the HTTP entry point and at the dispatch step shared with api::invoke(). Root reaches any scope; namespace principals their namespace; database and record principals their exact namespace/database; anonymous callers remain governed by the endpoint's PERMISSIONS.

• Versions 3.2.0 and later are not affected by this issue.

Workarounds

Users unable to patch should consider the following workarounds:

• Disable the custom API HTTP route via capabilities where it is not required.
• Treat separate deployments, not namespace/database boundaries, as the tenant isolation boundary on shared instances.
• Prefer a PERMISSIONS WHERE clause that checks the authenticated identity over PERMISSIONS FULL (reduces exposure but does not restore the boundary).

Resources

• SurrealQL Documentation — DEFINE API
• SurrealDB Documentation — Capabilities
• fix(core/api): reject cross-tenant custom API access (included in SurrealDB 3.2.0)

Acknowledgements

SurrealDB thanks sondt99 for reporting this issue.

An authenticated user scoped to one namespace/database could invoke a custom API (DEFINE API) belonging to a different namespace/database, reaching another tenant's endpoint.

The route /api/{namespace}/{database}/{endpoint} took the namespace and database from the URL and applied them to the caller's session before the endpoint was looked up or run, without checking that the caller's authenticated scope covered them. Because a custom API handler runs with permissions disabled (definer's rights), the endpoint's own PERMISSIONS clause was the only gate — open to everyone for a PERMISSIONS FULL endpoint. The api::invoke() function was affected the same way, resolving against the session's selected namespace/database (settable via the surreal-ns / surreal-db headers or USE).

Impact

What an attacker can do:

• With valid credentials for any one namespace/database (a VIEWER is enough), invoke a custom API in another namespace/database by naming the victim scope in the URL.
• Read data that endpoint returns — including from PERMISSIONS NONE tables, since the handler runs with permissions disabled — or trigger any writes and side effects it performs.

What it can't do:

• Reach a scope without valid credentials for some namespace/database on the instance; this is not an unauthenticated bypass.
• Affect single-tenant deployments, or any deployment where callers already hold instance-wide (root) scope.

Patches

The namespace/database is now validated against the caller's authenticated level — which the request cannot change — before the endpoint is resolved or run. A target scope outside that level is rejected with 403 Forbidden, both at the HTTP entry point and at the dispatch step shared with api::invoke(). Root reaches any scope; namespace principals their namespace; database and record principals their exact namespace/database; anonymous callers remain governed by the endpoint's PERMISSIONS.

• Versions 3.2.0 and later are not affected by this issue.

Workarounds

Users unable to patch should consider the following workarounds:

• Disable the custom API HTTP route via capabilities where it is not required.
• Treat separate deployments, not namespace/database boundaries, as the tenant isolation boundary on shared instances.
• Prefer a PERMISSIONS WHERE clause that checks the authenticated identity over PERMISSIONS FULL (reduces exposure but does not restore the boundary).

Resources

• SurrealQL Documentation — DEFINE API
• SurrealDB Documentation — Capabilities
• fix(core/api): reject cross-tenant custom API access (included in SurrealDB 3.2.0)

Acknowledgements

SurrealDB thanks sondt99 for reporting this issue.

An authenticated user scoped to one namespace/database could invoke a custom API (DEFINE API) belonging to a different namespace/database, reaching another tenant's endpoint.

The route /api/{namespace}/{database}/{endpoint} took the namespace and database from the URL and applied them to the caller's session before the endpoint was looked up or run, without checking that the caller's authenticated scope covered them. Because a custom API handler runs with permissions disabled (definer's rights), the endpoint's own PERMISSIONS clause was the only gate — open to everyone for a PERMISSIONS FULL endpoint. The api::invoke() function was affected the same way, resolving against the session's selected namespace/database (settable via the surreal-ns / surreal-db headers or USE).

Impact

What an attacker can do:

• With valid credentials for any one namespace/database (a VIEWER is enough), invoke a custom API in another namespace/database by naming the victim scope in the URL.
• Read data that endpoint returns — including from PERMISSIONS NONE tables, since the handler runs with permissions disabled — or trigger any writes and side effects it performs.

What it can't do:

• Reach a scope without valid credentials for some namespace/database on the instance; this is not an unauthenticated bypass.
• Affect single-tenant deployments, or any deployment where callers already hold instance-wide (root) scope.

Patches

The namespace/database is now validated against the caller's authenticated level — which the request cannot change — before the endpoint is resolved or run. A target scope outside that level is rejected with 403 Forbidden, both at the HTTP entry point and at the dispatch step shared with api::invoke(). Root reaches any scope; namespace principals their namespace; database and record principals their exact namespace/database; anonymous callers remain governed by the endpoint's PERMISSIONS.

• Versions 3.2.0 and later are not affected by this issue.

Workarounds

Users unable to patch should consider the following workarounds:

• Disable the custom API HTTP route via capabilities where it is not required.
• Treat separate deployments, not namespace/database boundaries, as the tenant isolation boundary on shared instances.
• Prefer a PERMISSIONS WHERE clause that checks the authenticated identity over PERMISSIONS FULL (reduces exposure but does not restore the boundary).

Resources

• SurrealQL Documentation — DEFINE API
• SurrealDB Documentation — Capabilities
• fix(core/api): reject cross-tenant custom API access (included in SurrealDB 3.2.0)

Acknowledgements

SurrealDB thanks sondt99 for reporting this issue.

An authenticated user scoped to one namespace/database could invoke a custom API (DEFINE API) belonging to a different namespace/database, reaching another tenant's endpoint.

The route /api/{namespace}/{database}/{endpoint} took the namespace and database from the URL and applied them to the caller's session before the endpoint was looked up or run, without checking that the caller's authenticated scope covered them. Because a custom API handler runs with permissions disabled (definer's rights), the endpoint's own PERMISSIONS clause was the only gate — open to everyone for a PERMISSIONS FULL endpoint. The api::invoke() function was affected the same way, resolving against the session's selected namespace/database (settable via the surreal-ns / surreal-db headers or USE).

Impact

What an attacker can do:

• With valid credentials for any one namespace/database (a VIEWER is enough), invoke a custom API in another namespace/database by naming the victim scope in the URL.
• Read data that endpoint returns — including from PERMISSIONS NONE tables, since the handler runs with permissions disabled — or trigger any writes and side effects it performs.

What it can't do:

• Reach a scope without valid credentials for some namespace/database on the instance; this is not an unauthenticated bypass.
• Affect single-tenant deployments, or any deployment where callers already hold instance-wide (root) scope.

Patches

The namespace/database is now validated against the caller's authenticated level — which the request cannot change — before the endpoint is resolved or run. A target scope outside that level is rejected with 403 Forbidden, both at the HTTP entry point and at the dispatch step shared with api::invoke(). Root reaches any scope; namespace principals their namespace; database and record principals their exact namespace/database; anonymous callers remain governed by the endpoint's PERMISSIONS.

• Versions 3.2.0 and later are not affected by this issue.

Workarounds

Users unable to patch should consider the following workarounds:

• Disable the custom API HTTP route via capabilities where it is not required.
• Treat separate deployments, not namespace/database boundaries, as the tenant isolation boundary on shared instances.
• Prefer a PERMISSIONS WHERE clause that checks the authenticated identity over PERMISSIONS FULL (reduces exposure but does not restore the boundary).

Resources

• SurrealQL Documentation — DEFINE API
• SurrealDB Documentation — Capabilities
• fix(core/api): reject cross-tenant custom API access (included in SurrealDB 3.2.0)

Acknowledgements

SurrealDB thanks sondt99 for reporting this issue.

An authenticated user could crash a SurrealDB server with a single query containing a long chain of operators.

Such a query — for example RETURN 1 + 1 + 1 + ... with tens of thousands of terms — is parsed into an expression tree one level deep per operator. Because the chain is flat and the pratt parser appends to it iteratively, the configured query- and object-recursion limits never fire, so the tree grows unbounded with the length of the query.

The root cause: the over-deep tree is later walked recursively, one call per node, when it is dropped, formatted, or lowered for execution — overflowing the thread stack and aborting the process.

Impact

An authenticated user with query-execution privileges can crash a SurrealDB server with a single query containing a long chain of operators. The whole process aborts, denying service to every namespace and database on that instance until it is restarted. The crash occurs during query processing, before any data is read or written (availability only).

Patches

A patch introduces a dedicated expression-depth budget — expr_recursion_limit, sourced from max_expression_parsing_depth (default 128, configurable via SURREAL_MAX_EXPRESSION_PARSING_DEPTH). It is charged once per pratt-parser level and once per operator appended to the spine, so an over-deep operator chain is rejected with a syntax error instead of building a tree that overflows the stack downstream. Paths that re-parse already-validated stored data are exempted, so existing databases with deep stored expressions still load.

• Versions 3.1.5 and later are not affected by this issue.

Workarounds

Users unable to patch should consider the following workarounds:

• Restrict the ability of untrusted users to execute arbitrary queries via the --deny-arbitrary-query capability flag for the affected user classes (guest, record, or system).
• Restrict untrusted access to the WebSocket /rpc endpoint, which accepts larger request bodies than the HTTP /sql endpoint. The /sql endpoint's 1 MiB body limit lowers the achievable operator depth but does not by itself guarantee the stack cannot be exhausted.
• Run SurrealDB under an orchestrator or process manager that restarts it automatically on exit (e.g. Kubernetes, systemd Restart=on-failure, or a Docker restart policy), so the server recovers immediately after a crash. This limits downtime from a successful attack but does not prevent the crash.

References

• SurrealQL Documentation — Operators
• fix(syn): bound expression operator-tree depth to prevent stack-overflow DoS

A record user could read field values hidden from them by field-level SELECT permissions by reaching the records through a graph-edge (->) or back-reference (<~) traversal instead of a direct SELECT.

When a table was readable at the table level but carried a field hidden by a field-level permission (DEFINE FIELD secret ON knows PERMISSIONS FOR select NONE), a direct SELECT * FROM knows hid secret — but reaching the same records through a traversal that yields full objects — person:bob->(SELECT * FROM knows), person:bob<~(SELECT * FROM comment), or a projected target vertex ->knows->(SELECT * FROM person) — returned it intact.

The root cause: the shared resolve_record_batch helper used by GraphEdgeScan (FullEdge) and ReferenceScan (FullRecord) enforced only the table-level SELECT permission and pushed raw record data, never running the field-level filtering (build_field_state / filter_fields_by_permission) that ordinary table scans and fetch_record apply.

Impact

A record user can read the values of fields hidden by field-level SELECT permissions, on tables they already hold table-level SELECT on, by materialising the records through a graph-edge, back-reference, or target-vertex traversal — recovering the values directly, for every record the traversal returns.

The disclosure is confined to the field-permission layer: it grants no unauthorised cross-table, cross-record, or cross-namespace/database access. The table's own SELECT permission — including any row-level WHERE predicate — is still enforced, so the caller only reaches records they were already entitled to read; only the per-field SELECT filtering within those records is skipped. Root and record-owner sessions are unaffected, and data cannot be modified (confidentiality only).

Table-level enforcement on these traversals landed in 3.1.0 (the fix for GHSA-vjjx-rfw4-rmfc); releases before 3.1.0 additionally exposed whole records on tables the caller could not read, and are covered by that advisory.

Patches

resolve_record_batch (the shared helper that materialises full records for graph and reference traversals) now applies field-level SELECT permissions and read-time COMPUTED fields to each record, matching the regular table-scan and fetch_record paths.

Versions 3.1.5 and later are not affected.

Workarounds

• Force the unaffected legacy executor with --planner-strategy compute-only (env SURREAL_PLANNER_STRATEGY).
• Do not rely on field-level SELECT permissions to hide values on tables reachable as a graph edge, reference target, or traversal vertex; restrict at the table level instead.
• Use namespace / database isolation as the primary boundary where feasible.

Resources

• SurrealQL Documentation — DEFINE FIELD
• SurrealQL Documentation — DEFINE TABLE … PERMISSIONS
• SurrealQL Documentation — Graph relationships
• fix(exec): apply field-level SELECT permissions + computed fields when graph/reference traversals materialize full records

A field can be hidden from a user with a field-level SELECT permission (DEFINE FIELD code ON secret PERMISSIONS FOR select WHERE owner = $auth.id). When that field is indexed, a record user who cannot read it could still recover the relative ordering of its values across every record by issuing ORDER BY <field>: the field came back null as intended, but the rows were returned in the hidden values' true sorted order.

To satisfy the sort, the planner selects the field's index and walks it in value order; the field-level permission is applied later, when the row is projected, so the value is nulled but the row order already encodes it. The guard that withholds restricted fields from the WHERE path was never applied to ORDER BY.

Impact

What an attacker can do:

• As a record (scope) user with table SELECT, learn the relative ordering of a field hidden by a field-level SELECT permission, across other users' records, by ordering on it when an index covers the field — the value returns null, but the rows come back in the hidden values' order.
• With rows they control in the same table, use that ordering to narrow the hidden values toward exact ones.

What it can't do:

• Read the field value directly — only its relative ordering leaks; the projected value is correctly redacted.
• Cross table, record, or namespace/database boundaries — the table's SELECT permission and any row-level WHERE are still enforced, so only records the caller may already read are ordered.
• Leak anything when the restricted field is not indexed, affect root or record-owner sessions, or modify data (confidentiality only).

Patches

The query planner now applies the field-permission guard to the ORDER BY clause as well as the WHERE clause. When an ordered field is hidden from the caller by a field-level SELECT permission, the index sort pushdown is withheld and the rows are sorted after redaction instead, so the row order no longer reflects the hidden values. The dynamic-scan fallback is closed the same way, and a regression test was added.

The fix is included in SurrealDB 3.1.5.

Workarounds

Users unable to upgrade are advised to consider the following:

• Force the legacy executor with SURREAL_PLANNER_STRATEGY=compute-only; the sort then runs after redaction, so no ordering leaks.
• Do not place an index on a field whose values are hidden by a field-level SELECT permission — without the index the leak does not occur.
• Do not rely on field-level SELECT permissions to hide values on indexed fields from record users; restrict at the table level instead.
• Use namespace / database isolation as the primary trust boundary where feasible.

References

• SurrealQL Documentation — DEFINE FIELD
• SurrealQL Documentation — DEFINE INDEX
• SurrealQL Documentation — DEFINE TABLE … PERMISSIONS
• Related advisory (same class, indexed COUNT variant): GHSA-c8jx-96c9-8xrp
• fix(planner): prevent ORDER BY value-ordering oracle on restricted SELECT fields
• fix(planner): close ORDER BY value-ordering oracle on the DynamicScan fallback

Acknowledgements

Thanks to George Chen (@geo-chen) for finding and reporting this issue.

SurrealDB's full-text search lets you define a text analyzer whose mapper filter loads a term-mapping file from disk (DEFINE ANALYZER ... FILTERS mapper('<path>')). A database user with the EDITOR or OWNER role could point that filter at any file the SurrealDB process can read and have its content returned in the query's error message.

File access is meant to be restricted by the SURREAL_FILE_ALLOWLIST setting, but an empty allowlist applied no restriction at all — and empty is the default.

Impact

The file is read with the privileges of the SurrealDB process, so a database EDITOR or OWNER user can disclose the contents of any file the process can access. Only the first line of the file is returned, except for files with no newlines.

However recovering the process's command line and environment could expose startup root credentials (--user / --pass) and secret environment variables, escalating a single-database role toward full control of the instance.

The read on the underlying filesystem is bounded by what the SurrealDB process can reach — any file readable by the OS user it runs as — so the impact scales with how the process is run and what is mounted into it.

Patches

A patch has been included in SurrealDB 3.1.5.

File access is now secure by default. check_is_path_allowed denies every path when no SURREAL_FILE_ALLOWLIST is configured, so the mapper filter cannot open any file unless the operator has explicitly allowed its directory. Analyzer parse errors no longer include the contents of the mapped file, only the line number.

Workarounds

Users unable to upgrade are advised to consider the following:

• Set SURREAL_FILE_ALLOWLIST to a directory that contains only the intended mapping files; this confines the mapper filter to that path. On affected versions the allowlist must be non-empty to have any effect.
• Grant the EDITOR and OWNER database roles only to trusted principals.
• Avoid supplying secrets — including the root credentials — on the command line or through environment variables; prefer mounted files with least-privilege permissions.

References

• SurrealQL Documentation — DEFINE ANALYZER
• SurrealDB Documentation — Capabilities
• Related earlier advisory: GHSA-2cvj-g5r5-jrrg local file read of 2-column TSV files via analyzers
• https://github.com/surrealdb/surrealdb/pull/5600
• fix(iam): deny filesystem access by default and stop leaking file content in analyzer errors

Acknowledgements

Thanks to Jan Kahmen (@kah-ja) for finding and reporting this issue.

SurrealDB fetches the JWKS document for a JWT or record access method using a bare reqwest client that follows HTTP redirects by default. The network capability check in core/src/iam/jwks.rs (check_capabilities_url) is applied only to the originally configured URL; redirect targets are not re-validated. An --allow-net-permitted JWKS host that returns a 3xx Location can therefore redirect the request to an address the allowlist was meant to block, resulting in a server-side request forgery (SSRF). The protected HttpClient used by http::* functions re-checks every redirect hop and was hardened in 3.1.0, but the JWKS fetcher uses its own client and was not covered.

Impact

What an attacker can do:

• With the Owner role at database level or above (the minimum required to run DEFINE ACCESS ... TYPE JWT URL or TYPE RECORD ... WITH JWT URL), point an access method at an allowlisted host they control and redirect the server's GET to an otherwise-blocked target — cloud metadata, loopback, internal services — bypassing --allow-net/--deny-net.
• Infer the existence and liveness of internal hosts and ports from response-timing differences (bounded by the 1-second fetch timeout).

What it can't do:

• Read the response: the fetch is blind — the body is only parsed as a JWKS, and a non-JWKS response surfaces as an opaque InvalidAuth error. Nothing is returned to the caller.
• Modify data or affect availability (a single GET request).

Patches

The JWKS fetcher now applies a redirect policy that re-validates every redirect target against the configured network capabilities (mirroring check_capabilities_url) and caps redirects at max_http_redirects.

• Versions prior to 3.1.5 are vulnerable.

Workarounds

• Restrict the Owner role to trusted operators.
• Enforce egress filtering at the network layer (block link-local 169.254.0.0/16 and internal ranges) so redirect targets are unreachable regardless of in-process checks.
• Configure access methods to use only trusted JWKS hosts that do not redirect, or use locally defined keys instead of a remote JWKS.

References

• SurrealDB Documentation — Capabilities
• SurrealQL Documentation — DEFINE ACCESS
• fix(iam): prevent SSRF in JWKS fetch by re-validating redirect targets

An authenticated user scoped to one namespace/database could invoke a custom API (DEFINE API) belonging to a different namespace/database, reaching another tenant's endpoint.

The route /api/{namespace}/{database}/{endpoint} took the namespace and database from the URL and applied them to the caller's session before the endpoint was looked up or run, without checking that the caller's authenticated scope covered them. Because a custom API handler runs with permissions disabled (definer's rights), the endpoint's own PERMISSIONS clause was the only gate — open to everyone for a PERMISSIONS FULL endpoint. The api::invoke() function was affected the same way, resolving against the session's selected namespace/database (settable via the surreal-ns / surreal-db headers or USE).

Impact

What an attacker can do:

• With valid credentials for any one namespace/database (a VIEWER is enough), invoke a custom API in another namespace/database by naming the victim scope in the URL.
• Read data that endpoint returns — including from PERMISSIONS NONE tables, since the handler runs with permissions disabled — or trigger any writes and side effects it performs.

What it can't do:

• Reach a scope without valid credentials for some namespace/database on the instance; this is not an unauthenticated bypass.
• Affect single-tenant deployments, or any deployment where callers already hold instance-wide (root) scope.

Patches

The namespace/database is now validated against the caller's authenticated level — which the request cannot change — before the endpoint is resolved or run. A target scope outside that level is rejected with 403 Forbidden, both at the HTTP entry point and at the dispatch step shared with api::invoke(). Root reaches any scope; namespace principals their namespace; database and record principals their exact namespace/database; anonymous callers remain governed by the endpoint's PERMISSIONS.

• Versions 3.2.0 and later are not affected by this issue.

Workarounds

Users unable to patch should consider the following workarounds:

• Disable the custom API HTTP route via capabilities where it is not required.
• Treat separate deployments, not namespace/database boundaries, as the tenant isolation boundary on shared instances.
• Prefer a PERMISSIONS WHERE clause that checks the authenticated identity over PERMISSIONS FULL (reduces exposure but does not restore the boundary).

Resources

• SurrealQL Documentation — DEFINE API
• SurrealDB Documentation — Capabilities
• fix(core/api): reject cross-tenant custom API access (included in SurrealDB 3.2.0)

Acknowledgements

SurrealDB thanks sondt99 for reporting this issue.

A SELECT permission defined on an array element (DEFINE FIELD field.* … PERMISSIONS FOR select …) is not enforced correctly for RECORD users. Instead of hiding the denied elements, the query leaks a subset of them: a deny-all returns the odd-indexed elements, and a per-element predicate keeps and drops the wrong ones.

The filter removed each denied element by index while walking the array forwards. Because removing an element shifts every later index down, each cut invalidated the indices still pending in the loop, leaving denied elements behind. Field-level permissions are enforced correctly; only the element (field.*) level is affected, and only for record users — root and record-owner sessions are not.

Impact

What an attacker can do:

• As a record (scope) user, read array elements that an element-level (field.*) SELECT permission should hide, on any table they can already SELECT.
• Recover denied elements through both a deny-all and a WHERE predicate — the wrong elements are selected either way.

What it can't do:

• Bypass field-level SELECT permissions, which are evaluated correctly.
• Affect root or record-owner sessions, or cross namespace/database isolation.
• Modify data, escalate privileges, or affect availability (confidentiality only).

Patches

The three permission-filtering paths (doc/reduce.rs, doc/output.rs, exec/operators/scan/pipeline.rs) now remove denied elements in reverse index order, so removing one element no longer shifts the elements still to be checked. Regression tests reproducing the issue were added.

The fix is included in SurrealDB 3.1.4.

Workarounds

• Do not rely on element-level (field.*) permissions to hide data from record users; use field-level permissions, which are enforced correctly.
• Restrict record users from selecting tables whose schema uses element-level permissions.

Resources

• DEFINE FIELD
• USERS
• DEFINE TABLE … PERMISSIONS
• fix(sec): stop array element-level SELECT permissions leaking elements (commit 8f89b260b)

An authenticated user could crash a SurrealDB server with a single query containing a long chain of operators.

Such a query — for example RETURN 1 + 1 + 1 + ... with tens of thousands of terms — is parsed into an expression tree one level deep per operator. Because the chain is flat and the pratt parser appends to it iteratively, the configured query- and object-recursion limits never fire, so the tree grows unbounded with the length of the query.

The root cause: the over-deep tree is later walked recursively, one call per node, when it is dropped, formatted, or lowered for execution — overflowing the thread stack and aborting the process.

Impact

An authenticated user with query-execution privileges can crash a SurrealDB server with a single query containing a long chain of operators. The whole process aborts, denying service to every namespace and database on that instance until it is restarted. The crash occurs during query processing, before any data is read or written (availability only).

Patches

A patch introduces a dedicated expression-depth budget — expr_recursion_limit, sourced from max_expression_parsing_depth (default 128, configurable via SURREAL_MAX_EXPRESSION_PARSING_DEPTH). It is charged once per pratt-parser level and once per operator appended to the spine, so an over-deep operator chain is rejected with a syntax error instead of building a tree that overflows the stack downstream. Paths that re-parse already-validated stored data are exempted, so existing databases with deep stored expressions still load.

• Versions 3.1.5 and later are not affected by this issue.

Workarounds

Users unable to patch should consider the following workarounds:

• Restrict the ability of untrusted users to execute arbitrary queries via the --deny-arbitrary-query capability flag for the affected user classes (guest, record, or system).
• Restrict untrusted access to the WebSocket /rpc endpoint, which accepts larger request bodies than the HTTP /sql endpoint. The /sql endpoint's 1 MiB body limit lowers the achievable operator depth but does not by itself guarantee the stack cannot be exhausted.
• Run SurrealDB under an orchestrator or process manager that restarts it automatically on exit (e.g. Kubernetes, systemd Restart=on-failure, or a Docker restart policy), so the server recovers immediately after a crash. This limits downtime from a successful attack but does not prevent the crash.

References

• SurrealQL Documentation — Operators
• fix(syn): bound expression operator-tree depth to prevent stack-overflow DoS

A record user could read field values hidden from them by field-level SELECT permissions by reaching the records through a graph-edge (->) or back-reference (<~) traversal instead of a direct SELECT.

When a table was readable at the table level but carried a field hidden by a field-level permission (DEFINE FIELD secret ON knows PERMISSIONS FOR select NONE), a direct SELECT * FROM knows hid secret — but reaching the same records through a traversal that yields full objects — person:bob->(SELECT * FROM knows), person:bob<~(SELECT * FROM comment), or a projected target vertex ->knows->(SELECT * FROM person) — returned it intact.

The root cause: the shared resolve_record_batch helper used by GraphEdgeScan (FullEdge) and ReferenceScan (FullRecord) enforced only the table-level SELECT permission and pushed raw record data, never running the field-level filtering (build_field_state / filter_fields_by_permission) that ordinary table scans and fetch_record apply.

Impact

A record user can read the values of fields hidden by field-level SELECT permissions, on tables they already hold table-level SELECT on, by materialising the records through a graph-edge, back-reference, or target-vertex traversal — recovering the values directly, for every record the traversal returns.

The disclosure is confined to the field-permission layer: it grants no unauthorised cross-table, cross-record, or cross-namespace/database access. The table's own SELECT permission — including any row-level WHERE predicate — is still enforced, so the caller only reaches records they were already entitled to read; only the per-field SELECT filtering within those records is skipped. Root and record-owner sessions are unaffected, and data cannot be modified (confidentiality only).

Table-level enforcement on these traversals landed in 3.1.0 (the fix for GHSA-vjjx-rfw4-rmfc); releases before 3.1.0 additionally exposed whole records on tables the caller could not read, and are covered by that advisory.

Patches

resolve_record_batch (the shared helper that materialises full records for graph and reference traversals) now applies field-level SELECT permissions and read-time COMPUTED fields to each record, matching the regular table-scan and fetch_record paths.

Versions 3.1.5 and later are not affected.

Workarounds

• Force the unaffected legacy executor with --planner-strategy compute-only (env SURREAL_PLANNER_STRATEGY).
• Do not rely on field-level SELECT permissions to hide values on tables reachable as a graph edge, reference target, or traversal vertex; restrict at the table level instead.
• Use namespace / database isolation as the primary boundary where feasible.

Resources

• SurrealQL Documentation — DEFINE FIELD
• SurrealQL Documentation — DEFINE TABLE … PERMISSIONS
• SurrealQL Documentation — Graph relationships
• fix(exec): apply field-level SELECT permissions + computed fields when graph/reference traversals materialize full records

A field can be hidden from a user with a field-level SELECT permission (DEFINE FIELD code ON secret PERMISSIONS FOR select WHERE owner = $auth.id). When that field is indexed, a record user who cannot read it could still recover the relative ordering of its values across every record by issuing ORDER BY <field>: the field came back null as intended, but the rows were returned in the hidden values' true sorted order.

To satisfy the sort, the planner selects the field's index and walks it in value order; the field-level permission is applied later, when the row is projected, so the value is nulled but the row order already encodes it. The guard that withholds restricted fields from the WHERE path was never applied to ORDER BY.

Impact

What an attacker can do:

• As a record (scope) user with table SELECT, learn the relative ordering of a field hidden by a field-level SELECT permission, across other users' records, by ordering on it when an index covers the field — the value returns null, but the rows come back in the hidden values' order.
• With rows they control in the same table, use that ordering to narrow the hidden values toward exact ones.

What it can't do:

• Read the field value directly — only its relative ordering leaks; the projected value is correctly redacted.
• Cross table, record, or namespace/database boundaries — the table's SELECT permission and any row-level WHERE are still enforced, so only records the caller may already read are ordered.
• Leak anything when the restricted field is not indexed, affect root or record-owner sessions, or modify data (confidentiality only).

Patches

The query planner now applies the field-permission guard to the ORDER BY clause as well as the WHERE clause. When an ordered field is hidden from the caller by a field-level SELECT permission, the index sort pushdown is withheld and the rows are sorted after redaction instead, so the row order no longer reflects the hidden values. The dynamic-scan fallback is closed the same way, and a regression test was added.

The fix is included in SurrealDB 3.1.5.

Workarounds

Users unable to upgrade are advised to consider the following:

• Force the legacy executor with SURREAL_PLANNER_STRATEGY=compute-only; the sort then runs after redaction, so no ordering leaks.
• Do not place an index on a field whose values are hidden by a field-level SELECT permission — without the index the leak does not occur.
• Do not rely on field-level SELECT permissions to hide values on indexed fields from record users; restrict at the table level instead.
• Use namespace / database isolation as the primary trust boundary where feasible.

References

• SurrealQL Documentation — DEFINE FIELD
• SurrealQL Documentation — DEFINE INDEX
• SurrealQL Documentation — DEFINE TABLE … PERMISSIONS
• Related advisory (same class, indexed COUNT variant): GHSA-c8jx-96c9-8xrp
• fix(planner): prevent ORDER BY value-ordering oracle on restricted SELECT fields
• fix(planner): close ORDER BY value-ordering oracle on the DynamicScan fallback

Acknowledgements

Thanks to George Chen (@geo-chen) for finding and reporting this issue.

SurrealDB's full-text search lets you define a text analyzer whose mapper filter loads a term-mapping file from disk (DEFINE ANALYZER ... FILTERS mapper('<path>')). A database user with the EDITOR or OWNER role could point that filter at any file the SurrealDB process can read and have its content returned in the query's error message.

File access is meant to be restricted by the SURREAL_FILE_ALLOWLIST setting, but an empty allowlist applied no restriction at all — and empty is the default.

Impact

The file is read with the privileges of the SurrealDB process, so a database EDITOR or OWNER user can disclose the contents of any file the process can access. Only the first line of the file is returned, except for files with no newlines.

However recovering the process's command line and environment could expose startup root credentials (--user / --pass) and secret environment variables, escalating a single-database role toward full control of the instance.

The read on the underlying filesystem is bounded by what the SurrealDB process can reach — any file readable by the OS user it runs as — so the impact scales with how the process is run and what is mounted into it.

Patches

A patch has been included in SurrealDB 3.1.5.

File access is now secure by default. check_is_path_allowed denies every path when no SURREAL_FILE_ALLOWLIST is configured, so the mapper filter cannot open any file unless the operator has explicitly allowed its directory. Analyzer parse errors no longer include the contents of the mapped file, only the line number.

Workarounds

Users unable to upgrade are advised to consider the following:

• Set SURREAL_FILE_ALLOWLIST to a directory that contains only the intended mapping files; this confines the mapper filter to that path. On affected versions the allowlist must be non-empty to have any effect.
• Grant the EDITOR and OWNER database roles only to trusted principals.
• Avoid supplying secrets — including the root credentials — on the command line or through environment variables; prefer mounted files with least-privilege permissions.

References

• SurrealQL Documentation — DEFINE ANALYZER
• SurrealDB Documentation — Capabilities
• Related earlier advisory: GHSA-2cvj-g5r5-jrrg local file read of 2-column TSV files via analyzers
• https://github.com/surrealdb/surrealdb/pull/5600
• fix(iam): deny filesystem access by default and stop leaking file content in analyzer errors

Acknowledgements

Thanks to Jan Kahmen (@kah-ja) for finding and reporting this issue.

SurrealDB fetches the JWKS document for a JWT or record access method using a bare reqwest client that follows HTTP redirects by default. The network capability check in core/src/iam/jwks.rs (check_capabilities_url) is applied only to the originally configured URL; redirect targets are not re-validated. An --allow-net-permitted JWKS host that returns a 3xx Location can therefore redirect the request to an address the allowlist was meant to block, resulting in a server-side request forgery (SSRF). The protected HttpClient used by http::* functions re-checks every redirect hop and was hardened in 3.1.0, but the JWKS fetcher uses its own client and was not covered.

Impact

What an attacker can do:

• With the Owner role at database level or above (the minimum required to run DEFINE ACCESS ... TYPE JWT URL or TYPE RECORD ... WITH JWT URL), point an access method at an allowlisted host they control and redirect the server's GET to an otherwise-blocked target — cloud metadata, loopback, internal services — bypassing --allow-net/--deny-net.
• Infer the existence and liveness of internal hosts and ports from response-timing differences (bounded by the 1-second fetch timeout).

What it can't do:

• Read the response: the fetch is blind — the body is only parsed as a JWKS, and a non-JWKS response surfaces as an opaque InvalidAuth error. Nothing is returned to the caller.
• Modify data or affect availability (a single GET request).

Patches

The JWKS fetcher now applies a redirect policy that re-validates every redirect target against the configured network capabilities (mirroring check_capabilities_url) and caps redirects at max_http_redirects.

• Versions prior to 3.1.5 are vulnerable.

Workarounds

• Restrict the Owner role to trusted operators.
• Enforce egress filtering at the network layer (block link-local 169.254.0.0/16 and internal ranges) so redirect targets are unreachable regardless of in-process checks.
• Configure access methods to use only trusted JWKS hosts that do not redirect, or use locally defined keys instead of a remote JWKS.

References

• SurrealDB Documentation — Capabilities
• SurrealQL Documentation — DEFINE ACCESS
• fix(iam): prevent SSRF in JWKS fetch by re-validating redirect targets

An authenticated user scoped to one namespace/database could invoke a custom API (DEFINE API) belonging to a different namespace/database, reaching another tenant's endpoint.

The route /api/{namespace}/{database}/{endpoint} took the namespace and database from the URL and applied them to the caller's session before the endpoint was looked up or run, without checking that the caller's authenticated scope covered them. Because a custom API handler runs with permissions disabled (definer's rights), the endpoint's own PERMISSIONS clause was the only gate — open to everyone for a PERMISSIONS FULL endpoint. The api::invoke() function was affected the same way, resolving against the session's selected namespace/database (settable via the surreal-ns / surreal-db headers or USE).

Impact

What an attacker can do:

• With valid credentials for any one namespace/database (a VIEWER is enough), invoke a custom API in another namespace/database by naming the victim scope in the URL.
• Read data that endpoint returns — including from PERMISSIONS NONE tables, since the handler runs with permissions disabled — or trigger any writes and side effects it performs.

What it can't do:

• Reach a scope without valid credentials for some namespace/database on the instance; this is not an unauthenticated bypass.
• Affect single-tenant deployments, or any deployment where callers already hold instance-wide (root) scope.

Patches

The namespace/database is now validated against the caller's authenticated level — which the request cannot change — before the endpoint is resolved or run. A target scope outside that level is rejected with 403 Forbidden, both at the HTTP entry point and at the dispatch step shared with api::invoke(). Root reaches any scope; namespace principals their namespace; database and record principals their exact namespace/database; anonymous callers remain governed by the endpoint's PERMISSIONS.

• Versions 3.2.0 and later are not affected by this issue.

Workarounds

Users unable to patch should consider the following workarounds:

• Disable the custom API HTTP route via capabilities where it is not required.
• Treat separate deployments, not namespace/database boundaries, as the tenant isolation boundary on shared instances.
• Prefer a PERMISSIONS WHERE clause that checks the authenticated identity over PERMISSIONS FULL (reduces exposure but does not restore the boundary).

Resources

• SurrealQL Documentation — DEFINE API
• SurrealDB Documentation — Capabilities
• fix(core/api): reject cross-tenant custom API access (included in SurrealDB 3.2.0)

Acknowledgements

SurrealDB thanks sondt99 for reporting this issue.

A SELECT permission defined on an array element (DEFINE FIELD field.* … PERMISSIONS FOR select …) is not enforced correctly for RECORD users. Instead of hiding the denied elements, the query leaks a subset of them: a deny-all returns the odd-indexed elements, and a per-element predicate keeps and drops the wrong ones.

The filter removed each denied element by index while walking the array forwards. Because removing an element shifts every later index down, each cut invalidated the indices still pending in the loop, leaving denied elements behind. Field-level permissions are enforced correctly; only the element (field.*) level is affected, and only for record users — root and record-owner sessions are not.

Impact

What an attacker can do:

• As a record (scope) user, read array elements that an element-level (field.*) SELECT permission should hide, on any table they can already SELECT.
• Recover denied elements through both a deny-all and a WHERE predicate — the wrong elements are selected either way.

What it can't do:

• Bypass field-level SELECT permissions, which are evaluated correctly.
• Affect root or record-owner sessions, or cross namespace/database isolation.
• Modify data, escalate privileges, or affect availability (confidentiality only).

Patches

The three permission-filtering paths (doc/reduce.rs, doc/output.rs, exec/operators/scan/pipeline.rs) now remove denied elements in reverse index order, so removing one element no longer shifts the elements still to be checked. Regression tests reproducing the issue were added.

The fix is included in SurrealDB 3.1.4.

Workarounds

• Do not rely on element-level (field.*) permissions to hide data from record users; use field-level permissions, which are enforced correctly.
• Restrict record users from selecting tables whose schema uses element-level permissions.

Resources

• DEFINE FIELD
• USERS
• DEFINE TABLE … PERMISSIONS
• fix(sec): stop array element-level SELECT permissions leaking elements (commit 8f89b260b)

An authenticated user could crash a SurrealDB server with a single query containing a long chain of operators.

Such a query — for example RETURN 1 + 1 + 1 + ... with tens of thousands of terms — is parsed into an expression tree one level deep per operator. Because the chain is flat and the pratt parser appends to it iteratively, the configured query- and object-recursion limits never fire, so the tree grows unbounded with the length of the query.

The root cause: the over-deep tree is later walked recursively, one call per node, when it is dropped, formatted, or lowered for execution — overflowing the thread stack and aborting the process.

Impact

An authenticated user with query-execution privileges can crash a SurrealDB server with a single query containing a long chain of operators. The whole process aborts, denying service to every namespace and database on that instance until it is restarted. The crash occurs during query processing, before any data is read or written (availability only).

Patches

A patch introduces a dedicated expression-depth budget — expr_recursion_limit, sourced from max_expression_parsing_depth (default 128, configurable via SURREAL_MAX_EXPRESSION_PARSING_DEPTH). It is charged once per pratt-parser level and once per operator appended to the spine, so an over-deep operator chain is rejected with a syntax error instead of building a tree that overflows the stack downstream. Paths that re-parse already-validated stored data are exempted, so existing databases with deep stored expressions still load.

• Versions 3.1.5 and later are not affected by this issue.

Workarounds

Users unable to patch should consider the following workarounds:

• Restrict the ability of untrusted users to execute arbitrary queries via the --deny-arbitrary-query capability flag for the affected user classes (guest, record, or system).
• Restrict untrusted access to the WebSocket /rpc endpoint, which accepts larger request bodies than the HTTP /sql endpoint. The /sql endpoint's 1 MiB body limit lowers the achievable operator depth but does not by itself guarantee the stack cannot be exhausted.
• Run SurrealDB under an orchestrator or process manager that restarts it automatically on exit (e.g. Kubernetes, systemd Restart=on-failure, or a Docker restart policy), so the server recovers immediately after a crash. This limits downtime from a successful attack but does not prevent the crash.

References

• SurrealQL Documentation — Operators
• fix(syn): bound expression operator-tree depth to prevent stack-overflow DoS

A record user could read field values hidden from them by field-level SELECT permissions by reaching the records through a graph-edge (->) or back-reference (<~) traversal instead of a direct SELECT.

When a table was readable at the table level but carried a field hidden by a field-level permission (DEFINE FIELD secret ON knows PERMISSIONS FOR select NONE), a direct SELECT * FROM knows hid secret — but reaching the same records through a traversal that yields full objects — person:bob->(SELECT * FROM knows), person:bob<~(SELECT * FROM comment), or a projected target vertex ->knows->(SELECT * FROM person) — returned it intact.

The root cause: the shared resolve_record_batch helper used by GraphEdgeScan (FullEdge) and ReferenceScan (FullRecord) enforced only the table-level SELECT permission and pushed raw record data, never running the field-level filtering (build_field_state / filter_fields_by_permission) that ordinary table scans and fetch_record apply.

Impact

A record user can read the values of fields hidden by field-level SELECT permissions, on tables they already hold table-level SELECT on, by materialising the records through a graph-edge, back-reference, or target-vertex traversal — recovering the values directly, for every record the traversal returns.

The disclosure is confined to the field-permission layer: it grants no unauthorised cross-table, cross-record, or cross-namespace/database access. The table's own SELECT permission — including any row-level WHERE predicate — is still enforced, so the caller only reaches records they were already entitled to read; only the per-field SELECT filtering within those records is skipped. Root and record-owner sessions are unaffected, and data cannot be modified (confidentiality only).

Table-level enforcement on these traversals landed in 3.1.0 (the fix for GHSA-vjjx-rfw4-rmfc); releases before 3.1.0 additionally exposed whole records on tables the caller could not read, and are covered by that advisory.

Patches

resolve_record_batch (the shared helper that materialises full records for graph and reference traversals) now applies field-level SELECT permissions and read-time COMPUTED fields to each record, matching the regular table-scan and fetch_record paths.

Versions 3.1.5 and later are not affected.

Workarounds

• Force the unaffected legacy executor with --planner-strategy compute-only (env SURREAL_PLANNER_STRATEGY).
• Do not rely on field-level SELECT permissions to hide values on tables reachable as a graph edge, reference target, or traversal vertex; restrict at the table level instead.
• Use namespace / database isolation as the primary boundary where feasible.

Resources

• SurrealQL Documentation — DEFINE FIELD
• SurrealQL Documentation — DEFINE TABLE … PERMISSIONS
• SurrealQL Documentation — Graph relationships
• fix(exec): apply field-level SELECT permissions + computed fields when graph/reference traversals materialize full records

A field can be hidden from a user with a field-level SELECT permission (DEFINE FIELD code ON secret PERMISSIONS FOR select WHERE owner = $auth.id). When that field is indexed, a record user who cannot read it could still recover the relative ordering of its values across every record by issuing ORDER BY <field>: the field came back null as intended, but the rows were returned in the hidden values' true sorted order.

To satisfy the sort, the planner selects the field's index and walks it in value order; the field-level permission is applied later, when the row is projected, so the value is nulled but the row order already encodes it. The guard that withholds restricted fields from the WHERE path was never applied to ORDER BY.

Impact

What an attacker can do:

• As a record (scope) user with table SELECT, learn the relative ordering of a field hidden by a field-level SELECT permission, across other users' records, by ordering on it when an index covers the field — the value returns null, but the rows come back in the hidden values' order.
• With rows they control in the same table, use that ordering to narrow the hidden values toward exact ones.

What it can't do:

• Read the field value directly — only its relative ordering leaks; the projected value is correctly redacted.
• Cross table, record, or namespace/database boundaries — the table's SELECT permission and any row-level WHERE are still enforced, so only records the caller may already read are ordered.
• Leak anything when the restricted field is not indexed, affect root or record-owner sessions, or modify data (confidentiality only).

Patches

The query planner now applies the field-permission guard to the ORDER BY clause as well as the WHERE clause. When an ordered field is hidden from the caller by a field-level SELECT permission, the index sort pushdown is withheld and the rows are sorted after redaction instead, so the row order no longer reflects the hidden values. The dynamic-scan fallback is closed the same way, and a regression test was added.

The fix is included in SurrealDB 3.1.5.

Workarounds

Users unable to upgrade are advised to consider the following:

• Force the legacy executor with SURREAL_PLANNER_STRATEGY=compute-only; the sort then runs after redaction, so no ordering leaks.
• Do not place an index on a field whose values are hidden by a field-level SELECT permission — without the index the leak does not occur.
• Do not rely on field-level SELECT permissions to hide values on indexed fields from record users; restrict at the table level instead.
• Use namespace / database isolation as the primary trust boundary where feasible.

References

• SurrealQL Documentation — DEFINE FIELD
• SurrealQL Documentation — DEFINE INDEX
• SurrealQL Documentation — DEFINE TABLE … PERMISSIONS
• Related advisory (same class, indexed COUNT variant): GHSA-c8jx-96c9-8xrp
• fix(planner): prevent ORDER BY value-ordering oracle on restricted SELECT fields
• fix(planner): close ORDER BY value-ordering oracle on the DynamicScan fallback

Acknowledgements

Thanks to George Chen (@geo-chen) for finding and reporting this issue.

SurrealDB's full-text search lets you define a text analyzer whose mapper filter loads a term-mapping file from disk (DEFINE ANALYZER ... FILTERS mapper('<path>')). A database user with the EDITOR or OWNER role could point that filter at any file the SurrealDB process can read and have its content returned in the query's error message.

File access is meant to be restricted by the SURREAL_FILE_ALLOWLIST setting, but an empty allowlist applied no restriction at all — and empty is the default.

Impact

The file is read with the privileges of the SurrealDB process, so a database EDITOR or OWNER user can disclose the contents of any file the process can access. Only the first line of the file is returned, except for files with no newlines.

However recovering the process's command line and environment could expose startup root credentials (--user / --pass) and secret environment variables, escalating a single-database role toward full control of the instance.

The read on the underlying filesystem is bounded by what the SurrealDB process can reach — any file readable by the OS user it runs as — so the impact scales with how the process is run and what is mounted into it.

Patches

A patch has been included in SurrealDB 3.1.5.

File access is now secure by default. check_is_path_allowed denies every path when no SURREAL_FILE_ALLOWLIST is configured, so the mapper filter cannot open any file unless the operator has explicitly allowed its directory. Analyzer parse errors no longer include the contents of the mapped file, only the line number.

Workarounds

Users unable to upgrade are advised to consider the following:

• Set SURREAL_FILE_ALLOWLIST to a directory that contains only the intended mapping files; this confines the mapper filter to that path. On affected versions the allowlist must be non-empty to have any effect.
• Grant the EDITOR and OWNER database roles only to trusted principals.
• Avoid supplying secrets — including the root credentials — on the command line or through environment variables; prefer mounted files with least-privilege permissions.

References

• SurrealQL Documentation — DEFINE ANALYZER
• SurrealDB Documentation — Capabilities
• Related earlier advisory: GHSA-2cvj-g5r5-jrrg local file read of 2-column TSV files via analyzers
• https://github.com/surrealdb/surrealdb/pull/5600
• fix(iam): deny filesystem access by default and stop leaking file content in analyzer errors

Acknowledgements

Thanks to Jan Kahmen (@kah-ja) for finding and reporting this issue.

SurrealDB fetches the JWKS document for a JWT or record access method using a bare reqwest client that follows HTTP redirects by default. The network capability check in core/src/iam/jwks.rs (check_capabilities_url) is applied only to the originally configured URL; redirect targets are not re-validated. An --allow-net-permitted JWKS host that returns a 3xx Location can therefore redirect the request to an address the allowlist was meant to block, resulting in a server-side request forgery (SSRF). The protected HttpClient used by http::* functions re-checks every redirect hop and was hardened in 3.1.0, but the JWKS fetcher uses its own client and was not covered.

Impact

What an attacker can do:

• With the Owner role at database level or above (the minimum required to run DEFINE ACCESS ... TYPE JWT URL or TYPE RECORD ... WITH JWT URL), point an access method at an allowlisted host they control and redirect the server's GET to an otherwise-blocked target — cloud metadata, loopback, internal services — bypassing --allow-net/--deny-net.
• Infer the existence and liveness of internal hosts and ports from response-timing differences (bounded by the 1-second fetch timeout).

What it can't do:

• Read the response: the fetch is blind — the body is only parsed as a JWKS, and a non-JWKS response surfaces as an opaque InvalidAuth error. Nothing is returned to the caller.
• Modify data or affect availability (a single GET request).

Patches

The JWKS fetcher now applies a redirect policy that re-validates every redirect target against the configured network capabilities (mirroring check_capabilities_url) and caps redirects at max_http_redirects.

• Versions prior to 3.1.5 are vulnerable.

Workarounds

• Restrict the Owner role to trusted operators.
• Enforce egress filtering at the network layer (block link-local 169.254.0.0/16 and internal ranges) so redirect targets are unreachable regardless of in-process checks.
• Configure access methods to use only trusted JWKS hosts that do not redirect, or use locally defined keys instead of a remote JWKS.

References

• SurrealDB Documentation — Capabilities
• SurrealQL Documentation — DEFINE ACCESS
• fix(iam): prevent SSRF in JWKS fetch by re-validating redirect targets

An authenticated user scoped to one namespace/database could invoke a custom API (DEFINE API) belonging to a different namespace/database, reaching another tenant's endpoint.

The route /api/{namespace}/{database}/{endpoint} took the namespace and database from the URL and applied them to the caller's session before the endpoint was looked up or run, without checking that the caller's authenticated scope covered them. Because a custom API handler runs with permissions disabled (definer's rights), the endpoint's own PERMISSIONS clause was the only gate — open to everyone for a PERMISSIONS FULL endpoint. The api::invoke() function was affected the same way, resolving against the session's selected namespace/database (settable via the surreal-ns / surreal-db headers or USE).

Impact

What an attacker can do:

• With valid credentials for any one namespace/database (a VIEWER is enough), invoke a custom API in another namespace/database by naming the victim scope in the URL.
• Read data that endpoint returns — including from PERMISSIONS NONE tables, since the handler runs with permissions disabled — or trigger any writes and side effects it performs.

What it can't do:

• Reach a scope without valid credentials for some namespace/database on the instance; this is not an unauthenticated bypass.
• Affect single-tenant deployments, or any deployment where callers already hold instance-wide (root) scope.

Patches

The namespace/database is now validated against the caller's authenticated level — which the request cannot change — before the endpoint is resolved or run. A target scope outside that level is rejected with 403 Forbidden, both at the HTTP entry point and at the dispatch step shared with api::invoke(). Root reaches any scope; namespace principals their namespace; database and record principals their exact namespace/database; anonymous callers remain governed by the endpoint's PERMISSIONS.

• Versions 3.2.0 and later are not affected by this issue.

Workarounds

Users unable to patch should consider the following workarounds:

• Disable the custom API HTTP route via capabilities where it is not required.
• Treat separate deployments, not namespace/database boundaries, as the tenant isolation boundary on shared instances.
• Prefer a PERMISSIONS WHERE clause that checks the authenticated identity over PERMISSIONS FULL (reduces exposure but does not restore the boundary).

Resources

• SurrealQL Documentation — DEFINE API
• SurrealDB Documentation — Capabilities
• fix(core/api): reject cross-tenant custom API access (included in SurrealDB 3.2.0)

Acknowledgements

SurrealDB thanks sondt99 for reporting this issue.

A SELECT permission defined on an array element (DEFINE FIELD field.* … PERMISSIONS FOR select …) is not enforced correctly for RECORD users. Instead of hiding the denied elements, the query leaks a subset of them: a deny-all returns the odd-indexed elements, and a per-element predicate keeps and drops the wrong ones.

The filter removed each denied element by index while walking the array forwards. Because removing an element shifts every later index down, each cut invalidated the indices still pending in the loop, leaving denied elements behind. Field-level permissions are enforced correctly; only the element (field.*) level is affected, and only for record users — root and record-owner sessions are not.

Impact

What an attacker can do:

• As a record (scope) user, read array elements that an element-level (field.*) SELECT permission should hide, on any table they can already SELECT.
• Recover denied elements through both a deny-all and a WHERE predicate — the wrong elements are selected either way.

What it can't do:

• Bypass field-level SELECT permissions, which are evaluated correctly.
• Affect root or record-owner sessions, or cross namespace/database isolation.
• Modify data, escalate privileges, or affect availability (confidentiality only).

Patches

The three permission-filtering paths (doc/reduce.rs, doc/output.rs, exec/operators/scan/pipeline.rs) now remove denied elements in reverse index order, so removing one element no longer shifts the elements still to be checked. Regression tests reproducing the issue were added.

The fix is included in SurrealDB 3.1.4.

Workarounds

• Do not rely on element-level (field.*) permissions to hide data from record users; use field-level permissions, which are enforced correctly.
• Restrict record users from selecting tables whose schema uses element-level permissions.

Resources

• DEFINE FIELD
• USERS
• DEFINE TABLE … PERMISSIONS
• fix(sec): stop array element-level SELECT permissions leaking elements (commit 8f89b260b)

An authenticated user could crash a SurrealDB server with a single query containing a long chain of operators.

Such a query — for example RETURN 1 + 1 + 1 + ... with tens of thousands of terms — is parsed into an expression tree one level deep per operator. Because the chain is flat and the pratt parser appends to it iteratively, the configured query- and object-recursion limits never fire, so the tree grows unbounded with the length of the query.

The root cause: the over-deep tree is later walked recursively, one call per node, when it is dropped, formatted, or lowered for execution — overflowing the thread stack and aborting the process.

Impact

An authenticated user with query-execution privileges can crash a SurrealDB server with a single query containing a long chain of operators. The whole process aborts, denying service to every namespace and database on that instance until it is restarted. The crash occurs during query processing, before any data is read or written (availability only).

Patches

A patch introduces a dedicated expression-depth budget — expr_recursion_limit, sourced from max_expression_parsing_depth (default 128, configurable via SURREAL_MAX_EXPRESSION_PARSING_DEPTH). It is charged once per pratt-parser level and once per operator appended to the spine, so an over-deep operator chain is rejected with a syntax error instead of building a tree that overflows the stack downstream. Paths that re-parse already-validated stored data are exempted, so existing databases with deep stored expressions still load.

• Versions 3.1.5 and later are not affected by this issue.

Workarounds

Users unable to patch should consider the following workarounds:

• Restrict the ability of untrusted users to execute arbitrary queries via the --deny-arbitrary-query capability flag for the affected user classes (guest, record, or system).
• Restrict untrusted access to the WebSocket /rpc endpoint, which accepts larger request bodies than the HTTP /sql endpoint. The /sql endpoint's 1 MiB body limit lowers the achievable operator depth but does not by itself guarantee the stack cannot be exhausted.
• Run SurrealDB under an orchestrator or process manager that restarts it automatically on exit (e.g. Kubernetes, systemd Restart=on-failure, or a Docker restart policy), so the server recovers immediately after a crash. This limits downtime from a successful attack but does not prevent the crash.

References

• SurrealQL Documentation — Operators
• fix(syn): bound expression operator-tree depth to prevent stack-overflow DoS

A record user could read field values hidden from them by field-level SELECT permissions by reaching the records through a graph-edge (->) or back-reference (<~) traversal instead of a direct SELECT.

When a table was readable at the table level but carried a field hidden by a field-level permission (DEFINE FIELD secret ON knows PERMISSIONS FOR select NONE), a direct SELECT * FROM knows hid secret — but reaching the same records through a traversal that yields full objects — person:bob->(SELECT * FROM knows), person:bob<~(SELECT * FROM comment), or a projected target vertex ->knows->(SELECT * FROM person) — returned it intact.

The root cause: the shared resolve_record_batch helper used by GraphEdgeScan (FullEdge) and ReferenceScan (FullRecord) enforced only the table-level SELECT permission and pushed raw record data, never running the field-level filtering (build_field_state / filter_fields_by_permission) that ordinary table scans and fetch_record apply.

Impact

A record user can read the values of fields hidden by field-level SELECT permissions, on tables they already hold table-level SELECT on, by materialising the records through a graph-edge, back-reference, or target-vertex traversal — recovering the values directly, for every record the traversal returns.

The disclosure is confined to the field-permission layer: it grants no unauthorised cross-table, cross-record, or cross-namespace/database access. The table's own SELECT permission — including any row-level WHERE predicate — is still enforced, so the caller only reaches records they were already entitled to read; only the per-field SELECT filtering within those records is skipped. Root and record-owner sessions are unaffected, and data cannot be modified (confidentiality only).

Table-level enforcement on these traversals landed in 3.1.0 (the fix for GHSA-vjjx-rfw4-rmfc); releases before 3.1.0 additionally exposed whole records on tables the caller could not read, and are covered by that advisory.

Patches

resolve_record_batch (the shared helper that materialises full records for graph and reference traversals) now applies field-level SELECT permissions and read-time COMPUTED fields to each record, matching the regular table-scan and fetch_record paths.

Versions 3.1.5 and later are not affected.

Workarounds

• Force the unaffected legacy executor with --planner-strategy compute-only (env SURREAL_PLANNER_STRATEGY).
• Do not rely on field-level SELECT permissions to hide values on tables reachable as a graph edge, reference target, or traversal vertex; restrict at the table level instead.
• Use namespace / database isolation as the primary boundary where feasible.

Resources

• SurrealQL Documentation — DEFINE FIELD
• SurrealQL Documentation — DEFINE TABLE … PERMISSIONS
• SurrealQL Documentation — Graph relationships
• fix(exec): apply field-level SELECT permissions + computed fields when graph/reference traversals materialize full records

A field can be hidden from a user with a field-level SELECT permission (DEFINE FIELD code ON secret PERMISSIONS FOR select WHERE owner = $auth.id). When that field is indexed, a record user who cannot read it could still recover the relative ordering of its values across every record by issuing ORDER BY <field>: the field came back null as intended, but the rows were returned in the hidden values' true sorted order.

To satisfy the sort, the planner selects the field's index and walks it in value order; the field-level permission is applied later, when the row is projected, so the value is nulled but the row order already encodes it. The guard that withholds restricted fields from the WHERE path was never applied to ORDER BY.

Impact

What an attacker can do:

• As a record (scope) user with table SELECT, learn the relative ordering of a field hidden by a field-level SELECT permission, across other users' records, by ordering on it when an index covers the field — the value returns null, but the rows come back in the hidden values' order.
• With rows they control in the same table, use that ordering to narrow the hidden values toward exact ones.

What it can't do:

• Read the field value directly — only its relative ordering leaks; the projected value is correctly redacted.
• Cross table, record, or namespace/database boundaries — the table's SELECT permission and any row-level WHERE are still enforced, so only records the caller may already read are ordered.
• Leak anything when the restricted field is not indexed, affect root or record-owner sessions, or modify data (confidentiality only).

Patches

The query planner now applies the field-permission guard to the ORDER BY clause as well as the WHERE clause. When an ordered field is hidden from the caller by a field-level SELECT permission, the index sort pushdown is withheld and the rows are sorted after redaction instead, so the row order no longer reflects the hidden values. The dynamic-scan fallback is closed the same way, and a regression test was added.

The fix is included in SurrealDB 3.1.5.

Workarounds

Users unable to upgrade are advised to consider the following:

• Force the legacy executor with SURREAL_PLANNER_STRATEGY=compute-only; the sort then runs after redaction, so no ordering leaks.
• Do not place an index on a field whose values are hidden by a field-level SELECT permission — without the index the leak does not occur.
• Do not rely on field-level SELECT permissions to hide values on indexed fields from record users; restrict at the table level instead.
• Use namespace / database isolation as the primary trust boundary where feasible.

References

• SurrealQL Documentation — DEFINE FIELD
• SurrealQL Documentation — DEFINE INDEX
• SurrealQL Documentation — DEFINE TABLE … PERMISSIONS
• Related advisory (same class, indexed COUNT variant): GHSA-c8jx-96c9-8xrp
• fix(planner): prevent ORDER BY value-ordering oracle on restricted SELECT fields
• fix(planner): close ORDER BY value-ordering oracle on the DynamicScan fallback

Acknowledgements

Thanks to George Chen (@geo-chen) for finding and reporting this issue.

SurrealDB's full-text search lets you define a text analyzer whose mapper filter loads a term-mapping file from disk (DEFINE ANALYZER ... FILTERS mapper('<path>')). A database user with the EDITOR or OWNER role could point that filter at any file the SurrealDB process can read and have its content returned in the query's error message.

File access is meant to be restricted by the SURREAL_FILE_ALLOWLIST setting, but an empty allowlist applied no restriction at all — and empty is the default.

Impact

The file is read with the privileges of the SurrealDB process, so a database EDITOR or OWNER user can disclose the contents of any file the process can access. Only the first line of the file is returned, except for files with no newlines.

However recovering the process's command line and environment could expose startup root credentials (--user / --pass) and secret environment variables, escalating a single-database role toward full control of the instance.

The read on the underlying filesystem is bounded by what the SurrealDB process can reach — any file readable by the OS user it runs as — so the impact scales with how the process is run and what is mounted into it.

Patches

A patch has been included in SurrealDB 3.1.5.

File access is now secure by default. check_is_path_allowed denies every path when no SURREAL_FILE_ALLOWLIST is configured, so the mapper filter cannot open any file unless the operator has explicitly allowed its directory. Analyzer parse errors no longer include the contents of the mapped file, only the line number.

Workarounds

Users unable to upgrade are advised to consider the following:

• Set SURREAL_FILE_ALLOWLIST to a directory that contains only the intended mapping files; this confines the mapper filter to that path. On affected versions the allowlist must be non-empty to have any effect.
• Grant the EDITOR and OWNER database roles only to trusted principals.
• Avoid supplying secrets — including the root credentials — on the command line or through environment variables; prefer mounted files with least-privilege permissions.

References

• SurrealQL Documentation — DEFINE ANALYZER
• SurrealDB Documentation — Capabilities
• Related earlier advisory: GHSA-2cvj-g5r5-jrrg local file read of 2-column TSV files via analyzers
• https://github.com/surrealdb/surrealdb/pull/5600
• fix(iam): deny filesystem access by default and stop leaking file content in analyzer errors

Acknowledgements

Thanks to Jan Kahmen (@kah-ja) for finding and reporting this issue.

SurrealDB fetches the JWKS document for a JWT or record access method using a bare reqwest client that follows HTTP redirects by default. The network capability check in core/src/iam/jwks.rs (check_capabilities_url) is applied only to the originally configured URL; redirect targets are not re-validated. An --allow-net-permitted JWKS host that returns a 3xx Location can therefore redirect the request to an address the allowlist was meant to block, resulting in a server-side request forgery (SSRF). The protected HttpClient used by http::* functions re-checks every redirect hop and was hardened in 3.1.0, but the JWKS fetcher uses its own client and was not covered.

Impact

What an attacker can do:

• With the Owner role at database level or above (the minimum required to run DEFINE ACCESS ... TYPE JWT URL or TYPE RECORD ... WITH JWT URL), point an access method at an allowlisted host they control and redirect the server's GET to an otherwise-blocked target — cloud metadata, loopback, internal services — bypassing --allow-net/--deny-net.
• Infer the existence and liveness of internal hosts and ports from response-timing differences (bounded by the 1-second fetch timeout).

What it can't do:

• Read the response: the fetch is blind — the body is only parsed as a JWKS, and a non-JWKS response surfaces as an opaque InvalidAuth error. Nothing is returned to the caller.
• Modify data or affect availability (a single GET request).

Patches

The JWKS fetcher now applies a redirect policy that re-validates every redirect target against the configured network capabilities (mirroring check_capabilities_url) and caps redirects at max_http_redirects.

• Versions prior to 3.1.5 are vulnerable.

Workarounds

• Restrict the Owner role to trusted operators.
• Enforce egress filtering at the network layer (block link-local 169.254.0.0/16 and internal ranges) so redirect targets are unreachable regardless of in-process checks.
• Configure access methods to use only trusted JWKS hosts that do not redirect, or use locally defined keys instead of a remote JWKS.

References

• SurrealDB Documentation — Capabilities
• SurrealQL Documentation — DEFINE ACCESS
• fix(iam): prevent SSRF in JWKS fetch by re-validating redirect targets

An authenticated user scoped to one namespace/database could invoke a custom API (DEFINE API) belonging to a different namespace/database, reaching another tenant's endpoint.

The route /api/{namespace}/{database}/{endpoint} took the namespace and database from the URL and applied them to the caller's session before the endpoint was looked up or run, without checking that the caller's authenticated scope covered them. Because a custom API handler runs with permissions disabled (definer's rights), the endpoint's own PERMISSIONS clause was the only gate — open to everyone for a PERMISSIONS FULL endpoint. The api::invoke() function was affected the same way, resolving against the session's selected namespace/database (settable via the surreal-ns / surreal-db headers or USE).

Impact

What an attacker can do:

• With valid credentials for any one namespace/database (a VIEWER is enough), invoke a custom API in another namespace/database by naming the victim scope in the URL.
• Read data that endpoint returns — including from PERMISSIONS NONE tables, since the handler runs with permissions disabled — or trigger any writes and side effects it performs.

What it can't do:

• Reach a scope without valid credentials for some namespace/database on the instance; this is not an unauthenticated bypass.
• Affect single-tenant deployments, or any deployment where callers already hold instance-wide (root) scope.

Patches

The namespace/database is now validated against the caller's authenticated level — which the request cannot change — before the endpoint is resolved or run. A target scope outside that level is rejected with 403 Forbidden, both at the HTTP entry point and at the dispatch step shared with api::invoke(). Root reaches any scope; namespace principals their namespace; database and record principals their exact namespace/database; anonymous callers remain governed by the endpoint's PERMISSIONS.

• Versions 3.2.0 and later are not affected by this issue.

Workarounds

Users unable to patch should consider the following workarounds:

• Disable the custom API HTTP route via capabilities where it is not required.
• Treat separate deployments, not namespace/database boundaries, as the tenant isolation boundary on shared instances.
• Prefer a PERMISSIONS WHERE clause that checks the authenticated identity over PERMISSIONS FULL (reduces exposure but does not restore the boundary).

Resources

• SurrealQL Documentation — DEFINE API
• SurrealDB Documentation — Capabilities
• fix(core/api): reject cross-tenant custom API access (included in SurrealDB 3.2.0)

Acknowledgements

SurrealDB thanks sondt99 for reporting this issue.

A SELECT permission defined on an array element (DEFINE FIELD field.* … PERMISSIONS FOR select …) is not enforced correctly for RECORD users. Instead of hiding the denied elements, the query leaks a subset of them: a deny-all returns the odd-indexed elements, and a per-element predicate keeps and drops the wrong ones.

The filter removed each denied element by index while walking the array forwards. Because removing an element shifts every later index down, each cut invalidated the indices still pending in the loop, leaving denied elements behind. Field-level permissions are enforced correctly; only the element (field.*) level is affected, and only for record users — root and record-owner sessions are not.

Impact

What an attacker can do:

• As a record (scope) user, read array elements that an element-level (field.*) SELECT permission should hide, on any table they can already SELECT.
• Recover denied elements through both a deny-all and a WHERE predicate — the wrong elements are selected either way.

What it can't do:

• Bypass field-level SELECT permissions, which are evaluated correctly.
• Affect root or record-owner sessions, or cross namespace/database isolation.
• Modify data, escalate privileges, or affect availability (confidentiality only).

Patches

The three permission-filtering paths (doc/reduce.rs, doc/output.rs, exec/operators/scan/pipeline.rs) now remove denied elements in reverse index order, so removing one element no longer shifts the elements still to be checked. Regression tests reproducing the issue were added.

The fix is included in SurrealDB 3.1.4.

Workarounds

• Do not rely on element-level (field.*) permissions to hide data from record users; use field-level permissions, which are enforced correctly.
• Restrict record users from selecting tables whose schema uses element-level permissions.

Resources

• DEFINE FIELD
• USERS
• DEFINE TABLE … PERMISSIONS
• fix(sec): stop array element-level SELECT permissions leaking elements (commit 8f89b260b)

An authenticated user could crash a SurrealDB server with a single query containing a long chain of operators.

Such a query — for example RETURN 1 + 1 + 1 + ... with tens of thousands of terms — is parsed into an expression tree one level deep per operator. Because the chain is flat and the pratt parser appends to it iteratively, the configured query- and object-recursion limits never fire, so the tree grows unbounded with the length of the query.

The root cause: the over-deep tree is later walked recursively, one call per node, when it is dropped, formatted, or lowered for execution — overflowing the thread stack and aborting the process.

Impact

An authenticated user with query-execution privileges can crash a SurrealDB server with a single query containing a long chain of operators. The whole process aborts, denying service to every namespace and database on that instance until it is restarted. The crash occurs during query processing, before any data is read or written (availability only).

Patches

A patch introduces a dedicated expression-depth budget — expr_recursion_limit, sourced from max_expression_parsing_depth (default 128, configurable via SURREAL_MAX_EXPRESSION_PARSING_DEPTH). It is charged once per pratt-parser level and once per operator appended to the spine, so an over-deep operator chain is rejected with a syntax error instead of building a tree that overflows the stack downstream. Paths that re-parse already-validated stored data are exempted, so existing databases with deep stored expressions still load.

• Versions 3.1.5 and later are not affected by this issue.

Workarounds

Users unable to patch should consider the following workarounds:

• Restrict the ability of untrusted users to execute arbitrary queries via the --deny-arbitrary-query capability flag for the affected user classes (guest, record, or system).
• Restrict untrusted access to the WebSocket /rpc endpoint, which accepts larger request bodies than the HTTP /sql endpoint. The /sql endpoint's 1 MiB body limit lowers the achievable operator depth but does not by itself guarantee the stack cannot be exhausted.
• Run SurrealDB under an orchestrator or process manager that restarts it automatically on exit (e.g. Kubernetes, systemd Restart=on-failure, or a Docker restart policy), so the server recovers immediately after a crash. This limits downtime from a successful attack but does not prevent the crash.

References

• SurrealQL Documentation — Operators
• fix(syn): bound expression operator-tree depth to prevent stack-overflow DoS

A record user could read field values hidden from them by field-level SELECT permissions by reaching the records through a graph-edge (->) or back-reference (<~) traversal instead of a direct SELECT.

When a table was readable at the table level but carried a field hidden by a field-level permission (DEFINE FIELD secret ON knows PERMISSIONS FOR select NONE), a direct SELECT * FROM knows hid secret — but reaching the same records through a traversal that yields full objects — person:bob->(SELECT * FROM knows), person:bob<~(SELECT * FROM comment), or a projected target vertex ->knows->(SELECT * FROM person) — returned it intact.

The root cause: the shared resolve_record_batch helper used by GraphEdgeScan (FullEdge) and ReferenceScan (FullRecord) enforced only the table-level SELECT permission and pushed raw record data, never running the field-level filtering (build_field_state / filter_fields_by_permission) that ordinary table scans and fetch_record apply.

Impact

A record user can read the values of fields hidden by field-level SELECT permissions, on tables they already hold table-level SELECT on, by materialising the records through a graph-edge, back-reference, or target-vertex traversal — recovering the values directly, for every record the traversal returns.

The disclosure is confined to the field-permission layer: it grants no unauthorised cross-table, cross-record, or cross-namespace/database access. The table's own SELECT permission — including any row-level WHERE predicate — is still enforced, so the caller only reaches records they were already entitled to read; only the per-field SELECT filtering within those records is skipped. Root and record-owner sessions are unaffected, and data cannot be modified (confidentiality only).

Table-level enforcement on these traversals landed in 3.1.0 (the fix for GHSA-vjjx-rfw4-rmfc); releases before 3.1.0 additionally exposed whole records on tables the caller could not read, and are covered by that advisory.

Patches

resolve_record_batch (the shared helper that materialises full records for graph and reference traversals) now applies field-level SELECT permissions and read-time COMPUTED fields to each record, matching the regular table-scan and fetch_record paths.

Versions 3.1.5 and later are not affected.

Workarounds

• Force the unaffected legacy executor with --planner-strategy compute-only (env SURREAL_PLANNER_STRATEGY).
• Do not rely on field-level SELECT permissions to hide values on tables reachable as a graph edge, reference target, or traversal vertex; restrict at the table level instead.
• Use namespace / database isolation as the primary boundary where feasible.

Resources

• SurrealQL Documentation — DEFINE FIELD
• SurrealQL Documentation — DEFINE TABLE … PERMISSIONS
• SurrealQL Documentation — Graph relationships
• fix(exec): apply field-level SELECT permissions + computed fields when graph/reference traversals materialize full records

A field can be hidden from a user with a field-level SELECT permission (DEFINE FIELD code ON secret PERMISSIONS FOR select WHERE owner = $auth.id). When that field is indexed, a record user who cannot read it could still recover the relative ordering of its values across every record by issuing ORDER BY <field>: the field came back null as intended, but the rows were returned in the hidden values' true sorted order.

To satisfy the sort, the planner selects the field's index and walks it in value order; the field-level permission is applied later, when the row is projected, so the value is nulled but the row order already encodes it. The guard that withholds restricted fields from the WHERE path was never applied to ORDER BY.

Impact

What an attacker can do:

• As a record (scope) user with table SELECT, learn the relative ordering of a field hidden by a field-level SELECT permission, across other users' records, by ordering on it when an index covers the field — the value returns null, but the rows come back in the hidden values' order.
• With rows they control in the same table, use that ordering to narrow the hidden values toward exact ones.

What it can't do:

• Read the field value directly — only its relative ordering leaks; the projected value is correctly redacted.
• Cross table, record, or namespace/database boundaries — the table's SELECT permission and any row-level WHERE are still enforced, so only records the caller may already read are ordered.
• Leak anything when the restricted field is not indexed, affect root or record-owner sessions, or modify data (confidentiality only).

Patches

The query planner now applies the field-permission guard to the ORDER BY clause as well as the WHERE clause. When an ordered field is hidden from the caller by a field-level SELECT permission, the index sort pushdown is withheld and the rows are sorted after redaction instead, so the row order no longer reflects the hidden values. The dynamic-scan fallback is closed the same way, and a regression test was added.

The fix is included in SurrealDB 3.1.5.

Workarounds

Users unable to upgrade are advised to consider the following:

• Force the legacy executor with SURREAL_PLANNER_STRATEGY=compute-only; the sort then runs after redaction, so no ordering leaks.
• Do not place an index on a field whose values are hidden by a field-level SELECT permission — without the index the leak does not occur.
• Do not rely on field-level SELECT permissions to hide values on indexed fields from record users; restrict at the table level instead.
• Use namespace / database isolation as the primary trust boundary where feasible.

References

• SurrealQL Documentation — DEFINE FIELD
• SurrealQL Documentation — DEFINE INDEX
• SurrealQL Documentation — DEFINE TABLE … PERMISSIONS
• Related advisory (same class, indexed COUNT variant): GHSA-c8jx-96c9-8xrp
• fix(planner): prevent ORDER BY value-ordering oracle on restricted SELECT fields
• fix(planner): close ORDER BY value-ordering oracle on the DynamicScan fallback

Acknowledgements

Thanks to George Chen (@geo-chen) for finding and reporting this issue.

SurrealDB's full-text search lets you define a text analyzer whose mapper filter loads a term-mapping file from disk (DEFINE ANALYZER ... FILTERS mapper('<path>')). A database user with the EDITOR or OWNER role could point that filter at any file the SurrealDB process can read and have its content returned in the query's error message.

File access is meant to be restricted by the SURREAL_FILE_ALLOWLIST setting, but an empty allowlist applied no restriction at all — and empty is the default.

Impact

The file is read with the privileges of the SurrealDB process, so a database EDITOR or OWNER user can disclose the contents of any file the process can access. Only the first line of the file is returned, except for files with no newlines.

However recovering the process's command line and environment could expose startup root credentials (--user / --pass) and secret environment variables, escalating a single-database role toward full control of the instance.

The read on the underlying filesystem is bounded by what the SurrealDB process can reach — any file readable by the OS user it runs as — so the impact scales with how the process is run and what is mounted into it.

Patches

A patch has been included in SurrealDB 3.1.5.

File access is now secure by default. check_is_path_allowed denies every path when no SURREAL_FILE_ALLOWLIST is configured, so the mapper filter cannot open any file unless the operator has explicitly allowed its directory. Analyzer parse errors no longer include the contents of the mapped file, only the line number.

Workarounds

Users unable to upgrade are advised to consider the following:

• Set SURREAL_FILE_ALLOWLIST to a directory that contains only the intended mapping files; this confines the mapper filter to that path. On affected versions the allowlist must be non-empty to have any effect.
• Grant the EDITOR and OWNER database roles only to trusted principals.
• Avoid supplying secrets — including the root credentials — on the command line or through environment variables; prefer mounted files with least-privilege permissions.

References

• SurrealQL Documentation — DEFINE ANALYZER
• SurrealDB Documentation — Capabilities
• Related earlier advisory: GHSA-2cvj-g5r5-jrrg local file read of 2-column TSV files via analyzers
• https://github.com/surrealdb/surrealdb/pull/5600
• fix(iam): deny filesystem access by default and stop leaking file content in analyzer errors

Acknowledgements

Thanks to Jan Kahmen (@kah-ja) for finding and reporting this issue.

SurrealDB fetches the JWKS document for a JWT or record access method using a bare reqwest client that follows HTTP redirects by default. The network capability check in core/src/iam/jwks.rs (check_capabilities_url) is applied only to the originally configured URL; redirect targets are not re-validated. An --allow-net-permitted JWKS host that returns a 3xx Location can therefore redirect the request to an address the allowlist was meant to block, resulting in a server-side request forgery (SSRF). The protected HttpClient used by http::* functions re-checks every redirect hop and was hardened in 3.1.0, but the JWKS fetcher uses its own client and was not covered.

Impact

What an attacker can do:

• With the Owner role at database level or above (the minimum required to run DEFINE ACCESS ... TYPE JWT URL or TYPE RECORD ... WITH JWT URL), point an access method at an allowlisted host they control and redirect the server's GET to an otherwise-blocked target — cloud metadata, loopback, internal services — bypassing --allow-net/--deny-net.
• Infer the existence and liveness of internal hosts and ports from response-timing differences (bounded by the 1-second fetch timeout).

What it can't do:

• Read the response: the fetch is blind — the body is only parsed as a JWKS, and a non-JWKS response surfaces as an opaque InvalidAuth error. Nothing is returned to the caller.
• Modify data or affect availability (a single GET request).

Patches

The JWKS fetcher now applies a redirect policy that re-validates every redirect target against the configured network capabilities (mirroring check_capabilities_url) and caps redirects at max_http_redirects.

• Versions prior to 3.1.5 are vulnerable.

Workarounds

• Restrict the Owner role to trusted operators.
• Enforce egress filtering at the network layer (block link-local 169.254.0.0/16 and internal ranges) so redirect targets are unreachable regardless of in-process checks.
• Configure access methods to use only trusted JWKS hosts that do not redirect, or use locally defined keys instead of a remote JWKS.

References

• SurrealDB Documentation — Capabilities
• SurrealQL Documentation — DEFINE ACCESS
• fix(iam): prevent SSRF in JWKS fetch by re-validating redirect targets

An authenticated user scoped to one namespace/database could invoke a custom API (DEFINE API) belonging to a different namespace/database, reaching another tenant's endpoint.

The route /api/{namespace}/{database}/{endpoint} took the namespace and database from the URL and applied them to the caller's session before the endpoint was looked up or run, without checking that the caller's authenticated scope covered them. Because a custom API handler runs with permissions disabled (definer's rights), the endpoint's own PERMISSIONS clause was the only gate — open to everyone for a PERMISSIONS FULL endpoint. The api::invoke() function was affected the same way, resolving against the session's selected namespace/database (settable via the surreal-ns / surreal-db headers or USE).

Impact

What an attacker can do:

• With valid credentials for any one namespace/database (a VIEWER is enough), invoke a custom API in another namespace/database by naming the victim scope in the URL.
• Read data that endpoint returns — including from PERMISSIONS NONE tables, since the handler runs with permissions disabled — or trigger any writes and side effects it performs.

What it can't do:

• Reach a scope without valid credentials for some namespace/database on the instance; this is not an unauthenticated bypass.
• Affect single-tenant deployments, or any deployment where callers already hold instance-wide (root) scope.

Patches

The namespace/database is now validated against the caller's authenticated level — which the request cannot change — before the endpoint is resolved or run. A target scope outside that level is rejected with 403 Forbidden, both at the HTTP entry point and at the dispatch step shared with api::invoke(). Root reaches any scope; namespace principals their namespace; database and record principals their exact namespace/database; anonymous callers remain governed by the endpoint's PERMISSIONS.

• Versions 3.2.0 and later are not affected by this issue.

Workarounds

Users unable to patch should consider the following workarounds:

• Disable the custom API HTTP route via capabilities where it is not required.
• Treat separate deployments, not namespace/database boundaries, as the tenant isolation boundary on shared instances.
• Prefer a PERMISSIONS WHERE clause that checks the authenticated identity over PERMISSIONS FULL (reduces exposure but does not restore the boundary).

Resources

• SurrealQL Documentation — DEFINE API
• SurrealDB Documentation — Capabilities
• fix(core/api): reject cross-tenant custom API access (included in SurrealDB 3.2.0)

Acknowledgements

SurrealDB thanks sondt99 for reporting this issue.

A SELECT permission defined on an array element (DEFINE FIELD field.* … PERMISSIONS FOR select …) is not enforced correctly for RECORD users. Instead of hiding the denied elements, the query leaks a subset of them: a deny-all returns the odd-indexed elements, and a per-element predicate keeps and drops the wrong ones.

The filter removed each denied element by index while walking the array forwards. Because removing an element shifts every later index down, each cut invalidated the indices still pending in the loop, leaving denied elements behind. Field-level permissions are enforced correctly; only the element (field.*) level is affected, and only for record users — root and record-owner sessions are not.

Impact

What an attacker can do:

• As a record (scope) user, read array elements that an element-level (field.*) SELECT permission should hide, on any table they can already SELECT.
• Recover denied elements through both a deny-all and a WHERE predicate — the wrong elements are selected either way.

What it can't do:

• Bypass field-level SELECT permissions, which are evaluated correctly.
• Affect root or record-owner sessions, or cross namespace/database isolation.
• Modify data, escalate privileges, or affect availability (confidentiality only).

Patches

The three permission-filtering paths (doc/reduce.rs, doc/output.rs, exec/operators/scan/pipeline.rs) now remove denied elements in reverse index order, so removing one element no longer shifts the elements still to be checked. Regression tests reproducing the issue were added.

The fix is included in SurrealDB 3.1.4.

Workarounds

• Do not rely on element-level (field.*) permissions to hide data from record users; use field-level permissions, which are enforced correctly.
• Restrict record users from selecting tables whose schema uses element-level permissions.

Resources

• DEFINE FIELD
• USERS
• DEFINE TABLE … PERMISSIONS
• fix(sec): stop array element-level SELECT permissions leaking elements (commit 8f89b260b)

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.

When a user configures ALGORITHM ES512 for any JWT access method (DEFINE ACCESS ... TYPE JWT ALGORITHM ES512), SurrealDB silently substitutes ES384 at all four internal algorithm conversion points. This occurs because the underlying jsonwebtoken crate (v10.x) does not include an ES512 algorithm variant, so the mapping defaults to ES384 without raising an error, warning, or log message.

Users who provide the correct P-521 key type for ES512 will experience authentication handshake failures due to the curve mismatch with ES384 (which expects P-384).

Impact

Authentication handshake failures when using ES512 with the correct P-521 key type, and when tokens are verified by external systems expecting real ES512 signatures.

This vulnerability cannot be exploited to forge tokens or compromise the integrity or confidentiality of data handled by SurrealDB, as ES384 remains cryptographically strong.

Patches

Versions prior to SurrealDB v3.1.0 are vulnerable.

The patches for SurrealDB v3.1.0 block new DEFINE ACCESS statements using ALGORITHM ES512 with a clear error message and add deprecation warnings at runtime for existing stored ES512 definitions.

Workarounds

Users should reconfigure affected JWT access methods to use a supported algorithm such as ES384 (with a P-384 key pair) or another supported algorithm. Review any DEFINE ACCESS statements specifying ALGORITHM ES512 and update them accordingly.

A record user could learn the value of a hidden field by counting how many records match a guess.

When DEFINE FIELD ... PERMISSIONS FOR select WHERE ... hides a field's contents from a caller, and that field is indexed, running SELECT count() FROM t WHERE hidden_field = "guess" GROUP ALL returned a count greater than zero whenever a record actually had that value — even though the caller was never allowed to read the field directly. The query planner used an indexed-COUNT shortcut (Index::Count, IndexCountScan, or the legacy Iterate Index Count / Iterate Index Keys paths) that counts matching index entries and skips the permission check that would normally hide the value. The same query with WITH NOINDEX correctly returned [], confirming the gap.

By repeating the count query with different guesses, an attacker can confirm or recover the contents of any restricted field they could not read through a normal SELECT.

Impact

What an attacker can do:

• Confirm or recover values of a field protected by field-level SELECT permissions on any table they hold table-level SELECT on, provided the field is indexed.
• Repeat the query with different guesses to read restricted field contents one value at a time.

What it can't do:

• Read fields that are not indexed (the shortcut only fires when an index covers the predicate column).
• Cross table, database or namespace isolation boundaries.
• Modify data, escalate privileges, or affect availability.

Patches

The legacy planner (surrealdb/core/src/idx/planner/tree.rs) and the streaming planner (surrealdb/core/src/exec/planner/select/mod.rs) now both refuse the indexed fast path when the WHERE / ORDER tree references a field governed by a non-Full SELECT permission:

• resolve_indexes skips any B-tree / unique index whose columns are governed by such a permission.
• A new cond_touches_restricted_field flag is propagated; eval_count refuses a dedicated Index::Count when set.
• The streaming planner adds cond_touches_restricted_select_field, a RestrictedIdiomChecker visitor that matches each idiom against the table's field-permission prefixes (loaded via the plan-time txn), and gates IndexCountScan emission on it.
• The fast paths are preserved for root / owner sessions via should_check_perms_for_view.

Versions 3.1.0 and later are not affected.

Workarounds

Users unable to patch are advised to consider the following workarounds:

• Avoid DEFINE INDEX on fields whose values are protected by field-level SELECT permissions. The class of attack is specific to the indexed fast paths.
• Restrict the ability of record users to issue arbitrary SELECT count() … GROUP ALL queries against tables containing field-protected columns.
• Use namespace / database isolation as the primary boundary where feasible.

An anonymous caller could create new namespaces and databases on a running SurrealDB instance without holding DEFINE NAMESPACE or DEFINE DATABASE permission.

USE NS <name> and USE DB <name> automatically create the target when it does not exist. The three places USE is handled — the RPC use method, Datastore::process_use, and the SurrealQL executor — did not check whether the caller was allowed to create the resource. Under default capabilities any session reached this path, including an unauthenticated guest.

Impact

What an attacker can do:

• Create new namespaces and databases without DEFINE NAMESPACE / DEFINE DATABASE permission. An unauthenticated guest is enough under default capabilities.
• Recreate a parent namespace that an operator deliberately dropped, using a stale namespace-Editor token, by running USE NS <dropped> DB anything.
• Exhaust catalog storage by repeatedly creating new resources.

What it can't do:

• Read or modify data inside any pre-existing namespace or database.
• Escalate to root or namespace-owner privileges on existing resources.
• Affect deployments running with auth_enabled=false.

Patches

All three USE entry points now check whether the caller has DEFINE NAMESPACE / DEFINE DATABASE authority before creating a missing target. Sessions still update their context regardless of authorization, so SDKs that send use before signin continue to work — only the catalog creation step is gated. The parent-namespace side-effect path is closed by the same check.

Versions 3.1.0 and later are not affected.

Workarounds

• Set --deny-arbitrary-query * for guest principals to remove the entry point.
• Run with --auth and require all callers to signin before issuing use.
• Revoke namespace-level tokens promptly when a namespace is dropped.

SurrealDB offers http::* functions that can access external network endpoints, with the --allow-net and --deny-net capabilities used to restrict the set of network targets that can be reached. An authenticated user of SurrealDB can bypass a port-scoped --deny-net <host>:<port> rule by chaining an HTTP redirect: the initial request goes to an --allow-net-permitted hostname, the response's 3xx Location header points at the denied host:port, and the redirect is followed even though the destination was explicitly denied.

The root cause is in the redirect policy applied to outbound HTTP requests (surrealdb/core/src/fnc/util/http/mod.rs): the NetTarget for the redirect destination is built from url.host_str() alone and url.port() is dropped. The capability matcher (surrealdb/core/src/dbs/capabilities.rs:259-264) refuses to match a port-bearing rule against a port-stripped target (Self::Host(host, Some(port)) => match tgt { _ => false }), so the operator's port-scoped deny rule silently does not fire on the redirect target.

Impact

The impact of this vulnerability is circumvention of the --deny-net capability when the operator has scoped deny rules by port, and the resulting impact on systems external to SurrealDB. The ultimate impact is dependent on the deployment scenario.

For example, if a SurrealDB operator uses --deny-net <host>:<port> to block specific internal services (such as a local Redis at 192.168.1.1:6379 or an unauthenticated cloud metadata service) while leaving the rest of the host reachable, an authenticated principal that can call http::* and host an attacker-controlled redirect target can reach the blocked service and act on whatever interface it exposes.

Bounded to:

• Principals already permitted to call http::*.
• Capability configurations that scope deny rules by port. Host-only rules (--deny-net <host>) are not affected because the host-only rule arm of the matcher accepts port-stripped targets.

Patches

The redirect policy now constructs the NetTarget for the redirect URL with url.port() included, so port-specific deny rules apply to redirect targets identically to initial requests.

A new integration regression test (function_http_redirect_to_denied_port_blocked) uses two wiremock servers to verify the redirect target is blocked and the denied server receives no requests.

Versions 3.1.0 and later are not affected.

Workarounds

• Replace port-specific deny rules with host-only deny rules where feasible (--deny-net 192.168.1.1 instead of --deny-net 192.168.1.1:6379). Host-only rules match port-stripped targets, at the cost of denying every port on that host.
• Disable http::* for untrusted principals (--deny-funcs 'http::*') where the functions are not required.
• Terminate outbound HTTP requests at a reverse proxy that enforces port-specific access controls.

A record user could read records the table's SELECT permission expression should have hidden, when that expression referenced $value, $before, $after, or $event. Binding a chosen value to that name before registering a LIVE SELECT caused notifications to evaluate the permission against the attacker's input instead of the real document.

Impact

A record user binds a value to $value, $before, $after, or $event (e.g. LET $value = [$auth.id]) and registers LIVE SELECT * FROM person. The captured value shadows the real document at notification time, so a SELECT permission like WHERE $auth.id.id() IN $value passes for every record on the table — the subscriber receives notifications for records they should not see.

Read-only impact, bounded to one table. Permission expressions that reference only field names, $auth, or $session are unaffected.

Patches

A patch has been introduced that re-orders the LIVE notification parameter binding so captured user variables are added first and the trusted document-context and session parameters are added last.

• Versions 3.1.0 and later are not affected by this issue.

Workarounds

Affected users who are unable to update should avoid table-PERMISSIONS and LIVE WHERE expressions that read user-named variables ($value, $before, $after, $event) without also gating on a system-derived field such as the record id.

RELATE creates an edge record between two existing records, and SurrealDB enforces the CREATE permission on the edge table for this operation. When the statement included a SET id = edge:existing clause, however, the new edge's id ended up pointing at an record that was already in storage. Rather than failing because the target already existed — which is what a create operation should do — the storage layer silently overwrote the existing edge. A caller with CREATE permission could therefore replace any existing edge on the table, even without UPDATE permission for that record.

Impact

An authenticated user with CREATE permission on an edge table could overwrite any existing record on that table — including edges they had no UPDATE permission for — by issuing a RELATE whose SET id = … resolved to the target record's id. The attack is integrity-only.

Patches

A patch has been introduced that adds an explicit Statement::Relate arm using put_record instead of set_record when the create path is selected. Conflicting writes now return a RecordExists error.

• Versions 3.1.0 and later are not affected by this issue.

This is a behaviour change for applications that relied on RELATE … SET id = … to silently replace existing edges; after the patch those calls return RecordExists instead. Applications that need "create or replace" semantics should use UPSERT (which is correctly permission-gated for the update half).

Workarounds

The defect only fires when the RELATE statement includes a SET id = … clause that resolves to an existing edge id. Applications that let SurrealDB auto-generate the edge id (the default — RELATE a:1 -> edge -> b:1 SET <data> with no id override) are not affected, because auto-generated ids do not collide with existing records.

Where applications must use SET id = … (for example, to produce deterministic edge ids for idempotency), they should first verify that no record with the target id exists before issuing the statement, or restrict CREATE permission on the edge table to principals trusted with UPDATE on the same table.

SurrealDB lets callers modify records using JSON Patch operations via the UPDATE … PATCH statement (and SDK equivalents such as db.patch()). One of those operations is copy, which duplicates one field's value into another field of the same record. A PATCH with an empty from — for example, UPDATE thing:1 PATCH [{ op: 'copy', from: '', path: '/leak' }] — was treated as "copy the entire record" and duplicated every field, including fields the caller has no permission to read, into the destination field the caller chose. The permission filter that hides protected field values from the response only knew to hide the original protected field names, not the new destinations, so the protected values were returned to the caller intact under the new field name.

Impact

An authenticated user with permission to issue UPDATE … PATCH against a record could read the values of any field on that record, regardless of field-level PERMISSIONS FOR select restrictions. The leak is confidentiality-only, and bounded to the fields of the single record the caller targets per PATCH request — it does not expose other records on the same table or any data outside that record's scope.

Patches

A patch has been introduced that rejects an empty from pointer at parse time for both copy and move operations.

• Versions 3.1.0 and later are not affected by this issue.

Workarounds

Affected users who are unable to update should restrict UPDATE … PATCH to callers who already hold SELECT permission on every field of the target record — for them, the bug exposes nothing they can't already read. Otherwise, switch the mutation to an explicit SET or MERGE clause, which removes the attack surface since neither form accepts JSON Patch operations.

A record user with UPDATE access could read field values that field-level SELECT permissions hid from them. Arithmetic operators and extend embedded the raw operand into their error messages, and UPDATE permission checks evaluate against the unreduced document — so triggering such an error against a hidden field returned its value in the resulting error.

Impact

A record user issues an UPDATE that performs an incompatible operation against a hidden field — e.g. UPDATE person:me SET probe = email + 1 when email is a string — and reads the value from the returned error (Tried to compute "alice@example.com" + 1 …). One field per operation, but the attacker can repeat against any field on any record they can UPDATE.

Patches

A patch has been introduced that replaces the raw operand in every try_* operator and in extend with the operand's type name ("string", "int", "array", etc.).

• Versions 3.1.0 and later are not affected by this issue.

Workarounds

Affected users who are unable to update should not grant UPDATE permission on records whose field-level SELECT permissions are expected to hide values from the same caller.

A LIVE SELECT subscription records the user's auth state ($auth, $token, $session, $access) when it is registered, and the server uses that recorded state to evaluate the table- and row-level PERMISSIONS clauses for every subsequent notification. The recorded state is never refreshed.

When something changes the user's effective auth state — the originating session is invalidated, the session's TTL expires, or the user signs in, signs up, or authenticates as a different identity on the same connection — the subscription keeps delivering notifications under the old, stale auth state, and the PERMISSIONS that should now apply to the connection are never consulted.

Impact

A user whose session has been revoked, expired, signed out of, or re-authenticated on the same connection continues to receive real-time notifications evaluated against the prior principal. The attacker does not gain access to new resources — only continued access to resources the prior principal was already permitted to read — but that continued access persists past the point the principal change should have ended it, and persists indefinitely until the originating connection is closed.

This is confidentiality-only: the dispatcher does not enable writes evaluated under the stranded principal.

Patches

• invalidate() and TTL expiry — RpcProtocol::invalidate now calls cleanup_lqs(session_id) after clearing the session, dropping every LIVE owned by the now-invalidated session. The notification dispatcher additionally reads the originating session's exp and skips delivery once it has passed, closing the TTL-expiry leg without requiring the Session object to remain in memory.
• Principal change on signin / signup / authenticate / refresh — each of these RPC methods now snapshots the session's auth principal (Auth::id() + Auth::level()) before mutating the session and, if the principal has changed after the operation, calls cleanup_lqs(session_id). Token refresh against the same identity is therefore preserved; identity change tears stranded subscriptions down.

Versions 3.1.0 and later are not affected by this issue.

Workarounds

For unpatched versions, clients should call reset() (which tears down all LIVE queries owned by the session) or kill each outstanding live query ID before signing out, signing in as a different identity, or signing up on an existing connection. There is no client-side workaround for the TTL-expiry leg; deployments concerned about it should restrict DURATION FOR SESSION on access methods that have permission to register LIVE queries.

An anonymous caller could degrade /sql availability by streaming WebSocket frames many times larger than the operator-configured per-connection limit. The /sql upgrade handler accepted anonymous connections and did not propagate SURREAL_WEBSOCKET_MAX_MESSAGE_SIZE to the WebSocket protocol layer — incoming bytes accumulated in the per-connection read buffer before check_anon could reject the query, so the memory cost was incurred regardless of whether the caller could ever execute SurrealQL. The same upgrade path also silently ignored --deny-http sql and --deny-arbitrary-query * for authenticated callers, but that secondary effect does not grant new permissions.

Impact

SURREAL_WEBSOCKET_MAX_MESSAGE_SIZE is not applied to anonymous /sql connections, so each connection can buffer up to the WebSocket library defaults (16 MiB per frame, 64 MiB per reassembled message) of in-flight bytes regardless of the operator's configured limit. Holding this much memory pinned requires actively streaming bytes into the connection, so an attacker has to maintain bandwidth across many concurrent connections to consume meaningful memory. Within that constraint the result is degraded availability for legitimate /sql clients; on memory-constrained deployments the process may be OOM-killed and restarted during the attack rather than denied service outright.

Separately, --deny-http sql and --deny-arbitrary-query * were not enforced on the WebSocket, so SurrealQL operations the operator had configured to refuse could still be issued by any authenticated principal that already held the corresponding data permissions. This is a configuration-correctness defect — the bypass does not grant new permissions.

Patches

A patch has been introduced that performs the two capability checks before calling on_upgrade and applies the same per-connection size limits used by /rpc. The capability checks enforce the operator's configured deny flags; they do not change what any authenticated principal is permitted to do.

• Versions 3.1.0 and later are not affected by this issue.

Workarounds

Affected users who are unable to update should refuse GET /sql requests carrying Upgrade: websocket at a reverse proxy, or apply per-connection frame size limits at the reverse proxy.

The KILL statement is used to terminate LIVE SELECT subscriptions that capture real-time changes to data within a table. The KILL statement implementation in core/src/expr/statements/kill.rs verifies that the requesting user has database-level access, but does not verify that the requesting user is the owner of the live query being terminated.

After passing the valid_for_db() check, the KILL statement resolves the live query UUID, looks up the corresponding live query entry, and immediately deletes it without comparing the requesting user's identity against the live query owner. This allows any authenticated user with database-level access to terminate any live query in that database, regardless of who created it.

The affected user's real-time subscription silently stops receiving updates with no notification that the live query was terminated. The same attack works across privilege levels: a low-privilege record-scoped user can terminate a root user's monitoring live queries.

This issue was discovered and patched during a code audit and penetration test of SurrealDB by cure53, the severity defined within cure53's preliminary finding is Medium, matched by our CVSS v3.1 assessment.

Impact

An authenticated user with database-level access can terminate any other user's live query subscriptions within the same database by issuing a KILL statement with the target live query's UUID. This impacts availability by silently disrupting real-time data subscriptions and breaks multi-tenant isolation guarantees.

The attack requires knowledge of the target live query UUID. Live query UUIDs are randomly generated, but may be exposed through application logs, shared monitoring dashboards, or other information disclosure vectors.

Patches

An ownership verification check has been introduced in the KILL statement implementation that compares the requesting user's authentication context against the owner of the live query before allowing deletion.

• Versions 3.1.0 and later are not affected by this issue.

Workarounds

Users unable to upgrade should consider the following mitigations:

• Ensure that live query UUIDs are treated as sensitive values and are not exposed to other users through application logs, error messages, or shared interfaces.
• Where multi-tenant isolation is critical, use separate databases per tenant rather than relying on record-level access controls within a shared database.
• Monitor for unexpected termination of live queries in application logic and implement reconnection and re-subscription mechanisms.

A LIVE query whose WHERE clause evaluates to an error caused the source data modifier (the user creating, updating, or deleting a record on the watched table) to fail instead. Calling any arbitrary SurrealQL function with a typed parameter and passing a value of the wrong type — for example LIVE SELECT * FROM t WHERE string::trim(deny) — triggered an evaluation error inside the LIVE notification path. That error then propagated through to the triggering write, rolling back the attempted change.

While such a LIVE query was registered, all CREATE, UPDATE, and DELETE operations on the watched table failed — including those issued by a root user — for as long as the registration remained active. Registering the LIVE required select permission on the table; no other permission on the table was needed.

Impact

An authenticated user with select permission on a table can prevent all CREATE, UPDATE, and DELETE operations on that table — by any other user, up to and including root — for the lifetime of a single registered LIVE query. Service is restored when the LIVE query is killed or the session that registered it ends.

Patches

A patch has been introduced that:

1. Decouples LIVE query evaluation errors from the source transaction — when lq_check returns an error during the LIVE notification path, the error is now reported to the LIVE subscriber as an Action::Error notification and the LIVE processing path returns Ok(()). The triggering write proceeds normally.
2. Defers the error notification until after the permission check — the Action::Error notification is only delivered after the LIVE subscription's PERMISSIONS clause has been evaluated, so unauthorised subscribers do not learn even that an error occurred (closing an information-disclosure side channel introduced by the first part of the fix).

• Versions 3.1.0 and later are not affected by this issue.

Workarounds

Users unable to upgrade should restrict the ability of untrusted users to register LIVE queries by removing the select permission on tables they want to keep writeable, or by gating LIVE registration at the application layer.

An authenticated user could bypass permission rules that gated access on parts of a record's id — most commonly tenant-isolation rules of the form PERMISSIONS FOR select WHERE id.tenant = $auth.id.tenant. The same defect also let UNIQUE constraints defined on parts of an id admit duplicate entries.

When a query referenced part of a composite record id (id.tenant, id.uid, …), SurrealDB read the value from the record's editable body fields instead of from the immutable id key. Because the body is editable but the id is fixed at creation, an attacker with write access could set the body field to any value and have permission checks read that spoofed value.

Impact

What an attacker can do:

• Read records hidden by permission rules of the form id.<field> = $auth.<...> (typically tenant- or scope-isolation boundaries) by writing the same-named field on a record they control to the spoofed value.
• Cause UNIQUE constraints defined on id.<field> to silently admit duplicate entries, leaving the database with rows that violate the constraint.

What it can't do:

• Cross namespace or database isolation boundaries. -Bypass field-level PERMISSIONS FOR update clauses that don't reference id.<field> paths.
• Affect availability or crash the server.

Patches

The value-path resolver now special-cases Part::Field and Part::Value against RecordIdKey::Object, reading the named component directly from the id key without ever entering select_document. The Array-keyed special case (id[0], id[1], …) is unchanged.

• Versions 3.1.0 and later are not affected.

Workarounds

Users unable to patch are advised to consider the following workarounds:

• Avoid permission expressions that read id.<field> on Object-keyed record ids; gate on the full record id (id = $auth.id) or on a server-derived session value instead.
• Avoid UNIQUE indexes on id.<field> until 3.1.0; use DEFINE INDEX ... ON FIELDS id UNIQUE (the full id) where possible.

An authenticated record or scope user could read records on any table reachable through a graph edge or REFERENCES TO back-reference, regardless of that table's PERMISSIONS FOR select clause.

Traversing SELECT * FROM source->edge->target returned full documents from target even when target was defined as PERMISSIONS FOR select NONE. The same bypass extended through multi-hop chains, so any table reachable by a sequence of edges from a readable starting point was exposed.

The root cause: GraphEdgeScan and ReferenceScan fetched records straight from storage without routing them through Document::pluck_select, so the target table's permission expression was never consulted.

Impact

An authenticated record or scope user can read records on any table reachable through a chain of graph edges or back-references from a table they have select on, regardless of the target's PERMISSIONS FOR select clause. Confidentiality-only and bounded to the caller's current database — namespace and database isolation are unaffected.

Patches

A new per-batch permission cache (exec::permission::CachedTableSelect) resolves each target table's SELECT permission once and filters yielded values through check_permission_for_value, matching the regular SELECT code path.

• Versions 3.1.0 and later are not affected.

Workarounds

• Remove select permission on edge tables whose targets should be hidden.
• Use namespace or database isolation as the primary boundary where feasible.

A vulnerability was discovered where the user-supplied WHERE clause in a SELECT statement is evaluated against the full record data before PERMISSIONS FOR SELECT WHERE determines whether the principal is authorised to access that record. A side-effecting expression in the WHERE clause can exfiltrate record contents before the permission check runs. The same ordering bug affects the SET, MERGE, CONTENT and PATCH clauses of update-variant statements (UPDATE, UPSERT-update, INSERT ON DUPLICATE KEY UPDATE, RELATE-update).

This vulnerability is confined to the attacker's current database. It does not cross namespace or database isolation boundaries.

Impact

An authenticated user — including Record and Scope users — can read the full contents of any table in the database they are authenticated against, bypassing PERMISSIONS FOR SELECT WHERE restrictions on those tables.

The most direct exfiltration method requires scripting functions to be enabled (--allow-scripting / -A). However, exfiltration via SurrealQL's THROW statement is also feasible without scripting functions, and timing-based side-channel extraction is possible in all configurations.

All tables within the attacker's current database, regardless of table-level PERMISSIONS FOR SELECT WHERE restrictions on those tables, are vulnerable to this attack. Tables in other databases within the same namespace, or within other namespaces, are not vulnerable.

Patches

A patch has been introduced that runs check_permissions_table before any user-supplied expression is evaluated against the record. A new check_pre_update helper centralises this ordering on every update-variant code path. Regression tests covering WHERE, SET, MERGE, CONTENT, INSERT ON DUPLICATE KEY UPDATE, and RELATE with THROW side-effects are included.

• Versions 3.1.0 and later are not affected by this issue.

Workarounds

Affected users who are unable to update may want to:

• Disable scripting functions if not required — remove the -A / --allow-scripting flag. This blocks the most direct exfiltration method but does not fully mitigate the vulnerability, as THROW-based and timing-based exfiltration remain possible.
• Limit query access — restrict the ability of untrusted principals to run arbitrary SELECT queries with user-controlled WHERE clauses.
• Use namespace/database isolation instead of table-level permissions as the primary security boundary where feasible, since the vulnerability is in table-level permission enforcement, not namespace or database isolation.

The SurrealDB type/kind parser did not enforce the configured recursion depth limit when parsing nested type annotations. The expression parser already enforced the limit for analogous constructs; the kind parser omitted it. An authenticated attacker could send a query with deeply nested type annotations (e.g., array<option<array<option<...>>>>) and exhaust server memory, crashing the process.

This is an incomplete fix for GHSA-6r8p-hpg7-825g, which addressed the same class of bug in the expression parser but did not cover the kind/type annotation parser code path.

Impact

An authenticated user with query execution privileges can crash a SurrealDB server with a single WebSocket message containing deeply nested type annotations.

Patches

A patch has been introduced that wraps parse_concrete_kind and the OPTION<...> arm of parse_inner_kind with enter_object_recursion!, bounding the recursive cycle parse_concrete_kind → parse_inner_kind → parse_inner_single_kind → parse_concrete_kind at the configured object_recursion_limit (default 100). Regression tests cover both cast and DEFINE FIELD paths.

• Versions 3.1.0 and later are not affected by this issue.

Workarounds

Restrict the ability of untrusted users to execute arbitrary queries via the --deny-arbitrary-query capability flag for the affected user classes (guest, record, or system). Disabling untrusted access to the WebSocket /rpc endpoint also prevents exploitation; the HTTP /sql endpoint's 1 MiB body limit constrains nesting to a depth where OOM is not feasible.

A single unauthenticated WebSocket message to /rpc crashed the SurrealDB server. Sending use { db: "x" } without first selecting a namespace hit .expect("namespace should be set") in the use handler; because surrealdb-core is built with panic = 'abort', the panic terminated the process. use is callable before signin, and the per-method capability check passes by default for guest callers — so no credentials, token, or --allow-guests flag are required.

Impact

An unauthenticated remote attacker who could reach the /rpc endpoint could crash the SurrealDB server with a single WebSocket message. No credentials, token, session knowledge, or capability are required.

Patches

A patch has been introduced that returns a typed invalid_params response when db is set on a session with no ns, replacing the panic.

• Versions 3.1.0 and later are not affected by this issue.

Workarounds

Affected users who are unable to update should restrict network access to the /rpc endpoint to trusted clients, and run SurrealDB under a process supervisor that restarts on crash.

The SurrealDB value and JSON parser did not enforce the configured recursion depth limit when parsing nested {, [, or ( tokens. The expression parser already enforced the limit for these tokens; the value/JSON parser omitted it. An unauthenticated attacker could send a deeply nested JSON payload to the WebSocket /rpc endpoint and exhaust server memory, crashing the process.

This is an incomplete fix for GHSA-6r8p-hpg7-825g, which addressed the same class of bug in the expression parser but did not cover the value/JSON parser code path.

Impact

An unauthenticated remote attacker can crash a SurrealDB server with a single WebSocket message. No credentials or query execution privileges are required.

Patches

A patch enforces the configured recursion depth limit in parse_value and parse_json, bringing them in line with the rest of the parser.

• Versions 3.1.0 and later are not affected by this issue.

Workarounds

Restrict network access to the WebSocket /rpc endpoint to trusted clients.

The HTTP /rpc endpoint has a time-of-check/time-of-use (TOCTOU) race condition on internal session state. When authenticated and unauthenticated requests are processed concurrently, the unauthenticated request can inherit the authenticated user's session and privileges. The /rpc endpoint is the primary interface used by all official SurrealDB SDKs.

The HTTP /rpc handler does not bind each incoming request to an isolated session context. Instead, concurrent requests share mutable authentication state. When an authenticated request sets the session context and an unauthenticated request races in before it is cleared, the unauthenticated request executes with the authenticated user's privileges.

The impact depends on the privilege level of the session that is hijacked. If a root or namespace-level user session is inherited, the attacker can read and modify any data, delete records, and create persistent namespace-level users. If a scoped record user session is inherited, the attacker is limited to that user's permissions.

The attack requires no credentials, tokens, or session knowledge — only the ability to send concurrent HTTP requests to the /rpc endpoint while legitimate authenticated traffic is active.

Impact

An unauthenticated attacker who can reach the /rpc endpoint can escalate privileges by racing against any active authenticated session. The severity of the impact depends on the permissions of the user whose session was hijacked. This could include escalation to root user of SurrealDB instance

Patches

Versions prior to SurrealDB v3.1.0 are vulnerable.

A patch has been introduced that replaces the shared default session with per-request session isolation. Every POST /rpc request now allocates a fresh, server-side UUID and runs entirely within that session's scope for the duration of the request. The session-map signatures across the RPC protocol have been changed from Option<Uuid> to Uuid so the "default session" can no longer be represented at the type level, preventing future regressions of the same shape.

Workarounds

There is no configuration-level mitigation that fully addresses this vulnerability. Network-level controls restricting access to the /rpc endpoint to trusted clients can reduce exposure.

The HTTP /rpc sessions method returned every attached session UUID without authentication, and the /rpc handler accepted an arbitrary session field with no ownership check. An anonymous caller could enumerate UUIDs and impersonate any authenticated session.

"Attached" means sessions registered via {"method":"attach"} — the only writer to the HTTP session map. Ordinary stateless /rpc requests use ephemeral per-request sessions that are filtered from sessions() and destroyed at end-of-request, so they are not enumerable.

Exposure

• Exposed: clients that issue attach, notably the official Rust SDK's Http/Https engine (auto-attaches once per Surreal handle).
• Not exposed: REST endpoints (/sql, /key, /signin, /export, etc.); WebSocket /rpc (per-connection scope, attach refused); embedded / MCP usage; ad-hoc POST /rpc callers that never attach.

Impact

For each attached and authenticated session, an unauthenticated attacker can read, write, and delete any data the session can reach, dump metadata, invalidate sessions, and escalate to that session's privilege level (up to root). An attached session that has not yet authenticated is Level::No and confers no privilege.

Patches

1. HTTP sessions() now returns method_not_allowed. WebSocket retains per-connection enumeration.
2. The HTTP /rpc handler gates client-supplied session IDs against the caller's request-level auth principal (actor id + level); mismatches return session_not_found.
3. Attached HTTP sessions are capped via SURREAL_HTTP_MAX_ATTACHED_SESSIONS.

Versions 3.1.0 and later are not affected.

Workarounds

No configuration-level mitigation fully addresses this. For Users unable to upgrade:

• Avoid SDKs and client flows that call attach against HTTP /rpc (notably the Rust SDK's Http/Https engine). Prefer the WebSocket transport, or REST endpoints (/sql, /signin, /key, /export) which never populate the attached-session map.
• Restrict /rpc to trusted clients at the network layer.

An authenticated user could crash a SurrealDB server with a single query containing a long chain of operators.

Such a query — for example RETURN 1 + 1 + 1 + ... with tens of thousands of terms — is parsed into an expression tree one level deep per operator. Because the chain is flat and the pratt parser appends to it iteratively, the configured query- and object-recursion limits never fire, so the tree grows unbounded with the length of the query.

The root cause: the over-deep tree is later walked recursively, one call per node, when it is dropped, formatted, or lowered for execution — overflowing the thread stack and aborting the process.

Impact

An authenticated user with query-execution privileges can crash a SurrealDB server with a single query containing a long chain of operators. The whole process aborts, denying service to every namespace and database on that instance until it is restarted. The crash occurs during query processing, before any data is read or written (availability only).

Patches

A patch introduces a dedicated expression-depth budget — expr_recursion_limit, sourced from max_expression_parsing_depth (default 128, configurable via SURREAL_MAX_EXPRESSION_PARSING_DEPTH). It is charged once per pratt-parser level and once per operator appended to the spine, so an over-deep operator chain is rejected with a syntax error instead of building a tree that overflows the stack downstream. Paths that re-parse already-validated stored data are exempted, so existing databases with deep stored expressions still load.

• Versions 3.1.5 and later are not affected by this issue.

Workarounds

Users unable to patch should consider the following workarounds:

• Restrict the ability of untrusted users to execute arbitrary queries via the --deny-arbitrary-query capability flag for the affected user classes (guest, record, or system).
• Restrict untrusted access to the WebSocket /rpc endpoint, which accepts larger request bodies than the HTTP /sql endpoint. The /sql endpoint's 1 MiB body limit lowers the achievable operator depth but does not by itself guarantee the stack cannot be exhausted.
• Run SurrealDB under an orchestrator or process manager that restarts it automatically on exit (e.g. Kubernetes, systemd Restart=on-failure, or a Docker restart policy), so the server recovers immediately after a crash. This limits downtime from a successful attack but does not prevent the crash.

References

• SurrealQL Documentation — Operators
• fix(syn): bound expression operator-tree depth to prevent stack-overflow DoS

A field can be hidden from a user with a field-level SELECT permission (DEFINE FIELD code ON secret PERMISSIONS FOR select WHERE owner = $auth.id). When that field is indexed, a record user who cannot read it could still recover the relative ordering of its values across every record by issuing ORDER BY <field>: the field came back null as intended, but the rows were returned in the hidden values' true sorted order.

To satisfy the sort, the planner selects the field's index and walks it in value order; the field-level permission is applied later, when the row is projected, so the value is nulled but the row order already encodes it. The guard that withholds restricted fields from the WHERE path was never applied to ORDER BY.

Impact

What an attacker can do:

• As a record (scope) user with table SELECT, learn the relative ordering of a field hidden by a field-level SELECT permission, across other users' records, by ordering on it when an index covers the field — the value returns null, but the rows come back in the hidden values' order.
• With rows they control in the same table, use that ordering to narrow the hidden values toward exact ones.

What it can't do:

• Read the field value directly — only its relative ordering leaks; the projected value is correctly redacted.
• Cross table, record, or namespace/database boundaries — the table's SELECT permission and any row-level WHERE are still enforced, so only records the caller may already read are ordered.
• Leak anything when the restricted field is not indexed, affect root or record-owner sessions, or modify data (confidentiality only).

Patches

The query planner now applies the field-permission guard to the ORDER BY clause as well as the WHERE clause. When an ordered field is hidden from the caller by a field-level SELECT permission, the index sort pushdown is withheld and the rows are sorted after redaction instead, so the row order no longer reflects the hidden values. The dynamic-scan fallback is closed the same way, and a regression test was added.

The fix is included in SurrealDB 3.1.5.

Workarounds

Users unable to upgrade are advised to consider the following:

• Force the legacy executor with SURREAL_PLANNER_STRATEGY=compute-only; the sort then runs after redaction, so no ordering leaks.
• Do not place an index on a field whose values are hidden by a field-level SELECT permission — without the index the leak does not occur.
• Do not rely on field-level SELECT permissions to hide values on indexed fields from record users; restrict at the table level instead.
• Use namespace / database isolation as the primary trust boundary where feasible.

References

• SurrealQL Documentation — DEFINE FIELD
• SurrealQL Documentation — DEFINE INDEX
• SurrealQL Documentation — DEFINE TABLE … PERMISSIONS
• Related advisory (same class, indexed COUNT variant): GHSA-c8jx-96c9-8xrp
• fix(planner): prevent ORDER BY value-ordering oracle on restricted SELECT fields
• fix(planner): close ORDER BY value-ordering oracle on the DynamicScan fallback

Acknowledgements

Thanks to George Chen (@geo-chen) for finding and reporting this issue.

SurrealDB's full-text search lets you define a text analyzer whose mapper filter loads a term-mapping file from disk (DEFINE ANALYZER ... FILTERS mapper('<path>')). A database user with the EDITOR or OWNER role could point that filter at any file the SurrealDB process can read and have its content returned in the query's error message.

File access is meant to be restricted by the SURREAL_FILE_ALLOWLIST setting, but an empty allowlist applied no restriction at all — and empty is the default.

Impact

The file is read with the privileges of the SurrealDB process, so a database EDITOR or OWNER user can disclose the contents of any file the process can access. Only the first line of the file is returned, except for files with no newlines.

However recovering the process's command line and environment could expose startup root credentials (--user / --pass) and secret environment variables, escalating a single-database role toward full control of the instance.

The read on the underlying filesystem is bounded by what the SurrealDB process can reach — any file readable by the OS user it runs as — so the impact scales with how the process is run and what is mounted into it.

Patches

A patch has been included in SurrealDB 3.1.5.

File access is now secure by default. check_is_path_allowed denies every path when no SURREAL_FILE_ALLOWLIST is configured, so the mapper filter cannot open any file unless the operator has explicitly allowed its directory. Analyzer parse errors no longer include the contents of the mapped file, only the line number.

Workarounds

Users unable to upgrade are advised to consider the following:

• Set SURREAL_FILE_ALLOWLIST to a directory that contains only the intended mapping files; this confines the mapper filter to that path. On affected versions the allowlist must be non-empty to have any effect.
• Grant the EDITOR and OWNER database roles only to trusted principals.
• Avoid supplying secrets — including the root credentials — on the command line or through environment variables; prefer mounted files with least-privilege permissions.

References

• SurrealQL Documentation — DEFINE ANALYZER
• SurrealDB Documentation — Capabilities
• Related earlier advisory: GHSA-2cvj-g5r5-jrrg local file read of 2-column TSV files via analyzers
• https://github.com/surrealdb/surrealdb/pull/5600
• fix(iam): deny filesystem access by default and stop leaking file content in analyzer errors

Acknowledgements

Thanks to Jan Kahmen (@kah-ja) for finding and reporting this issue.

SurrealDB fetches the JWKS document for a JWT or record access method using a bare reqwest client that follows HTTP redirects by default. The network capability check in core/src/iam/jwks.rs (check_capabilities_url) is applied only to the originally configured URL; redirect targets are not re-validated. An --allow-net-permitted JWKS host that returns a 3xx Location can therefore redirect the request to an address the allowlist was meant to block, resulting in a server-side request forgery (SSRF). The protected HttpClient used by http::* functions re-checks every redirect hop and was hardened in 3.1.0, but the JWKS fetcher uses its own client and was not covered.

Impact

What an attacker can do:

• With the Owner role at database level or above (the minimum required to run DEFINE ACCESS ... TYPE JWT URL or TYPE RECORD ... WITH JWT URL), point an access method at an allowlisted host they control and redirect the server's GET to an otherwise-blocked target — cloud metadata, loopback, internal services — bypassing --allow-net/--deny-net.
• Infer the existence and liveness of internal hosts and ports from response-timing differences (bounded by the 1-second fetch timeout).

What it can't do:

• Read the response: the fetch is blind — the body is only parsed as a JWKS, and a non-JWKS response surfaces as an opaque InvalidAuth error. Nothing is returned to the caller.
• Modify data or affect availability (a single GET request).

Patches

The JWKS fetcher now applies a redirect policy that re-validates every redirect target against the configured network capabilities (mirroring check_capabilities_url) and caps redirects at max_http_redirects.

• Versions prior to 3.1.5 are vulnerable.

Workarounds

• Restrict the Owner role to trusted operators.
• Enforce egress filtering at the network layer (block link-local 169.254.0.0/16 and internal ranges) so redirect targets are unreachable regardless of in-process checks.
• Configure access methods to use only trusted JWKS hosts that do not redirect, or use locally defined keys instead of a remote JWKS.

References

• SurrealDB Documentation — Capabilities
• SurrealQL Documentation — DEFINE ACCESS
• fix(iam): prevent SSRF in JWKS fetch by re-validating redirect targets

An authenticated user scoped to one namespace/database could invoke a custom API (DEFINE API) belonging to a different namespace/database, reaching another tenant's endpoint.

The route /api/{namespace}/{database}/{endpoint} took the namespace and database from the URL and applied them to the caller's session before the endpoint was looked up or run, without checking that the caller's authenticated scope covered them. Because a custom API handler runs with permissions disabled (definer's rights), the endpoint's own PERMISSIONS clause was the only gate — open to everyone for a PERMISSIONS FULL endpoint. The api::invoke() function was affected the same way, resolving against the session's selected namespace/database (settable via the surreal-ns / surreal-db headers or USE).

Impact

What an attacker can do:

• With valid credentials for any one namespace/database (a VIEWER is enough), invoke a custom API in another namespace/database by naming the victim scope in the URL.
• Read data that endpoint returns — including from PERMISSIONS NONE tables, since the handler runs with permissions disabled — or trigger any writes and side effects it performs.

What it can't do:

• Reach a scope without valid credentials for some namespace/database on the instance; this is not an unauthenticated bypass.
• Affect single-tenant deployments, or any deployment where callers already hold instance-wide (root) scope.

Patches

The namespace/database is now validated against the caller's authenticated level — which the request cannot change — before the endpoint is resolved or run. A target scope outside that level is rejected with 403 Forbidden, both at the HTTP entry point and at the dispatch step shared with api::invoke(). Root reaches any scope; namespace principals their namespace; database and record principals their exact namespace/database; anonymous callers remain governed by the endpoint's PERMISSIONS.

• Versions 3.2.0 and later are not affected by this issue.

Workarounds

Users unable to patch should consider the following workarounds:

• Disable the custom API HTTP route via capabilities where it is not required.
• Treat separate deployments, not namespace/database boundaries, as the tenant isolation boundary on shared instances.
• Prefer a PERMISSIONS WHERE clause that checks the authenticated identity over PERMISSIONS FULL (reduces exposure but does not restore the boundary).

Resources

• SurrealQL Documentation — DEFINE API
• SurrealDB Documentation — Capabilities
• fix(core/api): reject cross-tenant custom API access (included in SurrealDB 3.2.0)

Acknowledgements

SurrealDB thanks sondt99 for reporting this issue.

A SELECT permission defined on an array element (DEFINE FIELD field.* … PERMISSIONS FOR select …) is not enforced correctly for RECORD users. Instead of hiding the denied elements, the query leaks a subset of them: a deny-all returns the odd-indexed elements, and a per-element predicate keeps and drops the wrong ones.

The filter removed each denied element by index while walking the array forwards. Because removing an element shifts every later index down, each cut invalidated the indices still pending in the loop, leaving denied elements behind. Field-level permissions are enforced correctly; only the element (field.*) level is affected, and only for record users — root and record-owner sessions are not.

Impact

What an attacker can do:

• As a record (scope) user, read array elements that an element-level (field.*) SELECT permission should hide, on any table they can already SELECT.
• Recover denied elements through both a deny-all and a WHERE predicate — the wrong elements are selected either way.

What it can't do:

• Bypass field-level SELECT permissions, which are evaluated correctly.
• Affect root or record-owner sessions, or cross namespace/database isolation.
• Modify data, escalate privileges, or affect availability (confidentiality only).

Patches

The three permission-filtering paths (doc/reduce.rs, doc/output.rs, exec/operators/scan/pipeline.rs) now remove denied elements in reverse index order, so removing one element no longer shifts the elements still to be checked. Regression tests reproducing the issue were added.

The fix is included in SurrealDB 3.1.4.

Workarounds

• Do not rely on element-level (field.*) permissions to hide data from record users; use field-level permissions, which are enforced correctly.
• Restrict record users from selecting tables whose schema uses element-level permissions.

Resources

• DEFINE FIELD
• USERS
• DEFINE TABLE … PERMISSIONS
• fix(sec): stop array element-level SELECT permissions leaking elements (commit 8f89b260b)

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.

When a user configures ALGORITHM ES512 for any JWT access method (DEFINE ACCESS ... TYPE JWT ALGORITHM ES512), SurrealDB silently substitutes ES384 at all four internal algorithm conversion points. This occurs because the underlying jsonwebtoken crate (v10.x) does not include an ES512 algorithm variant, so the mapping defaults to ES384 without raising an error, warning, or log message.

Users who provide the correct P-521 key type for ES512 will experience authentication handshake failures due to the curve mismatch with ES384 (which expects P-384).

Impact

Authentication handshake failures when using ES512 with the correct P-521 key type, and when tokens are verified by external systems expecting real ES512 signatures.

This vulnerability cannot be exploited to forge tokens or compromise the integrity or confidentiality of data handled by SurrealDB, as ES384 remains cryptographically strong.

Patches

Versions prior to SurrealDB v3.1.0 are vulnerable.

The patches for SurrealDB v3.1.0 block new DEFINE ACCESS statements using ALGORITHM ES512 with a clear error message and add deprecation warnings at runtime for existing stored ES512 definitions.

Workarounds

Users should reconfigure affected JWT access methods to use a supported algorithm such as ES384 (with a P-384 key pair) or another supported algorithm. Review any DEFINE ACCESS statements specifying ALGORITHM ES512 and update them accordingly.

A record user could learn the value of a hidden field by counting how many records match a guess.

When DEFINE FIELD ... PERMISSIONS FOR select WHERE ... hides a field's contents from a caller, and that field is indexed, running SELECT count() FROM t WHERE hidden_field = "guess" GROUP ALL returned a count greater than zero whenever a record actually had that value — even though the caller was never allowed to read the field directly. The query planner used an indexed-COUNT shortcut (Index::Count, IndexCountScan, or the legacy Iterate Index Count / Iterate Index Keys paths) that counts matching index entries and skips the permission check that would normally hide the value. The same query with WITH NOINDEX correctly returned [], confirming the gap.

By repeating the count query with different guesses, an attacker can confirm or recover the contents of any restricted field they could not read through a normal SELECT.

Impact

What an attacker can do:

• Confirm or recover values of a field protected by field-level SELECT permissions on any table they hold table-level SELECT on, provided the field is indexed.
• Repeat the query with different guesses to read restricted field contents one value at a time.

What it can't do:

• Read fields that are not indexed (the shortcut only fires when an index covers the predicate column).
• Cross table, database or namespace isolation boundaries.
• Modify data, escalate privileges, or affect availability.

Patches

The legacy planner (surrealdb/core/src/idx/planner/tree.rs) and the streaming planner (surrealdb/core/src/exec/planner/select/mod.rs) now both refuse the indexed fast path when the WHERE / ORDER tree references a field governed by a non-Full SELECT permission:

• resolve_indexes skips any B-tree / unique index whose columns are governed by such a permission.
• A new cond_touches_restricted_field flag is propagated; eval_count refuses a dedicated Index::Count when set.
• The streaming planner adds cond_touches_restricted_select_field, a RestrictedIdiomChecker visitor that matches each idiom against the table's field-permission prefixes (loaded via the plan-time txn), and gates IndexCountScan emission on it.
• The fast paths are preserved for root / owner sessions via should_check_perms_for_view.

Versions 3.1.0 and later are not affected.

Workarounds

Users unable to patch are advised to consider the following workarounds:

• Avoid DEFINE INDEX on fields whose values are protected by field-level SELECT permissions. The class of attack is specific to the indexed fast paths.
• Restrict the ability of record users to issue arbitrary SELECT count() … GROUP ALL queries against tables containing field-protected columns.
• Use namespace / database isolation as the primary boundary where feasible.

An anonymous caller could create new namespaces and databases on a running SurrealDB instance without holding DEFINE NAMESPACE or DEFINE DATABASE permission.

USE NS <name> and USE DB <name> automatically create the target when it does not exist. The three places USE is handled — the RPC use method, Datastore::process_use, and the SurrealQL executor — did not check whether the caller was allowed to create the resource. Under default capabilities any session reached this path, including an unauthenticated guest.

Impact

What an attacker can do:

• Create new namespaces and databases without DEFINE NAMESPACE / DEFINE DATABASE permission. An unauthenticated guest is enough under default capabilities.
• Recreate a parent namespace that an operator deliberately dropped, using a stale namespace-Editor token, by running USE NS <dropped> DB anything.
• Exhaust catalog storage by repeatedly creating new resources.

What it can't do:

• Read or modify data inside any pre-existing namespace or database.
• Escalate to root or namespace-owner privileges on existing resources.
• Affect deployments running with auth_enabled=false.

Patches

All three USE entry points now check whether the caller has DEFINE NAMESPACE / DEFINE DATABASE authority before creating a missing target. Sessions still update their context regardless of authorization, so SDKs that send use before signin continue to work — only the catalog creation step is gated. The parent-namespace side-effect path is closed by the same check.

Versions 3.1.0 and later are not affected.

Workarounds

• Set --deny-arbitrary-query * for guest principals to remove the entry point.
• Run with --auth and require all callers to signin before issuing use.
• Revoke namespace-level tokens promptly when a namespace is dropped.

SurrealDB offers http::* functions that can access external network endpoints, with the --allow-net and --deny-net capabilities used to restrict the set of network targets that can be reached. An authenticated user of SurrealDB can bypass a port-scoped --deny-net <host>:<port> rule by chaining an HTTP redirect: the initial request goes to an --allow-net-permitted hostname, the response's 3xx Location header points at the denied host:port, and the redirect is followed even though the destination was explicitly denied.

The root cause is in the redirect policy applied to outbound HTTP requests (surrealdb/core/src/fnc/util/http/mod.rs): the NetTarget for the redirect destination is built from url.host_str() alone and url.port() is dropped. The capability matcher (surrealdb/core/src/dbs/capabilities.rs:259-264) refuses to match a port-bearing rule against a port-stripped target (Self::Host(host, Some(port)) => match tgt { _ => false }), so the operator's port-scoped deny rule silently does not fire on the redirect target.

Impact

The impact of this vulnerability is circumvention of the --deny-net capability when the operator has scoped deny rules by port, and the resulting impact on systems external to SurrealDB. The ultimate impact is dependent on the deployment scenario.

For example, if a SurrealDB operator uses --deny-net <host>:<port> to block specific internal services (such as a local Redis at 192.168.1.1:6379 or an unauthenticated cloud metadata service) while leaving the rest of the host reachable, an authenticated principal that can call http::* and host an attacker-controlled redirect target can reach the blocked service and act on whatever interface it exposes.

Bounded to:

• Principals already permitted to call http::*.
• Capability configurations that scope deny rules by port. Host-only rules (--deny-net <host>) are not affected because the host-only rule arm of the matcher accepts port-stripped targets.

Patches

The redirect policy now constructs the NetTarget for the redirect URL with url.port() included, so port-specific deny rules apply to redirect targets identically to initial requests.

A new integration regression test (function_http_redirect_to_denied_port_blocked) uses two wiremock servers to verify the redirect target is blocked and the denied server receives no requests.

Versions 3.1.0 and later are not affected.

Workarounds

• Replace port-specific deny rules with host-only deny rules where feasible (--deny-net 192.168.1.1 instead of --deny-net 192.168.1.1:6379). Host-only rules match port-stripped targets, at the cost of denying every port on that host.
• Disable http::* for untrusted principals (--deny-funcs 'http::*') where the functions are not required.
• Terminate outbound HTTP requests at a reverse proxy that enforces port-specific access controls.

A record user could read records the table's SELECT permission expression should have hidden, when that expression referenced $value, $before, $after, or $event. Binding a chosen value to that name before registering a LIVE SELECT caused notifications to evaluate the permission against the attacker's input instead of the real document.

Impact

A record user binds a value to $value, $before, $after, or $event (e.g. LET $value = [$auth.id]) and registers LIVE SELECT * FROM person. The captured value shadows the real document at notification time, so a SELECT permission like WHERE $auth.id.id() IN $value passes for every record on the table — the subscriber receives notifications for records they should not see.

Read-only impact, bounded to one table. Permission expressions that reference only field names, $auth, or $session are unaffected.

Patches

A patch has been introduced that re-orders the LIVE notification parameter binding so captured user variables are added first and the trusted document-context and session parameters are added last.

• Versions 3.1.0 and later are not affected by this issue.

Workarounds

Affected users who are unable to update should avoid table-PERMISSIONS and LIVE WHERE expressions that read user-named variables ($value, $before, $after, $event) without also gating on a system-derived field such as the record id.

RELATE creates an edge record between two existing records, and SurrealDB enforces the CREATE permission on the edge table for this operation. When the statement included a SET id = edge:existing clause, however, the new edge's id ended up pointing at an record that was already in storage. Rather than failing because the target already existed — which is what a create operation should do — the storage layer silently overwrote the existing edge. A caller with CREATE permission could therefore replace any existing edge on the table, even without UPDATE permission for that record.

Impact

An authenticated user with CREATE permission on an edge table could overwrite any existing record on that table — including edges they had no UPDATE permission for — by issuing a RELATE whose SET id = … resolved to the target record's id. The attack is integrity-only.

Patches

A patch has been introduced that adds an explicit Statement::Relate arm using put_record instead of set_record when the create path is selected. Conflicting writes now return a RecordExists error.

• Versions 3.1.0 and later are not affected by this issue.

This is a behaviour change for applications that relied on RELATE … SET id = … to silently replace existing edges; after the patch those calls return RecordExists instead. Applications that need "create or replace" semantics should use UPSERT (which is correctly permission-gated for the update half).

Workarounds

The defect only fires when the RELATE statement includes a SET id = … clause that resolves to an existing edge id. Applications that let SurrealDB auto-generate the edge id (the default — RELATE a:1 -> edge -> b:1 SET <data> with no id override) are not affected, because auto-generated ids do not collide with existing records.

Where applications must use SET id = … (for example, to produce deterministic edge ids for idempotency), they should first verify that no record with the target id exists before issuing the statement, or restrict CREATE permission on the edge table to principals trusted with UPDATE on the same table.

SurrealDB lets callers modify records using JSON Patch operations via the UPDATE … PATCH statement (and SDK equivalents such as db.patch()). One of those operations is copy, which duplicates one field's value into another field of the same record. A PATCH with an empty from — for example, UPDATE thing:1 PATCH [{ op: 'copy', from: '', path: '/leak' }] — was treated as "copy the entire record" and duplicated every field, including fields the caller has no permission to read, into the destination field the caller chose. The permission filter that hides protected field values from the response only knew to hide the original protected field names, not the new destinations, so the protected values were returned to the caller intact under the new field name.

Impact

An authenticated user with permission to issue UPDATE … PATCH against a record could read the values of any field on that record, regardless of field-level PERMISSIONS FOR select restrictions. The leak is confidentiality-only, and bounded to the fields of the single record the caller targets per PATCH request — it does not expose other records on the same table or any data outside that record's scope.

Patches

A patch has been introduced that rejects an empty from pointer at parse time for both copy and move operations.

• Versions 3.1.0 and later are not affected by this issue.

Workarounds

Affected users who are unable to update should restrict UPDATE … PATCH to callers who already hold SELECT permission on every field of the target record — for them, the bug exposes nothing they can't already read. Otherwise, switch the mutation to an explicit SET or MERGE clause, which removes the attack surface since neither form accepts JSON Patch operations.

A record user with UPDATE access could read field values that field-level SELECT permissions hid from them. Arithmetic operators and extend embedded the raw operand into their error messages, and UPDATE permission checks evaluate against the unreduced document — so triggering such an error against a hidden field returned its value in the resulting error.

Impact

A record user issues an UPDATE that performs an incompatible operation against a hidden field — e.g. UPDATE person:me SET probe = email + 1 when email is a string — and reads the value from the returned error (Tried to compute "alice@example.com" + 1 …). One field per operation, but the attacker can repeat against any field on any record they can UPDATE.

Patches

A patch has been introduced that replaces the raw operand in every try_* operator and in extend with the operand's type name ("string", "int", "array", etc.).

• Versions 3.1.0 and later are not affected by this issue.

Workarounds

Affected users who are unable to update should not grant UPDATE permission on records whose field-level SELECT permissions are expected to hide values from the same caller.

A LIVE SELECT subscription records the user's auth state ($auth, $token, $session, $access) when it is registered, and the server uses that recorded state to evaluate the table- and row-level PERMISSIONS clauses for every subsequent notification. The recorded state is never refreshed.

When something changes the user's effective auth state — the originating session is invalidated, the session's TTL expires, or the user signs in, signs up, or authenticates as a different identity on the same connection — the subscription keeps delivering notifications under the old, stale auth state, and the PERMISSIONS that should now apply to the connection are never consulted.

Impact

A user whose session has been revoked, expired, signed out of, or re-authenticated on the same connection continues to receive real-time notifications evaluated against the prior principal. The attacker does not gain access to new resources — only continued access to resources the prior principal was already permitted to read — but that continued access persists past the point the principal change should have ended it, and persists indefinitely until the originating connection is closed.

This is confidentiality-only: the dispatcher does not enable writes evaluated under the stranded principal.

Patches

• invalidate() and TTL expiry — RpcProtocol::invalidate now calls cleanup_lqs(session_id) after clearing the session, dropping every LIVE owned by the now-invalidated session. The notification dispatcher additionally reads the originating session's exp and skips delivery once it has passed, closing the TTL-expiry leg without requiring the Session object to remain in memory.
• Principal change on signin / signup / authenticate / refresh — each of these RPC methods now snapshots the session's auth principal (Auth::id() + Auth::level()) before mutating the session and, if the principal has changed after the operation, calls cleanup_lqs(session_id). Token refresh against the same identity is therefore preserved; identity change tears stranded subscriptions down.

Versions 3.1.0 and later are not affected by this issue.

Workarounds

For unpatched versions, clients should call reset() (which tears down all LIVE queries owned by the session) or kill each outstanding live query ID before signing out, signing in as a different identity, or signing up on an existing connection. There is no client-side workaround for the TTL-expiry leg; deployments concerned about it should restrict DURATION FOR SESSION on access methods that have permission to register LIVE queries.

An anonymous caller could degrade /sql availability by streaming WebSocket frames many times larger than the operator-configured per-connection limit. The /sql upgrade handler accepted anonymous connections and did not propagate SURREAL_WEBSOCKET_MAX_MESSAGE_SIZE to the WebSocket protocol layer — incoming bytes accumulated in the per-connection read buffer before check_anon could reject the query, so the memory cost was incurred regardless of whether the caller could ever execute SurrealQL. The same upgrade path also silently ignored --deny-http sql and --deny-arbitrary-query * for authenticated callers, but that secondary effect does not grant new permissions.