GHSA-cc8f-fcx3-gpjr
HIGHSurrealDB: Arbitrary file read via DEFINE ANALYZER mapper() filter
Blast Radius
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
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_ALLOWLISTto a directory that contains only the intended mapping files; this confines themapperfilter to that path. On affected versions the allowlist must be non-empty to have any effect. - Grant the
EDITORandOWNERdatabase 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
- SurrealQL Documentation — DEFINE ANALYZER
- SurrealDB Documentation — Capabilities
- Related earlier advisory: GHSA-2cvj-g5r5-jrrg local file read of 2-column TSV files via analyzers
- https://github.com/surrealdb/surrealdb/pull/5600
- fix(iam): deny filesystem access by default and stop leaking file content in analyzer errors
Acknowledgements
Thanks to Jan Kahmen (@kah-ja) for finding and reporting this issue.
Affected Packages
| Ecosystem | Package | Vulnerable range | Fix |
|---|---|---|---|
| 🦀crates.io | surrealdb | all versions | 3.1.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 3.1.5 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms GHSA-cc8f-fcx3-gpjr 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-cc8f-fcx3-gpjr 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-cc8f-fcx3-gpjr. 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-cc8f-fcx3-gpjr in your dependencies?
O3 detects GHSA-cc8f-fcx3-gpjr 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.