- Exploited
- No known exploitation
- Fix
- Fixed in 4.0.0
- Who is exposed
- Not reported
Do first: Upgrade to a fixed version: 4.0.0.
- Last modified
- A 0-100 score for how much a CVE matters across the industry: exploitation, exposure, how widely the software is used, severity and whether a fix exists.What do these mean? →
- 10/100 · provisional
- Whether working attack code is public (Exploit-DB, Metasploit, Nuclei or GitHub). Public code makes attacks easier.What do these mean? →
- None on Exploit-DB, Metasploit or GitHub
Summary
Memory-safety flaws (data races and double frees) in the reblessive Rust library, which SurrealDB's query executor uses to run SurrealQL statements, can be triggered from safe Rust code. The library wrongly marks its types as safe to share and send across threads.
Written by anthropic/claude-haiku-5.5 from the sources below. Verify against them.
Read the original description
dbs::Executor drives every SurrealQL statement through reblessive::tree::TreeStack. In reblessive 0.4.3 the runtime types unconditionally assert Send/Sync (unsafe impl Send/Sync for Stack, TreeStack and Runner), while the public entry points accept any future without a Send bound and store it type-erased in a bump allocator.
Two safe-code consequences follow. First, Runner::step_async/finish_async return driver futures tied to the stack borrow rather than to &mut self, so a driver future can be duplicated; because Stack is Sync those futures are Send, and polling two copies on different threads runs drive_top_task concurrently — racy Cell/UnsafeCell access, double pop_task()/pop_dealloc() (double drop / double free) and a non-atomic Option::take. Second, TreeStack: Send lets safe code move a driver whose type-erased future captures !Send state (Rc, RefCell) to another thread while the creating thread keeps an alias of that state.
No unsafe is needed at the call site. surrealdb-core's own query futures are Send only because of the unsound unsafe impl Send for TreeStack, while the captured &mut tree::Stk is deliberately !Send.
The unsound dependency was removed in 4.0.0 and the parser now uses plain recursion (commit 75407c4bcc).
cve.now Index
- Exploitation?/40Unknown. No CISA SSVC exploitation rating yet
- Exposure?/25Unknown. No advisory context yet
- Reach10/20Affects crates.io packages
- Severity?/10Unknown. No CVSS score or vendor rating
- No patch0/5No signal
What would change the score
- Would score about 65 if added to CISA KEV
- Would score about 60 if CISA's SSVC rates exploitation active
- Would score about 32 if advisories confirm default setups are exposed
Impact
- Widely used
surrealdb-core has 44.4k weekly downloads.Source: crates.io
What to do
Upgrade to a fixed version: 4.0.0.
Timeline
- Advisory published3 days
- Record last updated
Affected versions
- surrealdb-corecrates.io
From 0.0.0-0 · fixed in 4.0.0
Evidence 3
- Advisory
- Repository
- Link
Corrections
None so far.
Something wrong on this page? Report an error. Every fix is listed here.
Questions about RUSTSEC-2026-0454
Is RUSTSEC-2026-0454 being exploited?
It is not in CISA's Known Exploited Vulnerabilities catalog, and CISA's SSVC assessment does not mark exploitation as active. That does not mean it has not been attacked: vendors and researchers can report attacks before CISA lists them. No public exploit code is tracked.Source: cve.now feed data
Which versions are affected by RUSTSEC-2026-0454?
surrealdb-core (crates.io): from 0.0.0-0 before 4.0.0.Source: cve.now feed data
How do I fix RUSTSEC-2026-0454?
Upgrade to a fixed version: 4.0.0.Source: cve.now feed data