Overview

DB-GPT is an open-source agentic AI data assistant for building AI and data products. Its /v1/chat/react-agent endpoint relies on get_user_from_headers for authentication, but that function is a mock that returns an admin user for every request, with or without credentials.

The ReAct agent behind the endpoint has a code_interpreter tool that runs model-generated Python as a plain subprocess, and a shell_interpreter tool that runs bash on the host while bypassing the project's own sandbox opt-in guard. Any unauthenticated client can therefore ask the agent to run code, and it executes as root inside the webserver container.

‍

Because exploitation can occur with a single unauthenticated request to DB-GPT's ReAct agent endpoint, giving any network client root code execution in the webserver container with no sandbox, exposed deployments should be taken off the network or put behind authentication immediately.

‍

Affected Product

eosphoros-ai/DB-GPT

‍

Affected Files

• packages/dbgpt-serve/src/dbgpt_serve/utils/auth.py:25-38 - mock get_user_from_headers
• packages/dbgpt-app/src/dbgpt_app/openapi/api_v1/tools/code_interpreter.py:131-138 - unsandboxed subprocess execution
• packages/dbgpt-app/src/dbgpt_app/openapi/api_v1/tools/shell_interpreter.py:34-73 - direct LocalRuntime import, bypasses SANDBOX_ALLOW_LOCAL_RUNTIME guard
• packages/dbgpt-app/src/dbgpt_app/openapi/api_v1/agentic_data_api.py:3249-3252, 1784-1785 - /v1/chat/react-agent endpoint, wires both interpreters

‍

Root Cause

get_user_from_headers in auth.py is a mock that unconditionally returns a UserRequest with role="admin" regardless of whether a user_id header is present, performing no credential verification.

‍

The /v1/chat/react-agent endpoint uses this function as its sole authentication gate. When the ReAct agent invokes the code_interpreter tool, LLM-generated Python is written to a temp file and executed via asyncio.create_subprocess_exec(sys.executable, tmp_path, cwd=work_dir) with no container, seccomp, network namespace, or capability isolation.

The shell_interpreter tool imports LocalRuntime directly, bypassing the SANDBOX_ALLOW_LOCAL_RUNTIME opt-in guard that governs the container-based sandbox path, and runs bash commands on the webserver host.

‍

PoC

Full unauthenticated RCE chain (local OSS models, commit 100acd7 / v0.8.1):

1. Bind-mount the reviewed source's packages/ over the published image; bring the stack up with SILICONFLOW_API_KEY=....

2. Send an unauthenticated POST to /api/v1/chat/react-agent (no auth header) with an analysis prompt.

3. llama3.1:8b (x2 runs) and qwen3:8b emitted the code_interpreter tool call; on-host docker exec confirmed a marker file /tmp/dbgpt_pwned and id returning uid=0(root) inside the webserver container.

‍

One run's interpreter additionally authenticated to the default-credential DB from inside the container, chaining to the DB leg. mistral:7b did not engage (a ReAct tool-call formatting failure, not a safety refusal) - the only variable observed was the model's tool-calling ability, not any auth or isolation barrier.

Mock authentication confirmed at auth.py:25-38:

def get_user_from_headers(user_id: Optional[str] = Header(None)):    
	try:        # Mock User Info        
      if user_id:            
      	return UserRequest(user_id=user_id, role="admin", nick_name=user_id, 		real_name=user_id)        
      else:            
        return UserRequest(user_id="001", role="admin", nick_name="dbgpt",real_name="dbgpt")

‍

Unsandboxed execution confirmed at code_interpreter.py:131-138:

proc = await asyncio.create_subprocess_exec(sys.executable,tmp_path, stdout=asyncio.subprocess.PIPE,stderr=asyncio.subprocess.PIPE,cwd=work_dir)

‍

Impact

Any unauthenticated network client that can reach the DB-GPT webserver port can execute arbitrary code in the webserver container as root, subject only to the LLM model's willingness to emit a tool call.

‍

Confirmed exploitation produced root-level command execution inside the container and, in one run, chained authentication to the co-located MySQL instance using its default credentials. DB-GPT has no multi-tenancy, so unauthenticated access to the API already constitutes full administrative compromise of the deployment.

‍

Suggested Remediation

1. Replace the mock get_user_from_headers with real authentication and authorization.

2. Route the code_interpreter and shell_interpreter tools through the container runtime with network_disabled=True, a dedicated non-application network, dropped capabilities, and read-only mounts; remove the LocalRuntime import path from shell_interpreter.

3. Remove the shared host /tmp bind-mount across sandbox sessions.

4. Require authentication on the standalone dbgpt-sandbox API.

‍

Additional Resources

• CVE-2026-77932

‍