GitHub issue #3082

The DB-GPT sandbox service can silently use LocalRuntime as the execution backend. In the tested source snapshot, SANDBOX_RUNTIME defaults to "local" :

Then RuntimeFactory.create() returns LocalRuntime() when the runtime preference is local, or when no container runtime is selected/available:

As a result, code submitted through the sandbox HTTP API can execute directly on the host rather than inside a containerized sandbox. I verified this through a real FastAPI sandbox service session using /api/connect followed by /api/execute .

The observed runtime was:

The safe test payload created a benign marker file inside the local runtime working directory, confirming that the API path reached local host-side execution.

What you expected to happen

The sandbox service should not silently fall back to host-local execution for untrusted code.

If Docker/Podman/Nerdctl is unavailable, the sandbox service should fail closed instead of using LocalRuntime .

LocalRuntime should require explicit opt-in, with a clear warning that code runs on the host.

The HTTP execution API should not expose host-local execution by default.

The runtime selected by RuntimeFactory.create() should be visible to users/admins before code execution.

Install DB-GPT with all dependencies: curl -fsSL | bash Or manually: git clone cd DB-GPT pip install -e ".[default]"

Install DB-GPT with all dependencies: curl -fsSL | bash

git clone cd DB-GPT pip install -e ".[default]"

Configure your LLM API key: cp .env.template .env Edit .env and set your API key: OPENAI_API_KEY=sk-xxx or MOONSHOT_API_KEY=sk-xxx (for Kimi) or other supported LLM providers

Configure your LLM API key: cp .env.template .env

CRITICAL: Ensure Docker is NOT available (to trigger the vulnerability): Stop Docker service: On Windows: Stop Docker Desktop On Linux: sudo systemctl stop docker On macOS: Quit Docker Desktop This forces the sandbox to use LocalRuntime (unsandboxed execution)

CRITICAL: Ensure Docker is NOT available (to trigger the vulnerability):

Start the DB-GPT server: dbgpt start webserver Or: python -m dbgpt_app.dbgpt_server The web interface will be available at The backend will start the sandbox service automatically

Start the DB-GPT server: dbgpt start webserver

Open DB-GPT Web interface: Navigate to in your browser You will see the DB-GPT chat interface The interface allows you to upload data files and ask AI to analyze them

Open DB-GPT Web interface:

Navigate to in your browser

You will see the DB-GPT chat interface

The interface allows you to upload data files and ask AI to analyze them

Create a test CSV file to trigger code execution: Create a file named test_data.csv with some sample data: name,age,city Alice,25,Beijing Bob,30,Shanghai Charlie,35,Guangzhou

Create a test CSV file to trigger code execution:

Create a file named test_data.csv with some sample data: name,age,city Alice,25,Beijing Bob,30,Shanghai Charlie,35,Guangzhou

Upload the CSV file and request analysis: In the DB-GPT chat interface, click the upload button Upload test_data.csv In the chat box, type: "Please analyze this CSV file and create a marker file at /tmp/dbgpt_web_unsandboxed.txt with content 'UNSANDBOXED_EXECUTION_VIA_WEB'" Send the message

Upload the CSV file and request analysis:

In the DB-GPT chat interface, click the upload button

In the chat box, type: "Please analyze this CSV file and create a marker file at /tmp/dbgpt_web_unsandboxed.txt with content 'UNSANDBOXED_EXECUTION_VIA_WEB'"

Observe the AI agent workflow: The AI will understand your request It will generate Python code to read the CSV and create the marker file The code will be sent to the sandbox service (/api/connect then /api/execute) Because Docker is unavailable, RuntimeFactory.create() falls back to LocalRuntime The code executes directly on the host, not in a container

Observe the AI agent workflow:

The AI will understand your request

It will generate Python code to read the CSV and create the marker file

The code will be sent to the sandbox service (/api/connect then /api/execute)

Because Docker is unavailable, RuntimeFactory.create() falls back to LocalRuntime

The code executes directly on the host, not in a container

Verify the vulnerability: Check if the marker file was created on the HOST filesystem: cat /tmp/dbgpt_web_unsandboxed.txt The file should contain: "UNSANDBOXED_EXECUTION_VIA_WEB" This proves that user requests through the Web UI can trigger arbitrary code execution on the host

Verify the vulnerability:

Check if the marker file was created on the HOST filesystem: cat /tmp/dbgpt_web_unsandboxed.txt

The file should contain: "UNSANDBOXED_EXECUTION_VIA_WEB"

This proves that user requests through the Web UI can trigger arbitrary code execution on the host

Compare with secure configuration: Stop the DB-GPT server Start Docker: sudo systemctl start docker (Linux) or start Docker Desktop Restart DB-GPT: dbgpt start webserver Repeat steps 6-8 This time, the code will execute inside a Docker container The marker file will be created INSIDE the container, not on the host The host filesystem remains protected

Compare with secure configuration:

Stop the DB-GPT server

Start Docker: sudo systemctl start docker (Linux) or start Docker Desktop

Restart DB-GPT: dbgpt start webserver

This time, the code will execute inside a Docker container

The marker file will be created INSIDE the container, not on the host

The host filesystem remains protected

Examine the root cause: Open packages/dbgpt-sandbox/src/dbgpt_sandbox/sandbox/execution_layer/runtime_factory.py Look at line 62: return LocalRuntime() This is the fallback when no container runtime is available LocalRuntime executes code directly on the host without isolation No warning or error is raised to alert administrators

Examine the root cause:

Open packages/dbgpt-sandbox/src/dbgpt_sandbox/sandbox/execution_layer/runtime_factory.py

Look at line 62: return LocalRuntime()

This is the fallback when no container runtime is available

LocalRuntime executes code directly on the host without isolation

No warning or error is raised to alert administrators

Relevant source files:

packages/dbgpt-sandbox/src/dbgpt_sandbox/sandbox/config.py

packages/dbgpt-sandbox/src/dbgpt_sandbox/sandbox/execution_layer/runtime_factory.py

packages/dbgpt-sandbox/src/dbgpt_sandbox/sandbox/execution_layer/local_runtime.py

packages/dbgpt-sandbox/src/dbgpt_sandbox/sandbox/user_layer/service.py

If the sandbox API is reachable by an untrusted user, or if an AI agent workflow forwards user/model-generated code into this service, code can execute on the host when the runtime is local. This weakens the expected sandbox boundary and may lead to host-side code execution.

Suggested mitigation:

Change the default SANDBOX_RUNTIME away from local .

Fail closed when container runtimes are unavailable.

Require explicit administrator opt-in for LocalRuntime .

Add clear runtime reporting in API responses/logs.

Consider rejecting /api/execute requests when the selected backend is LocalRuntime unless unsafe local execution is explicitly enabled.

Are you willing to submit PR?

Yes I am willing to submit a PR!

Activity on this issue will appear here.