Skip to content

chore(deps): update rust crate surrealdb to v3.1.5 [security] - #886

Open
renovate[bot] wants to merge 1 commit into
mainfrom
renovate/crate-surrealdb-vulnerability
Open

chore(deps): update rust crate surrealdb to v3.1.5 [security]#886
renovate[bot] wants to merge 1 commit into
mainfrom
renovate/crate-surrealdb-vulnerability

Conversation

@renovate

@renovate renovate Bot commented Jul 26, 2026 •
edited
Loading

Copy link
Copy Markdown
Contributor

This PR contains the following updates:

Package Type Update Change
surrealdb dependencies minor 3.0.5 → 3.1.5

Warning

Some dependencies could not be looked up. Check the Dependency Dashboard for more information.

SurrealDB: SSRF via JWKS URL — Redirect Following in JWT Key Fetch

GHSA-h5rg-8p7f-47g2

More information

Details

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

Severity

  • CVSS Score: 4.1 / 10 (Medium)
  • Vector String: CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:C/C:L/I:N/A:N

References

This data is provided by the GitHub Advisory Database (CC-BY 4.0).

SurrealDB: Arbitrary file read via DEFINE ANALYZER mapper() filter

GHSA-cc8f-fcx3-gpjr

More information

Details

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
Acknowledgements

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

Severity

  • CVSS Score: 7.7 / 10 (High)
  • Vector String: CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:N/A:N

References

This data is provided by the GitHub Advisory Database (CC-BY 4.0).

SurrealDB: Indexed ORDER BY leaks the value ordering of a SELECT-restricted field

GHSA-h4h3-3rfj-x6fq

More information

Details

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
Acknowledgements

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

Severity

  • CVSS Score: 4.3 / 10 (Medium)
  • Vector String: CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N

References

This data is provided by the GitHub Advisory Database (CC-BY 4.0).

SurrealDB: Denial of Service via deep operator chains

GHSA-jv2j-mqmw-xvv5

More information

Details

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

Severity

  • CVSS Score: 6.5 / 10 (Medium)
  • Vector String: CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H

References

This data is provided by the GitHub Advisory Database (CC-BY 4.0).

SurrealDB: Scraping a TABLE with no available PERMISSIONS to current auth level

GHSA-98fx-66cf-fc7c

More information

Details

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.

Severity

  • CVSS Score: 6.5 / 10 (Medium)
  • Vector String: CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N

References

This data is provided by the GitHub Advisory Database (CC-BY 4.0).

SurrealDB: ES512 silently downgraded to ES384 due to jsonwebtoken crate limitation

GHSA-fwg2-gr34-q3w8

More information

Details

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.

Severity

  • CVSS Score: 4.3 / 10 (Medium)
  • Vector String: CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:L

References

This data is provided by the GitHub Advisory Database (CC-BY 4.0).

SurrealDB has an Authorization Bypass via Composite Record-id Paths

GHSA-6vg3-hgrw-p5gf

More information

Details

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.

Severity

  • CVSS Score: 5.4 / 10 (Medium)
  • Vector String: CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:L/A:N

References

This data is provided by the GitHub Advisory Database (CC-BY 4.0).

SurrealDB: HTTP RPC Session Race Condition Allows Privilege Escalation

GHSA-4vgr-h27g-cf9p

More information

Details

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.

Severity

  • CVSS Score: 8.1 / 10 (High)
  • Vector String: CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H

References

This data is provided by the GitHub Advisory Database (CC-BY 4.0).

SurrealDB: USE NS/DB implicit creation bypasses DEFINE authorization

GHSA-wp87-mgvq-5j93

More information

Details

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.

Severity

  • CVSS Score: 6.5 / 10 (Medium)
  • Vector String: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:L

References

This data is provided by the GitHub Advisory Database (CC-BY 4.0).

SurrealDB: LIVE query subscriptions survive session state changes, bypassing access controls

GHSA-4m82-p8cx-f94j

More information

Details

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.

