CVE-2026-32949
SSRF in SQLBot <1.7.0 Allows Arbitrary File Disclosure
Publication date: 2026-03-20
Last updated on: 2026-03-23
Assigner: GitHub, Inc.
Description
Description
CVSS Scores
EPSS Scores
| Probability: | |
| Percentile: |
Meta Information
Affected Vendors & Products
| Vendor | Product | Version / Range |
|---|---|---|
| fit2cloud | sqlbot | to 1.7.0 (exc) |
Helpful Resources
Exploitability
| CWE ID | Description |
|---|---|
| CWE-73 | The product allows user input to control or influence paths or file names that are used in filesystem operations. |
| CWE-918 | The web server receives a URL or similar request from an upstream component and retrieves the contents of this URL, but it does not sufficiently ensure that the request is being sent to the expected destination. |
Attack-Flow Graph
AI Powered Q&A
Can you explain this vulnerability to me?
[{'type': 'paragraph', 'content': 'CVE-2026-32949 is a Server-Side Request Forgery (SSRF) vulnerability in SQLBot versions prior to 1.7.0. It allows an attacker to exploit the /api/v1/datasource/check endpoint by configuring a malicious MySQL datasource with the parameter extraJdbc="local_infile=1". During the backend verification process, the attacker-controlled rogue MySQL server sends a malicious LOAD DATA LOCAL INFILE command, which forces the target server to read arbitrary files from its local filesystem and send their contents back to the attacker.'}, {'type': 'paragraph', 'content': 'This vulnerability enables unauthorized access to sensitive system and application files such as /etc/passwd, /etc/shadow, environment variables, and configuration files. The issue was fixed in SQLBot version 1.7.0 by blocking unsafe JDBC parameters like local_infile in MySQL connections.'}] [1, 2, 3]
How can this vulnerability impact me? :
This vulnerability can have severe impacts because it allows unauthenticated attackers to read arbitrary files on the server running SQLBot. Attackers can extract sensitive information such as privileged account hashes from /etc/shadow, environment variables containing plaintext database superuser passwords, and cloud service API keys.
Such information disclosure can lead to total database compromise and full host cluster takeover. The exploitation barrier is very low, meaning attackers can easily leverage this vulnerability to gain unauthorized access and control over the system.
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 attempting to exploit the /api/v1/datasource/check endpoint with a specially crafted MySQL datasource configuration that includes the parameter extraJdbc="local_infile=1". If the server responds by sending back contents of local files (such as /etc/passwd), it indicates the presence of the vulnerability.'}, {'type': 'paragraph', 'content': 'A proof-of-concept involves deploying a rogue MySQL server that issues a malicious LOAD DATA LOCAL INFILE command during the MySQL handshake. Then, configure a MySQL datasource in SQLBot pointing to this rogue server with the extraJdbc parameter set to enable local_infile. Triggering the datasource check will cause the server to send local file contents if vulnerable.'}, {'type': 'paragraph', 'content': 'While specific commands are not provided in the resources, the detection process involves:'}, {'type': 'list_item', 'content': 'Setting up a rogue MySQL server (e.g., using a Python script like rogue_mysql.py) that listens on a specified port and targets a local file.'}, {'type': 'list_item', 'content': 'Configuring a MySQL datasource in SQLBot with the rogue server\'s IP, port, and extraJdbc="local_infile=1".'}, {'type': 'list_item', 'content': "Triggering the /api/v1/datasource/check endpoint (e.g., via the SQLBot UI's verify action) to see if the server returns the contents of the targeted file."}] [3]
What immediate steps should I take to mitigate this vulnerability?
The primary and recommended immediate mitigation step is to upgrade SQLBot to version 1.7.0 or later, where this SSRF vulnerability has been fixed.
The fix in version 1.7.0 includes validation to block unsafe JDBC parameters such as local_infile in MySQL datasource configurations, preventing exploitation of this vulnerability.
Until the upgrade can be applied, avoid configuring or accepting MySQL datasource connections that include the extraJdbc parameter local_infile=1 or similar unsafe parameters.