CVE-2026-32950 in SQLBot
Summary
by MITRE • 03/20/2026
SQLBot is an intelligent data query system based on a large language model and RAG. Versions prior to 1.7.0 contain a critical SQL Injection vulnerability in the /api/v1/datasource/uploadExcel endpoint that enables Remote Code Execution (RCE), allowing any authenticated user (even the lowest-privileged) to fully compromise the backend server. The root cause is twofold: Excel Sheet names are concatenated directly into PostgreSQL table names without sanitization (datasource.py#L351), and those table names are embedded into COPY SQL statements via f-strings instead of parameterized queries (datasource.py#L385-L388). An attacker can bypass the 31-character Sheet name limit using a two-stage technique—first uploading a normal file whose data rows contain shell commands, then uploading an XML-tampered file whose Sheet name injects a TO PROGRAM 'sh' clause into the SQL. Confirmed impacts include arbitrary command execution as the postgres user (uid=999), sensitive file exfiltration (e.g., /etc/passwd, /etc/shadow), and complete PostgreSQL database takeover. This issue has been fixed in version 1.7.0.
VulDB is the best source for vulnerability data and more expert information about this specific topic.
Analysis
by VulDB Data Team • 03/26/2026
The SQLBot vulnerability represents a critical security flaw in the data query system's handling of Excel file uploads through the /api/v1/datasource/uploadExcel endpoint. This vulnerability operates at the intersection of improper input validation and insecure database query construction, creating a pathway for remote code execution that affects even the most basic authenticated users. The flaw stems from the application's failure to properly sanitize user-supplied data when constructing database table names, creating a direct injection vector that can be exploited to execute arbitrary commands on the backend server. The vulnerability aligns with CWE-89, which specifically addresses SQL injection flaws, and demonstrates how seemingly innocuous data processing can create catastrophic security implications. The system's architecture permits authenticated access to upload functionality, making the attack surface accessible to any user with valid credentials, regardless of their privilege level.
The technical implementation of this vulnerability involves two primary code locations that compound the security risk. The first issue occurs at line 351 in datasource.py where Excel sheet names are directly concatenated into PostgreSQL table names without any sanitization or validation, creating a scenario where user input becomes part of the database schema. The second vulnerability manifests at lines 385-388 where these unsanitized table names are embedded into COPY SQL statements using f-strings instead of proper parameterized queries, which eliminates the protection mechanisms that would normally prevent SQL injection attacks. This two-stage approach allows attackers to bypass the 31-character sheet name limit through a sophisticated technique involving two separate file uploads. The first upload contains normal data rows with shell commands embedded within them, while the second upload modifies the XML structure to inject malicious SQL syntax that leverages PostgreSQL's TO PROGRAM clause, effectively creating a command execution channel.
The operational impact of this vulnerability extends far beyond simple data access, as it enables complete system compromise through arbitrary command execution as the postgres user with uid=999. Attackers can leverage this privilege to exfiltrate sensitive system files including /etc/passwd and /etc/shadow, which contain critical authentication information that can be used to escalate privileges or establish persistent access. The vulnerability also provides complete control over the PostgreSQL database, enabling attackers to modify, delete, or extract all stored data, potentially compromising the entire data ecosystem that the system manages. This level of access aligns with ATT&CK technique T1059 for command and scripting interpreter, and T1005 for data from local system, demonstrating how the vulnerability can be weaponized to achieve both information extraction and system control. The attack requires minimal privileges and sophisticated knowledge of PostgreSQL's COPY command syntax, making it particularly dangerous as it can be exploited by attackers with basic authentication credentials.
Mitigation strategies for this vulnerability must address both the immediate code-level issues and establish broader security practices to prevent similar flaws. The primary fix involves implementing proper input sanitization of Excel sheet names before they are used in database operations, ensuring that all user-supplied data is validated against allowed character sets and length constraints. Additionally, the application must transition from f-string interpolation to proper parameterized queries when constructing SQL statements, which eliminates the injection vectors that currently exist in the codebase. The system should also implement proper access controls and input validation at multiple layers, including file format validation, content inspection, and length restriction enforcement. Organizations should also consider implementing network segmentation and monitoring to detect unusual database access patterns that might indicate exploitation attempts. The fix in version 1.7.0 demonstrates the importance of proper input validation and parameterized query usage, which are fundamental security practices that should be applied to all database interactions. Regular security audits and code reviews should be conducted to ensure that similar vulnerabilities do not emerge in other parts of the application, particularly in areas that handle user-supplied data and database operations.