The vulnerability CVE-2026-32950 affects dataease SQLBot, an intelligent data query system leveraging large language models and retrieval-augmented generation (RAG). Versions prior to 1.7.0 contain a critical SQL Injection flaw in the /api/v1/datasource/uploadExcel endpoint. The root cause is twofold: first, Excel sheet names are directly concatenated into PostgreSQL table names without any sanitization or validation (in datasource.py at line 351). Second, these table names are embedded into SQL COPY commands using Python f-strings (lines 385-388), which do not provide protection against injection. The SQL COPY command is used to import data from the uploaded Excel files into PostgreSQL tables. An attacker can exploit this by uploading a normal Excel file containing shell commands in data rows, followed by an XML-tampered Excel file with a malicious sheet name that injects a TO PROGRAM 'sh' clause into the COPY statement. This technique bypasses the 31-character sheet name limit by splitting the payload across two uploads. Successful exploitation results in Remote Code Execution as the postgres user (uid=999), allowing arbitrary command execution on the backend server. Confirmed impacts include exfiltration of sensitive files such as /etc/passwd and /etc/shadow, and complete takeover of the PostgreSQL database. The vulnerability requires authentication but no user interaction beyond file upload. The issue was patched in version 1.7.0 by properly sanitizing sheet names and avoiding unsafe string interpolation in SQL commands. No known exploits are reported in the wild yet, but the high severity and ease of exploitation make this a critical risk for affected deployments.

This vulnerability poses a severe risk to organizations using dataease SQLBot versions prior to 1.7.0. An attacker with minimal privileges can escalate to full system compromise by executing arbitrary commands as the postgres user. This can lead to complete database takeover, unauthorized data access, and exfiltration of sensitive system files, potentially exposing user credentials and system configurations. The ability to run shell commands remotely can also allow attackers to pivot within the network, deploy malware, or disrupt services, severely impacting confidentiality, integrity, and availability. Given SQLBot’s role as a data query system, organizations relying on it for business intelligence or data analytics could face operational disruption and data breaches. The vulnerability’s exploitation does not require user interaction beyond authenticated file uploads, increasing the attack surface. Although no exploits are currently known in the wild, the critical nature of the flaw demands immediate attention to prevent potential targeted attacks or automated exploitation once public details become widespread.

Organizations should immediately upgrade SQLBot to version 1.7.0 or later, where the vulnerability is fixed by sanitizing Excel sheet names and using parameterized queries instead of f-string interpolation for SQL commands. Until upgrading, restrict access to the /api/v1/datasource/uploadExcel endpoint to trusted users only and implement strict authentication and authorization controls to limit who can upload Excel files. Employ network segmentation to isolate database servers and limit lateral movement in case of compromise. Monitor logs for unusual file upload patterns or suspicious SQL COPY commands. Consider deploying Web Application Firewalls (WAFs) with custom rules to detect and block SQL injection attempts targeting this endpoint. Conduct regular security audits and penetration testing focused on file upload functionalities. Educate developers on secure coding practices, especially avoiding unsafe string concatenation in SQL queries and validating all user-supplied input. Finally, maintain up-to-date backups and incident response plans to quickly recover from potential breaches.