Severity

  • CVSS Score: 4.3 / 10 (Medium)
  • Vector String: CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N

References

This data is provided by the GitHub Advisory Database (CC-BY 4.0).

SurrealDB: HTTP /rpc sessions method leaks attached session UUIDs, enabling full session hijack by anonymous callers

GHSA-5qfp-32cf-69jh

More information

Details

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.

Severity

  • CVSS Score: 8.8 / 10 (High)
  • Vector String: CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H

References

This data is provided by the GitHub Advisory Database (CC-BY 4.0).

SurrealDB has unauthenticated remote DoS via malformed RPC use call

GHSA-wjjj-24cx-f28g

More information

Details

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.

Severity

  • CVSS Score: 7.5 / 10 (High)
  • Vector String: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H

References

This data is provided by the GitHub Advisory Database (CC-BY 4.0).

SurrealDB: Crafting malicious LIVE queries writes to the database, resulting in DoS, without permission to the table required

GHSA-4v76-cw68-4vc9

More information

Details

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.

Severity

  • CVSS Score: 6.5 / 10 (Medium)
  • Vector String: CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H

References

This data is provided by the GitHub Advisory Database (CC-BY 4.0).

SurrealDB: Authenticated callers can read fields hidden by field-level SELECT permissions via error messages

GHSA-6g9v-7gq3-p2c6

More information

Details

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.

Severity

  • CVSS Score: 4.3 / 10 (Medium)
  • Vector String: CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N

References

This data is provided by the GitHub Advisory Database (CC-BY 4.0).

Release Notes

surrealdb/surrealdb (surrealdb)

v3.1.5: Release 3.1.5

Compare Source

Release 3.1.5

v3.1.4: Release 3.1.4

Compare Source

Release 3.1.4

v3.1.3: Release 3.1.3

Compare Source

Release 3.1.3

v3.1.2: Release 3.1.2

Compare Source

Release 3.1.2

v3.1.1: Release 3.1.1

Compare Source

Release 3.1.1

v3.1.0: Release 3.1.0

Compare Source

Release 3.1.0

Configuration

📅 Schedule: (in timezone America/Havana)

  • Branch creation
    • At any time (no schedule defined)
  • Automerge
    • "before 4am on the first day of the month"

🚦 Automerge: Disabled by config. Please merge this manually once you are satisfied.

♻ Rebasing: Whenever PR is behind base branch, or you tick the rebase/retry checkbox.

🔕 Ignore: Close this PR and you won't be reminded about this update again.

  • If you want to rebase/retry this PR, check this box

This PR was generated by Mend Renovate. View the repository job log.

@renovate
renovate Bot requested a review from yacosta738 July 26, 2026 02:06
@github-actions github-actions Bot added the size/m Denotes a medium change size label Jul 26, 2026
@socket-security

socket-security Bot commented Jul 26, 2026

Copy link
Copy Markdown

Review the following changes in direct dependencies. Learn more about Socket for GitHub.

Diff Package Supply Chain
Security		 Vulnerability Quality Maintenance License
Addedcargo/​surrealdb@​3.1.5591009310090

View full report

@cloudflare-workers-and-pages

cloudflare-workers-and-pages Bot commented Jul 26, 2026

Copy link
Copy Markdown

Deploying corvus with  Cloudflare Pages  Cloudflare Pages

Latest commit: 9161f5a
Status: ✅  Deploy successful!
Preview URL: https://5751517f.corvus-42x.pages.dev
Branch Preview URL: https://renovate-crate-surrealdb-vul.corvus-42x.pages.dev

View logs

@sonarqubecloud

sonarqubecloud Bot commented Jul 26, 2026

Copy link
Copy Markdown

Quality Gate Passed Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Reviewers

@yacosta738 yacosta738 Awaiting requested review from yacosta738

At least 1 approving review is required to merge this pull request.

Assignees

@yacosta738 yacosta738

Labels

renovate security size/m Denotes a medium change size

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

1 participant

@yacosta738