CVE-2026-32950
Received Received - Intake
Critical SQL Injection in SQLBot Allows Remote Code Execution

Publication date: 2026-03-20

Last updated on: 2026-03-23

Assigner: GitHub, Inc.

Description
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.
CVSS Scores
EPSS Scores
Probability:
Percentile:
Meta Information
Published
2026-03-20
Last Modified
2026-03-23
Generated
2026-05-07
AI Q&A
2026-03-20
EPSS Evaluated
2026-05-05
NVD
EUVD
Affected Vendors & Products
Showing 1 associated CPE
Vendor Product Version / Range
fit2cloud sqlbot to 1.7.0 (exc)
Helpful Resources
Exploitability
CWE
CWE Icon
KEV
KEV Icon
CWE ID Description
CWE-78 The product constructs all or part of an OS command using externally-influenced input from an upstream component, but it does not neutralize or incorrectly neutralizes special elements that could modify the intended OS command when it is sent to a downstream component.
CWE-89 The product constructs all or part of an SQL command using externally-influenced input from an upstream component, but it does not neutralize or incorrectly neutralizes special elements that could modify the intended SQL command when it is sent to a downstream component. Without sufficient removal or quoting of SQL syntax in user-controllable inputs, the generated SQL query can cause those inputs to be interpreted as SQL instead of ordinary user data.
Attack-Flow Graph
AI Powered Q&A
Can you explain this vulnerability to me?

[{'type': 'paragraph', 'content': 'CVE-2026-32950 is a critical SQL Injection vulnerability in SQLBot versions prior to 1.7.0, specifically in the /api/v1/datasource/uploadExcel endpoint. The issue arises because Excel Sheet names are directly concatenated into PostgreSQL table names without any sanitization, and these table names are then embedded into SQL COPY statements using unsafe Python f-string formatting instead of parameterized queries.'}, {'type': 'paragraph', 'content': "An attacker can exploit this by uploading specially crafted Excel files in two stages: first, a normal file with shell commands in data rows, and second, a tampered file with an XML-modified Sheet name that injects a TO PROGRAM 'sh' clause into the SQL. This allows execution of arbitrary shell commands on the backend server as the postgres user."}, {'type': 'paragraph', 'content': 'The root cause is the lack of sanitization of Sheet names and unsafe SQL query construction, enabling SQL Injection that leads to Remote Code Execution (RCE).'}] [2]


How can this vulnerability impact me? :

This vulnerability allows any authenticated user, even those with minimal privileges, to fully compromise the backend server running SQLBot.

  • Arbitrary command execution as the postgres user (UID 999) on the backend server.
  • Execution of arbitrary system commands, including reverse shells.
  • Exfiltration of sensitive files such as /etc/passwd, /etc/shadow, and application configuration files.
  • Complete takeover of the PostgreSQL database due to elevated privileges of the exploited process.

How does this vulnerability affect compliance with common standards and regulations (like GDPR, HIPAA)?:

I don't know


How can this vulnerability be detected on my network or system? Can you suggest some commands?

[{'type': 'paragraph', 'content': 'This vulnerability can be detected by monitoring for unusual or suspicious activity related to the /api/v1/datasource/uploadExcel endpoint in SQLBot versions prior to 1.7.0, especially uploads of Excel files with tampered Sheet names containing SQL injection payloads.'}, {'type': 'paragraph', 'content': 'Detection can involve inspecting HTTP requests to the vulnerable endpoint for Excel uploads where the Sheet names include suspicious patterns such as embedded SQL commands or the string TO PROGRAM.'}, {'type': 'paragraph', 'content': 'Additionally, monitoring PostgreSQL logs for COPY commands that include TO PROGRAM clauses or unexpected shell command executions can help identify exploitation attempts.'}, {'type': 'paragraph', 'content': 'Suggested commands to detect exploitation attempts include:'}, {'type': 'list_item', 'content': 'Check web server access logs for POST requests to /api/v1/datasource/uploadExcel with unusual payloads.'}, {'type': 'list_item', 'content': 'Use PostgreSQL log analysis to search for COPY commands containing TO PROGRAM, e.g.:'}, {'type': 'list_item', 'content': "grep -i 'COPY.*TO PROGRAM' /var/log/postgresql/postgresql.log"}, {'type': 'list_item', 'content': 'Monitor for creation of tables with suspicious names containing double quotes or shell command fragments.'}, {'type': 'list_item', 'content': 'If possible, capture and analyze network traffic to detect uploads of Excel files with XML modifications to Sheet names.'}] [2]


What immediate steps should I take to mitigate this vulnerability?

The primary and recommended mitigation is to upgrade SQLBot to version 1.7.0 or later, where the vulnerability has been fixed by properly sanitizing and parameterizing the SQL queries.

No effective workaround other than upgrading is recommended.

Until the upgrade can be applied, restrict access to the /api/v1/datasource/uploadExcel endpoint to trusted users only, and monitor for suspicious activity as described.


Ask Our AI Assistant
Need more information? Ask your question to get an AI reply (Powered by our expertise)
0/70
EPSS Chart