CVE-2026-32950: Fit2cloud Sqlbot SQLi Vulnerability

CVE-2026-32950 Overview

CVE-2026-32950 is a critical SQL Injection vulnerability in SQLBot, an intelligent data query system built on large language models and RAG (Retrieval-Augmented Generation) technology. The vulnerability exists in the /api/v1/datasource/uploadExcel endpoint and enables Remote Code Execution (RCE), allowing any authenticated user—even those with the lowest privileges—to fully compromise the backend server.

Critical Impact

This vulnerability allows authenticated attackers to execute arbitrary commands as the postgres user (uid=999), exfiltrate sensitive files including /etc/passwd and /etc/shadow, and achieve complete PostgreSQL database takeover.

Affected Products

• Fit2cloud SQLBot versions prior to 1.7.0
• SQLBot deployments using PostgreSQL backend database
• Any system running vulnerable /api/v1/datasource/uploadExcel endpoint

Discovery Timeline

• 2026-03-20 - CVE-2026-32950 published to NVD
• 2026-03-23 - Last updated in NVD database

Technical Details for CVE-2026-32950

Vulnerability Analysis

The vulnerability stems from a fundamental failure to properly sanitize user-controlled input before incorporating it into SQL statements. The affected endpoint processes Excel file uploads where sheet names are directly concatenated into PostgreSQL table names without any sanitization in datasource.py at line 351. These unsanitized table names are then embedded into COPY SQL statements using Python f-strings rather than parameterized queries at lines 385-388.

This architectural flaw creates a direct path from user-controlled Excel file content to SQL execution context. The impact is particularly severe because PostgreSQL's COPY command supports a TO PROGRAM clause that enables shell command execution, transforming what might otherwise be a data injection issue into full Remote Code Execution.

Root Cause

The vulnerability has two fundamental causes. First, Excel sheet names provided by users are concatenated directly into PostgreSQL table names without any input validation or sanitization. Second, these table names are embedded into SQL COPY statements using Python f-strings instead of using parameterized queries or proper identifier quoting through PostgreSQL's built-in escaping mechanisms.

Attack Vector

An attacker can exploit this vulnerability using a sophisticated two-stage technique designed to bypass the 31-character Excel sheet name limit. In the first stage, the attacker uploads a normal Excel file containing shell commands in its data rows. In the second stage, the attacker uploads an XML-tampered Excel file with a maliciously crafted sheet name that injects a TO PROGRAM 'sh' clause into the SQL statement.

This two-stage approach allows the attacker to first plant the payload and then trigger its execution, effectively circumventing character length restrictions that would otherwise limit the attack surface.

 import traceback
 import uuid
 from io import StringIO
+from psycopg2 import sql
 from typing import List
 from urllib.parse import quote

Source: GitHub Security Patch

The fix introduces psycopg2.sql.Identifier to properly escape and quote table names, preventing SQL injection through sheet name manipulation.

Detection Methods for CVE-2026-32950

Indicators of Compromise

• Unusual activity on the /api/v1/datasource/uploadExcel endpoint, particularly multiple sequential uploads from the same authenticated user
• PostgreSQL logs showing COPY statements with suspicious TO PROGRAM clauses or unusual table names
• Process creation events showing shell commands spawned by the postgres user (uid=999)
• Unexpected file access patterns, particularly reads of sensitive system files like /etc/passwd or /etc/shadow

Detection Strategies

• Monitor PostgreSQL query logs for COPY statements containing TO PROGRAM clauses, which are unusual in normal application operation
• Implement file integrity monitoring on sensitive system files to detect unauthorized access or exfiltration attempts
• Analyze Excel file uploads for XML tampering or anomalous sheet name patterns that exceed typical naming conventions
• Deploy endpoint detection rules to identify process chains originating from PostgreSQL processes executing shell commands

Monitoring Recommendations

• Enable verbose PostgreSQL logging including statement logging to capture all SQL queries for forensic analysis
• Implement network-level monitoring for data exfiltration patterns from PostgreSQL server hosts
• Configure alerting on any process execution by the postgres system user outside of expected database operations
• Monitor authentication logs for the SQLBot application to track all user access to the vulnerable endpoint

How to Mitigate CVE-2026-32950

Immediate Actions Required

• Upgrade SQLBot to version 1.7.0 or later immediately, as this version contains the security fix
• If immediate upgrade is not possible, disable or restrict access to the /api/v1/datasource/uploadExcel endpoint
• Review PostgreSQL logs for signs of prior exploitation and investigate any suspicious COPY TO PROGRAM statements
• Audit user accounts with access to the upload functionality and enforce principle of least privilege

Patch Information

Fit2cloud has released version 1.7.0 of SQLBot which addresses this vulnerability. The fix implements proper SQL identifier escaping using psycopg2.sql.Identifier to prevent malicious input from being interpreted as SQL syntax. For detailed information, see the GitHub Security Advisory GHSA-7hww-8rj5-7rmm and the patch commit.

Workarounds

• Implement network-level access controls to restrict access to the /api/v1/datasource/uploadExcel endpoint to trusted administrators only
• Deploy a Web Application Firewall (WAF) rule to inspect and block Excel uploads containing suspicious sheet names or XML content
• Disable the Excel upload functionality entirely if it is not critical to business operations until the patch can be applied
• Configure PostgreSQL to run with reduced privileges and disable the COPY TO PROGRAM functionality if not required

# Configuration example - Restrict PostgreSQL COPY TO PROGRAM capability
# Add to postgresql.conf to log all COPY statements for monitoring
log_statement = 'all'
log_min_duration_statement = 0

# Consider running PostgreSQL in a containerized environment with restricted capabilities
# or use pg_hba.conf to limit connections to trusted hosts only