Authenticated SQL Injection in previewData Resulting in Arbitrary File Read

Impact

Summary

A vulnerability chain exists in SQLBot Community Edition v1.8.0 that allows an authenticated user to read arbitrary files from the application server's filesystem through the /api/v1/datasource/previewData functionality.

This is not a single vulnerability — multiple security weaknesses combine to create a reliable attack path from a table-preview request to arbitrary file disclosure:

1. SQL Injection through the table_name parameter in previewData
2. Read-only enforcement bypass — blocks write operations but permits SELECT statements invoking privileged PostgreSQL functions
3. Internal PostgreSQL superuser access — loopback connections authenticate as PostgreSQL superuser without valid credentials

When the targeted datasource is SQLBot's internal PostgreSQL instance, the injected function executes with PostgreSQL superuser privileges and returns arbitrary filesystem contents directly in the API response.

Affected Endpoints

• API Endpoint: POST /api/v1/datasource/previewData
• Attack Vector: Crafted table_name value containing SQL injection payload

Technical Analysis

Flaw 1: SQL Injection Through table_name

The previewData functionality constructs SQL queries using a table_name value supplied by the client. Testing confirmed that the application accepts attacker-controlled values containing SQL syntax instead of legitimate table identifiers.

The supplied table_name is incorporated into the generated SQL query without sufficient validation or safe identifier handling, allowing attacker-controlled SQL fragments to become part of the executed query.

Flaw 2: Read-Only Enforcement Bypass

Before execution, SQLBot attempts to enforce a read-only policy. However, the implementation focuses on blocking specific write operations while permitting general SELECT statements.

As a result, a malicious query remains classified as a "read operation" while still invoking privileged PostgreSQL functions such as:

• pg_read_file() — reads arbitrary files from the server filesystem
• pg_read_binary_file() — reads arbitrary binary files
• pg_ls_dir() — lists directory contents

These functions remain reachable through an attacker-controlled SELECT statement despite the intended read-only restriction.

Flaw 3: Internal PostgreSQL Superuser Access

SQLBot's bundled PostgreSQL configuration permits trusted loopback authentication. During testing, connections to the internal PostgreSQL instance successfully authenticated as the PostgreSQL root superuser even when an intentionally incorrect password was supplied.

Because authentication is trusted on loopback connections, an attacker can configure a datasource pointing at the internal PostgreSQL instance without knowledge of valid database credentials. Queries executed through this datasource therefore run with PostgreSQL superuser privileges.

Attack Chain

POST /api/v1/datasource/previewData
  { table_name: "<SQL injection payload>" }
    ↓
[1] User-supplied table_name injected into SQL query (Flaw 1)
    ↓
[2] Read-only check: SELECT is allowed (Flaw 2)
    ↓
[3] Query executes against internal PostgreSQL as superuser (Flaw 3)
    ↓
[4] pg_read_file('/etc/passwd') → file contents in API response

Vulnerability Reproduction

Prerequisites

• SQLBot Community Edition v1.8.0 (Docker deployment)
• Valid user authentication (any authenticated user)
• Default PostgreSQL loopback authentication (trusted)

Steps to Reproduce

Step 1: Create an internal PostgreSQL datasource pointing to the container's PostgreSQL instance:

POST /api/v1/datasource

Step 2: Register a PostgreSQL catalog table for the internal datasource.

Step 3: Submit a baseline previewData request to confirm normal operation.

Step 4: Inject SQL through the table_name parameter to invoke pg_read_file():

POST /api/v1/datasource/previewData HTTP/1.1
Content-Type: application/json
Authorization: Bearer <token>

{
  "table_name": "<injected_table_name>",
  "datasource_id": "<internal_pg_datasource_id>"
}

Step 5: Verify arbitrary file read by checking the API response for file contents.

POC Evidence (from Notion Report)

The following screenshots were extracted from the researcher's Notion report, demonstrating the complete exploit chain:

Verification

The following files were successfully read from the SQLBot container and returned in the API response:

• /etc/hosts
• /etc/passwd

Impact

Affected versions

Affected versions < v1.9.0

Patches

The vulnerability has been fixed in v1.9.0.

Workarounds

It is recommended to upgrade the version to v1.9.0.

References

If you have any questions or comments about this advisory:

• Open an issue in https://github.com/dataease/sqlbot
• Email us at wei@fit2cloud.com