CVE-2025-71392 in SurrealDB
Summary
by MITRE • 07/18/2026
SurrealDB before 2.0.5, 2.1.x before 2.1.5, and 2.2.x before 2.2.2 fails to properly escape table and field names in the command-line export command. An authenticated System User with OWNER or EDITOR roles can create tables or fields with malicious names containing SurrealQL. When a higher-privileged user subsequently imports the exported backup, the injected SurrealQL executes, enabling privilege escalation and root-level takeover of the SurrealDB instance. Applications that let users define custom tables or fields are also exposed to a universal second-order SurrealQL injection even when query parameters are sanitized.
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 07/18/2026
This vulnerability represents a critical second-order sql injection flaw in SurrealDB affecting versions prior to 2.0.5, 2.1.x prior to 2.1.5, and 2.2.x prior to 2.2.2. The core issue stems from inadequate input sanitization during the command-line export process where table and field names are not properly escaped before being written to backup files. When authenticated users with OWNER or EDITOR roles create database objects with malicious names containing SurrealQL code, these payloads become embedded in exported backups. The vulnerability operates through a classic second-order injection pattern where the malicious input appears harmless during creation but executes during subsequent import operations. This behavior aligns with CWE-116 for improper encoding or escaping of output and CWE-94 for arbitrary code execution. The attack vector leverages the trust relationship between export and import operations, where the system assumes exported data is safe for re-importation without proper validation.
The operational impact of this vulnerability extends beyond simple privilege escalation to full system compromise. An attacker with basic user privileges can escalate to SYSTEM_USER level access through the import process, effectively gaining root-level control over the database instance. This represents a severe elevation of privileges because the malicious SurrealQL code executes with the highest available permissions during import operations. The vulnerability affects not only the backup restoration process but also applications that allow users to define custom database objects, creating a universal second-order injection vector. Even when query parameters are properly sanitized during initial input processing, the exported data retains the malicious payloads, making them executable upon subsequent import operations. This pattern demonstrates the importance of sanitizing all data at rest and in transit, as the security boundary is not just at the point of user interaction but throughout the entire data lifecycle.
The attack chain begins with an authenticated user creating database objects with malicious names containing SurrealQL code, typically through application interfaces that allow custom table or field definitions. These objects are then exported using the command-line tools, where the malicious names are written to backup files without proper escaping. When a higher-privileged user imports this backup, the SurrealQL code executes within the context of the database engine with elevated privileges. The vulnerability is particularly dangerous because it can be exploited even in systems that properly sanitize inputs during creation, as the malicious data persists in exported formats. This attack pattern follows ATT&CK technique T1059.006 for execution through command-line interfaces and T1496 for resource hijacking through manipulation of backup processes. Organizations using SurrealDB should implement immediate mitigation strategies including patching to affected versions, restricting export functionality to trusted administrators only, and implementing strict validation of exported data before import operations.
Security practitioners should recognize this vulnerability as a prime example of how seemingly benign data handling processes can create critical security risks. The issue highlights the importance of input validation at all stages of data processing, particularly in backup and restore operations where data integrity is paramount. Organizations should adopt defense-in-depth strategies that include regular patch management, principle of least privilege enforcement, and monitoring for unusual export/import operations. The vulnerability also underscores the need for proper security testing of data export mechanisms and the implementation of automated validation checks to prevent malicious data from being written to backup files. Additionally, the use of parameterized queries and proper input sanitization throughout the application stack remains critical even when specific vulnerabilities are patched. This incident serves as a reminder that database security encompasses not just query execution but also the safe handling of metadata and structural elements within the database system itself.