GHSA-cc8f-fcx3-gpjr: Arbitrary File Disclosure via DEFINE ANALYZER mapper filter in SurrealDB

SurrealDB is a multi-model database engine designed for highly scalable cloud applications. Among its features is support for full-text search, which allows developers to configure custom tokenizers, filters, and analyzers. An analytical utility within this search engine, the mapper filter, is designed to ingest a mapping file from the local file system. This mapping file allows the tokenization pipeline to translate specified search terms to normalized values.

A local file disclosure vulnerability exists in SurrealDB prior to version 3.1.5. This issue allows authenticated database users possessing EDITOR or OWNER privileges to read arbitrary files from the host server. The vulnerability is tracked under the identifier GHSA-cc8f-fcx3-gpjr. It stems from a combination of insufficient path validation and verbose error logging.

An attacker with administrative database credentials can invoke the DEFINE ANALYZER statement and configure a mapper filter pointing to critical system files. Because the parser attempts to read the targeted file as a two-column term-mapping file, it fails on standard files and leaks the content of the invalid lines within the resulting database error messages. This mechanism can expose credentials, process environment variables, and system configurations.

The vulnerability is caused by two distinct logical flaws in the handling of the mapper filter paths. First, the database does not restrict file access paths to a specific sandbox directory by default. Although SurrealDB includes a directory checking function in crates/core/src/iam/file.rs designed to enforce access limits, the logic fails when no allowlist is explicitly defined.

If the SURREAL_FILE_ALLOWLIST environment variable is unset, the internal path verification array remains empty. In this state, the validation logic operates in a 'fail-open' manner, immediately canonicalizing and approving any file path requested by the caller. Consequently, the application will attempt to open any file readable by the operating system user account under which SurrealDB is executed.

Second, the parser built for reading mapping files is overly descriptive when encountering parsing errors. The mapper filter expects files formatted in a structured two-column format, such as tab-separated values. When it parses standard configuration files or binary data, the operation fails and generates an error that includes the literal text of the parsed line. This behavior enables the attacker to view the file contents indirectly through database error responses.

The path validation function, check_is_path_allowed, failed to enforce restrictions when the configuration vector was empty. The following code represents the vulnerable implementation in crates/core/src/iam/file.rs:

fn check_is_path_allowed(path: &Path, allowed_path: &[PathBuf]) -> Result<PathBuf, Error> {
	let canonical_path = fs::canonicalize(path)?;
 
	// VULNERABILITY: An empty allowlist results in unconditional access approval
	if allowed_path.is_empty() {
		return Ok(canonical_path);
	}
 
	if allowed_path.iter().any(|allowed| canonical_path.starts_with(allowed)) {
		Ok(canonical_path)
	} else {
		Err(Error::FileAccessDenied(path.to_string_lossy().to_string()))
	}
}

To remediate this behavior, the patch implements a secure-by-default design where the list is checked properly, and the mapper files are routed through the is_path_allowed validator prior to initialization. The modified crates/core/src/idx/ft/analyzer/mapper.rs file now implements the path verification step before attempting to load file contents:

impl Mapper {
	pub(in crate::idx) async fn new(path: &Path) -> Result<Self, Error> {
		let mut terms = Tree::new();
		// PATCH: Ensure the path is checked against the configured allowlist
		let path = is_path_allowed(path)?;
		Self::iterate_file(&mut terms, &path).await?;
		Ok(Self {
			terms: Arc::new(terms),
		})
	}
}

This modification guarantees that unless SURREAL_FILE_ALLOWLIST is explicitly set to a valid directory, the database prevents the ingestion of files. Furthermore, because canonicalize is executed on both the requested path and the configured allowlist, directory traversal techniques using path segments such as .. are neutralized.

Exploitation of GHSA-cc8f-fcx3-gpjr requires network access to the SurrealDB SQL query interface and valid credentials with EDITOR or OWNER roles. The attack begins by registering a custom analyzer with a mapper filter pointing to the target local file. This is achieved via a standard SurrealQL statement:

DEFINE ANALYZER read_passwd TOKENIZERS blank FILTERS mapper('/etc/passwd');

When this statement is evaluated, the database attempts to initialize the analyzer and read /etc/passwd. Because /etc/passwd does not conform to the expected two-column schema, the parser triggers an exception on the first line. The resulting database response contains the error message leaking the first line of the file, which usually corresponds to the system's root user account definition.

To retrieve entire files, the attacker can target system files that contain no newline characters. On Linux platforms, pseudo-files in the /proc directory, such as /proc/self/cmdline and /proc/self/environ, use null bytes (\x00) rather than newlines as delimiters. When SurrealDB attempts to parse these files, it processes the entire content as a single line, causing the database to leak all environment variables or startup arguments within the error message.

The impact of this vulnerability is classified as High, with a CVSS v3.1 score of 7.7. The confidentiality impact is high because unauthorized actors can read arbitrary files within the security boundaries of the operating system user account under which SurrealDB is running. This bypasses the typical isolation boundaries between the database engine and the host environment.

By accessing files such as /proc/self/environ, attackers can retrieve sensitive environment variables. This often includes cloud service provider keys, API tokens, and database access credentials. Accessing /proc/self/cmdline can expose the plain-text passwords used to start the SurrealDB database server, directly facilitating administrative takeover of other database instances.

There is no integrity or availability impact associated with this flaw, as the vulnerability is restricted to read operations. However, the exposure of environment secrets often serves as a key pivot point for lateral movement and privilege escalation inside the targeted network infrastructure.

The primary remediation path is upgrading the SurrealDB binary to version 3.1.5 or later. In this and subsequent versions, the system prevents directory access when SURREAL_FILE_ALLOWLIST is unconfigured, and error messages no longer leak line contents.

For systems where upgrading is not immediately possible, administrators must configure the SURREAL_FILE_ALLOWLIST environment variable. This variable must point to a specific, restricted directory containing only legitimate mapping files. This forces the validation algorithm to enforce directory limits and prevents access to system locations such as /etc or /proc.

Administrators can detect potential exploitation attempts by auditing the database metadata for suspicious analyzer definitions. Executing the statement INFO FOR DB; allows teams to review all registered analyzers and identify any custom mapper paths referencing system paths. In addition, network logs can be parsed for SurrealQL query strings containing the DEFINE ANALYZER keyword associated with the mapper filter.