Skip to main content
CVE Vulnerability Database
Vulnerability Database/CVE-2025-71392

CVE-2025-71392: SurrealDB Privilege Escalation Vulnerability

CVE-2025-71392 is a privilege escalation flaw in SurrealDB that allows authenticated users to inject malicious SurrealQL code through table and field names, enabling root-level takeover. This post covers technical details, affected versions, impact, and mitigation steps.

Published:

CVE-2025-71392 Overview

CVE-2025-71392 is a SurrealQL injection vulnerability in SurrealDB affecting versions before 2.0.5, 2.1.x before 2.1.5, and 2.2.x before 2.2.2. The flaw exists because the command-line export command fails to properly escape table and field names. An authenticated System User holding the OWNER or EDITOR role can create tables or fields whose names contain embedded SurrealQL statements. When a higher-privileged user later imports the resulting backup, the injected SurrealQL executes with elevated privileges. Applications that allow end users to define custom tables or fields are also exposed to universal second-order SurrealQL injection, even when query parameters are sanitized.

Critical Impact

Successful exploitation results in privilege escalation and root-level takeover of the SurrealDB instance through injected SurrealQL executed during backup import.

Affected Products

  • SurrealDB versions before 2.0.5
  • SurrealDB 2.1.x before 2.1.5
  • SurrealDB 2.2.x before 2.2.2

Discovery Timeline

  • 2026-07-18 - CVE-2025-71392 published to the National Vulnerability Database (NVD)
  • 2026-07-21 - Last updated in NVD database

Technical Details for CVE-2025-71392

Vulnerability Analysis

The vulnerability is a command injection weakness classified under [CWE-77]. SurrealDB's export command serializes database schema and data to a backup file. During serialization, table and field identifiers are written to the export stream without proper escaping. An attacker with OWNER or EDITOR privileges can create schema objects whose names contain SurrealQL syntax terminators followed by arbitrary SurrealQL statements. The malicious payload remains dormant inside the backup file and only activates during a subsequent import operation.

This is a second-order injection: the payload is stored during one operation and triggered during another. Because imports are typically performed by administrators or automated processes running with root-equivalent privileges, the injected statements execute in a context far higher than the attacker's original role. The attack vector is network-based and requires low attacker privileges plus user interaction from a privileged operator performing the import.

Root Cause

The root cause is missing output encoding in the export routine. SurrealDB treated identifiers as trusted strings and concatenated them directly into the emitted SurrealQL export script. Any character sequences that could break identifier context — including backticks, brackets, or statement terminators — were not neutralized before serialization.

Attack Vector

An authenticated OWNER or EDITOR user issues schema creation statements that embed SurrealQL inside identifier names. When an administrator later runs the export command and re-imports the backup, the embedded statements execute at root scope. The same class of injection extends to applications that allow untrusted users to name custom tables or fields, providing a universal SurrealQL injection primitive that bypasses standard parameter sanitization. See the GitHub Security Advisory for a full technical write-up.

Detection Methods for CVE-2025-71392

Indicators of Compromise

  • Table or field names containing SurrealQL keywords, backticks, semicolons, or unusual punctuation inconsistent with normal schema naming conventions.
  • Backup files whose serialized DEFINE TABLE or DEFINE FIELD statements contain unexpected trailing SurrealQL statements.
  • Unexpected creation of ROOT, NAMESPACE, or DATABASE level users, tokens, or scopes shortly after an import operation.

Detection Strategies

  • Audit SurrealDB schema for identifiers that do not match a strict allow-list pattern such as ^[A-Za-z_][A-Za-z0-9_]*$.
  • Inspect exported backup files before re-import and diff them against expected schema structures to catch injected statements.
  • Review authentication logs for OWNER or EDITOR accounts issuing DEFINE TABLE or DEFINE FIELD statements with anomalous identifier payloads.

Monitoring Recommendations

  • Enable and centralize SurrealDB audit logs, forwarding schema-modification events to a SIEM for correlation.
  • Alert when a database import is executed by a root-level operator, and validate the source of the backup file.
  • Track privilege changes on the SurrealDB instance and flag any new root-level principals created within a short window after import.

How to Mitigate CVE-2025-71392

Immediate Actions Required

  • Upgrade SurrealDB to 2.0.5, 2.1.5, 2.2.2, or later on all affected instances.
  • Do not import backups produced by vulnerable versions until the schema has been reviewed for injected identifiers.
  • Rotate root credentials and audit privileged accounts on any instance where an import may have executed attacker-controlled content.

Patch Information

SurrealDB addressed the flaw in versions 2.0.5, 2.1.5, and 2.2.2 by properly escaping table and field identifiers in the export command output. Details are available in the GitHub Security Advisory GHSA-ccj3-5p93-8p42 and the VulnCheck Advisory.

Workarounds

  • Restrict assignment of the OWNER and EDITOR roles to trusted operators only until patching is complete.
  • Enforce strict server-side validation on any application code that lets users define custom table or field names, rejecting non-alphanumeric characters.
  • Perform exports and imports only on patched instances, and treat backup files from vulnerable versions as untrusted input.
bash
# Verify installed SurrealDB version and upgrade
surreal version

# Example upgrade (Linux install script)
curl -sSf https://install.surrealdb.com | sh

# Enforce identifier allow-list at the application layer before schema calls
# Example (pseudo): reject any name not matching ^[A-Za-z_][A-Za-z0-9_]{0,63}$

Disclaimer: This content was generated using AI. While we strive for accuracy, please verify critical information with official sources.

Default Legacy - Prefooter | Experience the World’s Most Advanced Cybersecurity Platform

Experience the Most Advanced Cybersecurity Platform

See how the world’s most intelligent, autonomous cybersecurity platform can protect your organization today and into the future.