CVE-2026-53556: SQLBot: Authenticated SQL Injection in previewData Resulting in Arbitrary File Read
SQLBot is an intelligent Text-to-SQL system based on large language models and RAG. Prior to 1.9.0, the POST /api/v1/datasource/previewData endpoint in backend/apps/datasource/crud/datasource.py incorporates the client-controlled tablename value into generated SQL without safe identifier handling. An authenticated user can configure a datasource for SQLBot's internal PostgreSQL service and submit a crafted tablename that remains a SELECT operation under the read-only policy while invoking pgreadfile(), pgreadbinaryfile(), or pglsdir(). In the default tested trusted loopback authentication configuration, the internal connection accepts invalid credentials and executes with PostgreSQL superuser privileges, allowing filesystem content such as /etc/hosts and /etc/passwd to be returned in the previewData API response and potentially exposing configuration, credentials, authentication secrets, and source code. This issue is fixed in version 1.9.0.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
SQLBotto a version that resolves this vulnerability.Fixed in 1.9.0 - Configuration
Prior to version 1.9.0, refactor the previewData endpoint to apply safe identifier handling for table_name so it cannot be used to invoke pg_read_file(), pg_read_binary_file(), or pg_ls_dir() while bypassing the intended read-only policy.
SQLBot (backend/apps/datasource/crud/datasource.py) table_name handling for SQL generation in POST /api/v1/datasource/previewData = use safe identifier handling (do not directly incorporate client-controlled table_name into generated SQL) - Compensating control
In the default trusted loopback authentication configuration for SQLBot's internal PostgreSQL service, prevent invalid credentials from being accepted and ensure the internal connection does not run with PostgreSQL superuser privileges (lock down authentication and least-privilege for the internal connection).
Event History
Frequently Asked Questions
Which deployments are most exposed?
Deployments running versions prior to 1.9.0 are affected if an authenticated user can access the previewData endpoint and configure a datasource for SQLBot's internal PostgreSQL service. The default tested trusted loopback authentication configuration is especially exposed because the internal connection accepts invalid credentials and runs with PostgreSQL superuser privileges.
What does an attacker need to exploit this issue?
The attacker needs an authenticated SQLBot account and the ability to submit a crafted table_name through POST /api/v1/datasource/previewData after configuring the internal PostgreSQL datasource. The injected expression must remain a SELECT operation to satisfy the read-only policy.
What can an attacker access through successful exploitation?
An attacker can invoke PostgreSQL file functions including pg_read_file(), pg_read_binary_file(), and pg_ls_dir(), with results returned in the previewData API response. This can expose filesystem content, including configuration files, credentials, authentication secrets, and source code.
What should be done if an immediate upgrade is not possible?
The provided information identifies the previewData endpoint and access to internal PostgreSQL datasource configuration as required for exploitation. Restrict authenticated access to those capabilities until upgrading to 1.9.0 is possible.
How can I determine whether my instance is affected?
Check whether SQLBot is running a version earlier than 1.9.0 and whether authenticated users can use POST /api/v1/datasource/previewData with a datasource targeting SQLBot's internal PostgreSQL service. Also review whether the internal PostgreSQL connection uses the tested trusted loopback authentication configuration.