Raw vector
CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:H/VI:H/VA:N/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:XSummary
CVE-2026-32950 is a high-severity OS Command Injection (CWE-78) vulnerability in Fit2Cloud Sqlbot. Its CVSS base score is 8.6 (High).
Operationally, exploitation aligns with the MITRE ATT&CK technique Command and Scripting Interpreter (T1059); ranked in the top 44% of CVEs by exploit likelihood; it is not currently listed in the CISA KEV catalog; a public proof-of-concept is referenced.
This vulnerability is AI-related — categorised as LLM Application Platforms; in the Data-Related Vulnerabilities risk domain.
The strongest mitigations our analysis identified map to SA-11 (Developer Testing and Evaluation) and SI-10 (Information Input Validation) — see the control section below for these in your framework.
Deeper analysis AI-assisted summary
Synthesised by an AI model from the NVD description and linked references — a reading aid, not an authoritative source.
CVE-2026-32950 is a critical SQL injection vulnerability in SQLBot, an intelligent data query system based on a large language model and retrieval-augmented generation (RAG), affecting versions prior to 1.7.0. The issue occurs in the /api/v1/datasource/uploadExcel endpoint due to two root causes: Excel sheet names are concatenated directly into PostgreSQL table names without sanitization (datasource.py#L351), and these table names are embedded into COPY SQL statements via f-strings rather than parameterized queries (datasource.py#L385-L388). Rated at CVSS 3.1 score of 8.8 (AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H) and mapped to CWE-78 (OS Command Injection) and CWE-89 (SQL Injection), it enables remote code execution (RCE).
Any authenticated user, even those with the lowest privileges, can exploit the vulnerability to fully compromise the backend server. The attack employs a two-stage technique to bypass the 31-character sheet name limit: first, uploading a normal Excel file whose data rows contain shell commands, followed by 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.
The vulnerability was addressed in SQLBot version 1.7.0. Mitigation details are outlined in the GitHub security advisory (GHSA-7hww-8rj5-7rmm), release notes for v1.7.0, and the fixing commit (39f2203cec4bb4b0aa541710733fe7608e3d3c48). Security practitioners should upgrade to 1.7.0 or later and review access controls for the affected endpoint.
As an LLM-based system, SQLBot's flaw highlights risks in AI/ML-integrated tools handling untrusted uploads and database interactions, though no real-world exploitation has been reported in available data.
OWASP Top 10 for Web (2025)
EU & UK References
- 🇪🇺 ENISA EUVD: EUVD-2026-13543
Vulnerability Data
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…
more
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.
- CWE(s)
AI Security AnalysisAI
- AI Category
- LLM Application Platforms
- Risk Domain
- Data-Related Vulnerabilities
- OWASP Top 10 for LLMs 2025
- None mapped
- Classification Reason
- Matched keywords: large language model
Related Threats
MITRE ATT&CK Enterprise Techniques
CVEs Like This One
Affected Assets
Mitigating Controls
Control response
—
—
—
V1.2.5V1.2.8V15.2.5V6.2.5
Mitigating Controls (NIST 800-53 r5) AI
Developer testing and evaluation can discover missing or incorrect command sanitization during development.
Input validation directly neutralizes or rejects special characters that would otherwise alter OS command structure.
Least privilege reduces the permissions available to any process that could be subverted by injected commands.
Least functionality restricts available OS commands and interpreters, limiting the blast radius of injection.
Secure engineering principles require proper neutralization of untrusted input before command construction.
System monitoring can identify attempted SQLi exploitation via anomalous queries after the weakness exists.
Mitigating Controls (NIST CSF 2.0) AI
Derived directly from the weakness types (CWEs) cited in the NVD entry via our AI-authored CWE→CSF cross-walk (authority under review) — links open the control.
PR.PS-06's SDLC practices directly require secure coding and input handling that blocks command-injection defects, yet the single broad outcome leaves many specific neutralization vectors and verification gaps unaddressed.
Training raises developer awareness of SQLi risks and can reduce introduction likelihood (partial) but removes none of the actual coding flaw's risk by itself since technical neutralization is still required.
Routine patching/maintenance can remediate known command-injection CVEs in dependencies (partial forward) but does nothing to stop developers from introducing improper neutralization in custom code (none reverse).
Mitigating Controls (ISO/IEC 27001:2022 Annex A) AI
Derived directly from the weakness types (CWEs) cited in the NVD entry via our AI-authored CWE→ISO cross-walk (authority under review) — links open the control.
Security testing and code review target insecure use of operating-system command interfaces, catching command-injection flaws introduced during development.
Early warnings and shared best-practice information help organizations apply the latest remediation techniques against SQL-injection vulnerabilities.
Threat-intelligence feeds that surface new SQL-injection campaigns enable rapid updates to query-construction defenses and detection signatures before exploitation occurs.
Secure-coding rules and security testing phases mandate the use of parameterized queries or equivalent escaping, preventing the construction of dynamic SQL statements from untrusted input.
Language-specific secure coding rules, peer review and SAST together prevent the construction of SQL statements from untrusted data without proper parameterization or escaping.