SurrealDB Core CVE-2026-121417

Not a default-configuration remote flaw. Exploitation requires ALL of: (1) a Rust program embedding surrealdb-core as a library and holding a public Datastore/Transaction (or Transactor); (2) calling a KV-backend method that dispatches blocking work into affinitypool::spawn_local - the advisory lists count, get/set point reads/writes, keys/keysr, scan/scanr, compact, shutdown, and open_keys_cursor/open_vals_cursor with next_batch/for_each on the rocksdb, mem and surrealkv backends; and (3) leaking the returned future via a safe mechanism (mem::forget, Box::leak, ManuallyDrop, an Rc/Arc cycle, or a leaked enclosing future) and then dropping the transaction while the pool worker is still running, so the future's Drop safety barrier never executes. LIMITING FACTORS: the vector is local/in-process (AV:L) - the vendor explicitly states no remote input (SurrealQL, JS, WASM, RPC) can reach the leak, so standard server deployments driven only by remote queries are not exposed; only builds whose Cargo.lock pins affinitypool 0.7.0 and whose kvs/ sources contain spawn_local call sites (versions before 3.3.0) are affected; and the embedder must itself commit the leak, so a correctly-written embedder that awaits or drops the future is not vulnerable.

Signals diverge sharply here. The CVSS 4.0 base score is 8.8 (High), but the vector itself tells the real story: AV:L (local, in-process), AC:H (high complexity), AT:P (a specific attack requirement must hold - an independent pool worker must still be using the borrows when they end), PR:L and UI:N. This is NOT a remotely reachable flaw. The vendor advisory is explicit that no remote input path (SurrealQL, JS, WASM, RPC) can trigger it, because no remote input can call mem::forget - only the embedder's own Rust code can leak the dispatched future. So the trigger is a soundness defect in the surrealdb-core public API that is reachable only when a Rust embedder leaks a future (mem::forget/Box::leak/ManuallyDrop/Rc-Arc cycle) and then drops the transaction. No CISA KEV listing is present (not confirmed actively exploited) and no EPSS score was provided, so the quantitative exploitation-probability signal is simply missing and cannot be weighed. The vuln.today decision label is 'this_week' - meaningful but explicitly NOT act_now or emergency. The GHSA advisory does publish a complete public-API PoC with an AddressSanitizer heap-use-after-free log, which raises credibility of the bug class, but PoC availability is a distinct signal from active exploitation and must not be conflated. Bottom line: this is a genuine, patch-worthy priority for anyone who embeds surrealdb-core as a Rust library, but the headline 8.8 overstates practical risk for standard remote/server deployments - it behaves much more like a constrained, local, embedder-dependent memory-safety bug than a widespread exploitable threat. One conflict to flag: the supplied CVSS 4.0 sets all subsequent-system metrics (SC/SI/SA) to High, implying a cross-system scope change, which the described single-process pool-worker UAF does not obviously support - verify with the vendor.

A Rust application that embeds surrealdb-core holds a public Datastore/Transaction and calls a KV-backend method (e.g. Transactor::count on the RocksDB backend) whose blocking work is dispatched to affinitypool::spawn_local; the application then leaks the returned future with the safe mem::forget and drops the transaction while the pool worker is still scanning. The worker continues reading the freed MutexGuard/&Transaction and writes on mutex unlock, producing an AddressSanitizer-confirmed heap-use-after-free that risks crashes or memory corruption. The GHSA advisory publishes a complete public-API PoC source file and its full ASan log; the flaw is local/in-process only and cannot be reached through remote query, JS, WASM or RPC input.