GHSA-ccj3-5p93-8p42
SurrealDB server-takeover via SurrealQL injection on backup import
Blast Radius
surrealdb🦀surrealdb🦀surrealdbReal-time download stats are indexed for npm and PyPI packages. This vulnerability affects crates.io packages — download data is not available via public APIs for these ecosystems.
Description
The SurrealDB command-line tool allows exporting databases through the export command. It was discovered that table or field names are not properly sanitized in exports, leading to a SurrealQL injection when the backup is reimported.
For the injection to occur, an authenticated System User with OWNER or EDITOR roles needs to create tables or fields with malicious names containing SurrealQL, subsequently exported using the export operation
The attacker could achieve a privilege escalation and root level access to the SurrealDB instance if a higher privileged user subsequently performs the import operation.
Furthermore, applications using SurrealDB that allow its users to define custom fields or tables are at risk of a universal second order SurrealQL injection, even if query parameters are properly sanitized.
This issue was discovered and patched during an code audit and penetration test of SurrealDB by cure53, the severity defined within cure53's preliminary finding is Critical, matched by our CVSS v4 assessment.
Impact
This attack can be used to perform privilege escalation and complete takeover (root access) of the SurrealDB instance, as well as being able to perform SurrealQL injection attacks against co-tenanted applications where SurrealDB is used as a shared backend for multiple applications.
Patches
A patch has been created that addresses the issue by fixing the bugs in the exporter which failed to escape some characters properly.
- Versions 2.0.5, 2.1.5, 2.2.2 and later are not affected by this issue.
Workarounds
For SurrealDB users that are unable to upgrade, users that are looking to perform import operations must manually inspect the exported data for injected statements, prior to importing.
References
SurrealDB Documentation - Export SurrealDB Documentation - Import SurrealDB Documentation - Authentication
Affected Packages
| Ecosystem | Package | Vulnerable range | Fix |
|---|---|---|---|
| 🦀crates.io | surrealdb | ≥ 2.2.0&&< 2.2.2 | 2.2.2 |
| 🦀crates.io | surrealdb | ≥ 2.1.0&&< 2.1.5 | 2.1.5 |
| 🦀crates.io | surrealdb | all versions | 2.0.5 |
Detection & mitigation playbook
Open-source dependencyDetect
Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for surrealdb. O3's reachability analysis confirms whether the vulnerable code path is actually invoked in your application, so you act on real exposure instead of every transitive match.
Fix
Update surrealdb to 2.2.2 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms GHSA-ccj3-5p93-8p42 is resolved across your whole dependency graph.
Workarounds
If you can't upgrade right away: gate or disable the affected feature, validate untrusted input at the boundary, and avoid passing attacker-controlled data into the vulnerable path. O3's runtime protection blocks exploitation in production as an interim safeguard until the upgrade lands.
How O3 protects you
O3 pinpoints whether GHSA-ccj3-5p93-8p42 is reachable in your code and exactly where to fix it, then blocks exploitation in production at runtime until the patched version is deployed.
Tailored to GHSA-ccj3-5p93-8p42. Runtime protection reduces exposure until a permanent patch is applied and verified — it complements patching, it doesn't replace it.
Frequently Asked Questions
Is GHSA-ccj3-5p93-8p42 in your dependencies?
O3 detects GHSA-ccj3-5p93-8p42 across crates.io dependencies and uses function-level reachability to confirm whether the vulnerable code path is actually reachable — not just present. No false positives.