Summary
Langchain-Chatchat exposes a tool-calling API endpoint without authentication, allowing unauthenticated remote users to invoke registered tools by name. Because a shell tool is available by default, a remote attacker may execute arbitrary operating-system commands with the privileges of the server process, potentially including root in the shipped Docker image.
Langchain-Chatchat exposes a tool-calling API endpoint without authentication, allowing unauthenticated remote users to invoke registered tools by name. Because a shell tool is available by default, a remote attacker may execute arbitrary operating-system commands with the privileges of the server process, potentially including root in the shipped Docker image.
Affected context
The issue occurs in Langchain-Chatchat deployments that expose the POST /tools/call endpoint and leave tool invocation accessible without an authentication or authorization boundary. Risk is greatest when the shell tool remains registered and the service runs with elevated operating-system privileges, such as root inside a container.
The issue occurs in Langchain-Chatchat deployments that expose the POST /tools/call endpoint and leave tool invocation accessible without an authentication or authorization boundary. Risk is greatest when the shell tool remains registered and the service runs with elevated operating-system privileges, such as root inside a container.
Exploit preconditions
- Attack surface: Network-accessible POST
/tools/callAPI endpoint - Required access: No authentication is required when the endpoint is exposed
- Trigger point: A request naming a registered tool, particularly the shell tool
- Why exploitation is possible: The endpoint dispatches tool calls without verifying the caller's identity or authorization, allowing untrusted requests to reach command-execution functionality
- Attack surface: Network-accessible POST
/tools/callAPI endpoint - Required access: No authentication is required when the endpoint is exposed
- Trigger point: A request naming a registered tool, particularly the shell tool
- Why exploitation is possible: The endpoint dispatches tool calls without verifying the caller's identity or authorization, allowing untrusted requests to reach command-execution functionality
Why this happens
The vulnerability results from exposing a security-sensitive tool-dispatch operation without an authentication and authorization check. The application treats requests to invoke registered tools as trusted even when they originate from unauthenticated remote clients. This maps to CWE-306: Missing Authentication for Critical Function, because a critical operation can be reached without establishing the caller's identity.
The vulnerability results from exposing a security-sensitive tool-dispatch operation without an authentication and authorization check. The application treats requests to invoke registered tools as trusted even when they originate from unauthenticated remote clients. This maps to CWE-306: Missing Authentication for Critical Function, because a critical operation can be reached without establishing the caller's identity.
Potential impact
- Remote attackers may execute arbitrary operating-system commands
- Attackers could access, modify, or destroy data available to the server process
- The application environment may be compromised
- Elevated container privileges could increase the severity of the compromise
- Attackers may use the host or service for lateral movement, persistence, or further abuse
- Remote attackers may execute arbitrary operating-system commands
- Attackers could access, modify, or destroy data available to the server process
- The application environment may be compromised
- Elevated container privileges could increase the severity of the compromise
- Attackers may use the host or service for lateral movement, persistence, or further abuse
General mitigation guidance
Mitigation generally focuses on protecting tool invocation with strong identity and authorization controls and reducing the capabilities exposed to untrusted callers.
Common defensive patterns include:
- Require authentication and per-tool authorization before dispatching any tool call
- Avoid registering shell or other command-execution tools in externally reachable services unless they are explicitly required
- Apply allowlists that restrict callable tools, arguments, and execution contexts
- Run the service with a dedicated non-root identity and minimal filesystem, network, and operating-system permissions
- Bind administrative or tool APIs to trusted networks or private interfaces where appropriate
- Treat all tool names and arguments as untrusted input and validate them against strict schemas
- Add rate limiting, request auditing, and isolation controls around high-impact operations
Mitigation generally focuses on protecting tool invocation with strong identity and authorization controls and reducing the capabilities exposed to untrusted callers.
Common defensive patterns include:
- Require authentication and per-tool authorization before dispatching any tool call
- Avoid registering shell or other command-execution tools in externally reachable services unless they are explicitly required
- Apply allowlists that restrict callable tools, arguments, and execution contexts
- Run the service with a dedicated non-root identity and minimal filesystem, network, and operating-system permissions
- Bind administrative or tool APIs to trusted networks or private interfaces where appropriate
- Treat all tool names and arguments as untrusted input and validate them against strict schemas
- Add rate limiting, request auditing, and isolation controls around high-impact operations
How teams detect issues like this
Detection can combine code review, runtime monitoring, and policy enforcement:
- Use static analysis to identify sensitive API routes that dispatch tools without authentication or authorization checks
- Review routes that accept tool names or command-like arguments from HTTP requests
- Search deployment configuration for publicly exposed tool APIs and services running as root
- Monitor requests to
/tools/call, especially unauthenticated calls and unusual tool names or argument patterns - Enforce CI or API security policies requiring authentication for critical operations and prohibiting shell tools in public-facing deployments
- Use automated review tools to flag command execution reachable from network handlers
Detection can combine code review, runtime monitoring, and policy enforcement:
- Use static analysis to identify sensitive API routes that dispatch tools without authentication or authorization checks
- Review routes that accept tool names or command-like arguments from HTTP requests
- Search deployment configuration for publicly exposed tool APIs and services running as root
- Monitor requests to
/tools/call, especially unauthenticated calls and unusual tool names or argument patterns - Enforce CI or API security policies requiring authentication for critical operations and prohibiting shell tools in public-facing deployments
- Use automated review tools to flag command execution reachable from network handlers
