CVE-2024-10835: DB-GPT SQL Injection Vulnerability

CVE-2024-10835 Overview

CVE-2024-10835 is a critical SQL Injection vulnerability affecting eosphoros-ai/db-gpt version v0.6.0. The web API endpoint POST /api/v1/editor/sql/run allows execution of arbitrary SQL queries without any access control mechanisms. This vulnerability can be exploited by attackers to perform Arbitrary File Write operations using DuckDB SQL capabilities, enabling them to write arbitrary files to the victim's file system. The ability to write files to arbitrary locations on the system can potentially lead to Remote Code Execution (RCE).

Critical Impact

Unauthenticated attackers can execute arbitrary SQL queries, write files anywhere on the file system, and potentially achieve full Remote Code Execution on vulnerable DB-GPT instances.

Affected Products

• dbgpt db-gpt version 0.6.0
• Installations exposing the /api/v1/editor/sql/run endpoint without additional access controls
• Systems running DuckDB as the underlying database engine

Discovery Timeline

• 2025-03-20 - CVE-2024-10835 published to NVD
• 2025-07-17 - Last updated in NVD database

Technical Details for CVE-2024-10835

Vulnerability Analysis

The vulnerability exists in DB-GPT's SQL editor API endpoint which fails to implement proper access control or input validation. The POST /api/v1/editor/sql/run endpoint accepts SQL queries and executes them directly without authenticating the requesting user or sanitizing the input. This design flaw allows any attacker with network access to the API to submit and execute arbitrary SQL commands.

The vulnerability is particularly severe because DB-GPT utilizes DuckDB as its database engine. DuckDB includes powerful SQL functions that can interact with the file system, including the ability to write data to arbitrary file paths. By crafting malicious SQL queries, attackers can leverage these file system capabilities to write arbitrary content to any location accessible by the DB-GPT process.

Root Cause

The root cause is a combination of two security failures:

1. Missing Access Control (CWE-89): The /api/v1/editor/sql/run endpoint lacks authentication and authorization checks, allowing unauthenticated requests to reach the SQL execution logic.

2. Unrestricted SQL Execution: The application does not restrict which SQL commands can be executed, allowing dangerous file system operations through DuckDB's native SQL functions.

These combined weaknesses create a direct path from unauthenticated network access to arbitrary file system writes and potential code execution.

Attack Vector

The attack is executed over the network without requiring any prior authentication or user interaction. An attacker can send crafted HTTP POST requests to the vulnerable API endpoint containing malicious SQL payloads. The attack flow involves:

1. The attacker identifies a DB-GPT instance with the exposed /api/v1/editor/sql/run endpoint
2. A malicious SQL query is crafted using DuckDB's file writing capabilities
3. The payload is sent via HTTP POST to the vulnerable endpoint
4. The SQL is executed without validation, writing attacker-controlled content to the file system
5. By writing to specific locations (such as cron directories, web roots, or startup scripts), the attacker can achieve code execution

The vulnerability requires no privileges, no user interaction, and can be exploited remotely, making it highly accessible to attackers. For additional technical details, refer to the Huntr Bounty Report.

Detection Methods for CVE-2024-10835

Indicators of Compromise

• Unexpected HTTP POST requests to /api/v1/editor/sql/run from external or unauthorized IP addresses
• SQL queries containing file system operations such as COPY, EXPORT, or file path references
• New or modified files in sensitive directories that were not created by legitimate processes
• Cron jobs, startup scripts, or web shells appearing unexpectedly on the system

Detection Strategies

• Implement web application firewall (WAF) rules to detect and block SQL injection patterns targeting the /api/v1/editor/sql/run endpoint
• Monitor HTTP access logs for unauthenticated POST requests to the vulnerable API endpoint
• Deploy file integrity monitoring (FIM) to detect unauthorized file writes in critical system directories
• Use behavioral analysis to identify anomalous SQL query patterns, particularly those involving file operations

Monitoring Recommendations

• Enable detailed logging for all API requests to the DB-GPT application, including request bodies
• Configure alerts for any SQL queries containing DuckDB file operation commands
• Monitor for process execution originating from newly created files in writable directories
• Implement network segmentation to limit exposure of the DB-GPT API to trusted networks only

How to Mitigate CVE-2024-10835

Immediate Actions Required

• Restrict network access to the /api/v1/editor/sql/run endpoint using firewall rules or network segmentation
• Implement authentication and authorization controls in front of the vulnerable endpoint using a reverse proxy or API gateway
• Audit file system permissions to ensure the DB-GPT process runs with minimal required privileges
• Review system logs for any evidence of exploitation attempts

Patch Information

At the time of this publication, users should check the DB-GPT GitHub repository for security updates addressing this vulnerability. Monitor the project for security releases beyond version 0.6.0 that implement proper access controls on the SQL editor endpoint.

Workarounds

• Deploy a reverse proxy (such as nginx or Apache) with authentication requirements in front of the DB-GPT application
• Use network-level controls to ensure the API is only accessible from trusted internal networks
• Disable or remove the SQL editor functionality entirely if it is not required for your use case
• Run the DB-GPT service in a containerized environment with read-only file system mounts where possible

# Example: Nginx configuration to add basic authentication to the API endpoint
location /api/v1/editor/sql/run {
    auth_basic "Restricted Access";
    auth_basic_user_file /etc/nginx/.htpasswd;
    proxy_pass http://localhost:5000;
}