Raw vector
CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:N/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-32949 is a high-severity External Control of File Name or Path (CWE-73) vulnerability in Fit2Cloud Sqlbot. Its CVSS base score is 8.7 (High).
Operationally, exploitation aligns with the MITRE ATT&CK technique Data from Local System (T1005); ranked at the 35th percentile by exploit likelihood (below the median); 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 Privacy and Disclosure risk domain.
The strongest mitigations our analysis identified map to AC-4 (Information Flow Enforcement) 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.
SQLBot, an intelligent data query system based on a large language model and retrieval-augmented generation (RAG), contains a server-side request forgery (SSRF) vulnerability in versions prior to 1.7.0. The flaw, tracked as CVE-2026-32949 and associated with CWE-73 and CWE-918, affects the /api/v1/datasource/check endpoint. It enables attackers to retrieve arbitrary system and application files from the server, such as /etc/passwd or configuration files, with a CVSS v3.1 base score of 7.5 (AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N).
An unauthenticated remote attacker can exploit this vulnerability by configuring a forged MySQL data source with the malicious parameter extraJdbc="local_infile=1". When the SQLBot backend verifies connectivity to this data source, it connects to an attacker-controlled rogue MySQL server. During the MySQL handshake, the rogue server issues a malicious LOAD DATA LOCAL INFILE command, forcing the target server to read arbitrary files from its local filesystem and transmit their contents back to the attacker.
The issue was addressed in SQLBot version 1.7.0, as detailed in the project's GitHub security advisory (GHSA-wqj3-xcxf-j9m9), release notes, and the fixing commit (ff98514827bad99b8fa4b39385adecc6e3d44355). Security practitioners should upgrade to version 1.7.0 or later to mitigate the vulnerability.
This vulnerability is notable for its relevance to AI/ML-driven systems, as SQLBot leverages a large language model for data querying, highlighting SSRF risks in LLM-augmented applications. No public evidence of real-world exploitation has been reported as of the CVE publication on 2026-03-20.
OWASP Top 10 for Web (2025)
EU & UK References
- 🇪🇺 ENISA EUVD: EUVD-2026-13541
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 Server-Side Request Forgery (SSRF) vulnerability that allows an attacker to retrieve arbitrary system and application files from the server.…
more
An attacker can exploit the /api/v1/datasource/check endpoint by configuring a forged MySQL data source with a malicious parameter extraJdbc="local_infile=1". When the SQLBot backend attempts to verify the connectivity of this data source, an attacker-controlled Rogue MySQL server issues a malicious LOAD DATA LOCAL INFILE command during the MySQL handshake. This forces the target server to read arbitrary files from its local filesystem (such as /etc/passwd or configuration files) and transmit the contents back to the attacker. This issue was fixed in version 1.7.0.
- CWE(s)
AI Security AnalysisAI
- AI Category
- LLM Application Platforms
- Risk Domain
- Privacy and Disclosure
- 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
—
—
—
V5.3.2V1.3.6V1.5.3V10.4.7
Mitigating Controls (NIST 800-53 r5) AI
Information flow enforcement can restrict which destinations the server is allowed to contact on behalf of users.
Input validation directly rejects or sanitizes untrusted path strings before they reach filesystem operations.
Enforces authorization checks on the actual resource accessed, blocking unauthorized files even when a malicious path is supplied.
Least-privilege limits the set of files or directories any subject can affect, shrinking the blast radius of a path-control flaw.
Boundary protection limits the network reach of server-initiated requests even if SSRF occurs.
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.
Secure SDLC practices include input validation and path sanitization that eliminate this weakness.
Least-privilege file authorization directly limits damage from externally controlled paths.
Runtime monitoring of web applications and services can detect anomalous outbound requests indicative of SSRF.
Vulnerability identification processes can discover and record SSRF flaws in web applications.
Network segmentation and egress controls can limit the damage from successful SSRF requests.
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 can detect path-traversal issues but does not itself implement preventive controls.
Operational threat data describing SSRF campaigns can be used to tighten outbound-request allow-lists and detection rules before attackers exploit them.
Secure development lifecycle mandates input validation and path-handling controls that directly prevent external file/path manipulation.
Application security requirements explicitly call for controls against untrusted input influencing file operations.
Secure architecture principles discourage unsafe path construction but do not prescribe concrete file-name controls.
Secure coding standards require canonicalization, allow-listing, and bounds checks on file paths, directly eliminating CWE-73.