CVE-2026-121423

SurrealDB from 3.1.0 before 3.3.0 contains a server-side request forgery vulnerability that allows database Owners to bypass port-specific deny-net rules by using JWKS URLs with implicit default ports. Attackers can configure a JWT or record access method whose JWKS URL omits port 80 or 443, causing blind GET requests to explicitly denied internal services.

SurrealDB 3.1.0 before 3.3.0 contains a server-side request forgery vulnerability in network-capability matching because port-specific --deny-net rules (HOST:PORT or IP:PORT) match only a literal host string, while the resolved-IP check discards the port. Authenticated users can call http::* functions with a hostname resolving to a denied IP, or the IP of a denied hostname, to reach blocked internal services.

SurrealDB from 3.2.0 before 3.3.0 contains a server-side request forgery vulnerability in the FilteringResolver is_private_ip check that fails to unwrap NAT64, 6to4, and Teredo IPv6 addresses. Authenticated users triggering outbound HTTP requests via SurrealQL http functions can use transition addresses embedding private IPv4 targets to reach localhost, internal services, or cloud metadata endpoints.

SurrealDB from 3.1.0 before 3.3.0 contains an improper authentication vulnerability where the MCP BoundSubject fingerprint uses the access method name instead of per-user identity for JWT/Bearer access. Attackers with a valid low-privilege token for the same access method and a victim's mcp-session-id can hijack the session and execute MCP tools with the victim's roles and permissions.

SurrealDB from 3.1.0 before 3.3.0 contains an incorrect authorization vulnerability that allows record users to infer restricted field values because the streaming planner uses indexes on fields with restrictive SELECT permissions. Attackers can issue full-text MATCHES, compound B-tree, or HNSW KNN queries against restricted fields to learn which records contain guessed values or nearest vectors.

SurrealDB before 3.3.0 contains a use-after-free vulnerability in surrealdb-core KV backends that pass borrowed transaction state into affinitypool::spawn_local closures relying on future Drop for safety. Rust embedders that leak a dispatched future (e.g. via mem::forget) and drop the transaction cause pool workers to read and write freed memory, risking crashes or memory corruption.

SurrealDB 2.0.0 before 3.3.1 does not enforce --deny-funcs restrictions on method-style function calls in the streaming engine, because MethodPart::evaluate invokes resolved functions without a capability check. Authenticated users who can submit queries can run denied functions via method syntax, e.g. [1,2].map() or $f.put()/$f.get() to write and read file bucket data despite file::* denials.

SurrealDB before 3.3.0 allows cross-tenant access because the SurrealQL USE statement switches a session to any namespace/database without checking that the caller's authenticated level covers it. Authenticated namespace, database, or record users can switch to another tenant and read, create, update, or delete rows in tables whose PERMISSIONS allow it, such as PERMISSIONS FULL.

SurrealDB from 3.0.0 before 3.3.0 contains a missing authentication vulnerability in the revoke RPC method that allows low-privileged or unauthenticated callers to invalidate other users' refresh tokens without proof of possession. Attackers can obtain grant identifiers via ACCESS SHOW ALL with VIEWER permission or leaked tokens, then permanently revoke refresh tokens to force re-authentication.

SurrealDB before 3.3.0 contains an authorization bypass vulnerability that allows callers with table-level write permission to read SELECT-restricted fields by resolving JSON Patch pointers against the unreduced record. Attackers can use PATCH copy or move operations to copy hidden fields into readable destinations, or abuse test mismatch errors as a disclosure oracle.