No prompt injection required: Langchain-Chatchat's `/tools/call` is a remote shell

A vector breakdown of CVE-2026-75128 / GHSA-5rx2-xp53-9x5r (Langchain-Chatchat through 0.3.1.3)

Most agent bugs I write about need the model to be talked into something. This one skips the model entirely. Langchain-Chatchat has an HTTP endpoint that runs any registered tool by name, with no authentication, and one of the tools that's always registered is a shell.

What the advisory actually says

From GHSA-5rx2-xp53-9x5r and the VulnCheck advisory, published October 20, 2026 at 03:32 UTC:

Product: Langchain-Chatchat, an open-source RAG and agent app built on LangChain. Affected: through 0.3.1.3. No fixed release is listed.
Weakness: CWE-306, Missing Authentication for Critical Function. Severity: Critical, CVSS 3.1 score 9.8 (AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H).
The bug: the project "exposes a POST /tools/call API endpoint that invokes any registered tool by name without authentication, leaving the always-registered shell tool callable."
Impact: "Remote attackers can send a single request naming the shell tool to execute arbitrary OS commands as the server user (root in the shipped Docker image)."
Credit: VulnCheck credits Noy Pearl, Michael Sromin and Ophir Dror.

The vector: the agent's toolbox, published as an API

The advisory points at tool_routes.py. Reading it at the referenced commit, the shape is simple:

A /tools router has two routes. GET /tools lists every registered tool with its name, description and argument schema. POST /tools/call takes a tool name and an input dictionary and runs that tool.
Neither route has an authentication dependency.
Tools register themselves when their module is imported. The tools package imports a shell tool that wraps LangChain's ShellTool, described as "Use Shell to execute system shell commands."
So anyone who can reach the API server can list the tools, see shell, and call it directly.

No model is involved, so there's no system prompt to get around and no injection to craft. The tool layer that was meant to sit behind the agent is reachable straight from the network.

Why this class of bug exists: three root causes

1. Agent tools exposed without the agent's controls

Mechanism. In an agent app, tools are meant to be called by the model inside a turn, with whatever checks the app places around that turn. A direct "call any tool" endpoint is handy for debugging and for front ends. But it removes every control the agent path had and makes the HTTP layer the only policy. Here the HTTP layer has none.

Evidence. The advisory: the endpoint "invokes any registered tool by name without authentication." In the source, call_tool looks up the tool by the caller-supplied name and calls ainvoke on the caller-supplied input. Nothing checks who's asking or which tool they named.

What fixes it. Don't expose a generic tool-invocation route in production. If a front end needs one, put authentication on it and keep an explicit allow-list of tools callable that way, with dangerous tools never on it.

2. A dangerous tool on by default

Mechanism. Registering every tool when the package is imported is convenient, because nobody has to wire them up. It also means the riskiest tool in the box ships turned on for everyone, including people who never asked for it.

Evidence. The advisory calls the shell tool "always-registered." In the source, the tools package imports shell next to calculate, weather_check and the rest, and the @regist_tool decorator registers it on import.

What fixes it. Tools that execute code, run shell commands or touch the filesystem should be opt-in. Require an explicit config flag to enable them, and log loudly at startup when they are on.

3. Deployment defaults that turn a local bug into a remote one

Mechanism. A missing auth check on a service bound to localhost is a local problem. The same check on a service listening on every interface, running as root, is remote code execution with full control of the container.

Evidence. Outside Docker, the project's settings bind the API server to 127.0.0.1 by default, on port 7861. The shipped Dockerfile changes that with chatchat-config server --default_bind_host=0.0.0.0 and never sets a non-root USER, which matches the advisory's "root in the shipped Docker image." The example docker-compose.yaml runs the container with network_mode: "host", so that listener sits directly on the host's network.

What fixes it. Images should run as an unprivileged user, and anything that listens on all interfaces should require authentication. If a container has to bind 0.0.0.0 to be reachable, publish the port only to localhost or a private network and put an authenticating proxy in front.

How this connects to the approval-gate bugs

A lot of this week's agent advisories are about approval gates that get skipped: by sub-agents, by headless modes, by injected instructions. This one shows what happens when the gate isn't skipped but missing, because the tool can be called without going through the agent at all. Before asking "can the model be tricked into calling the shell?", ask the simpler question: can anyone call the shell without the model?

Defensive takeaways you can check this week

Find out if you run it. Langchain-Chatchat through 0.3.1.3 is affected and no fixed release is listed, so watch the advisory for one.
Check exposure first. Find out whether port 7861 (the API server) is reachable from anywhere beyond the machine itself. If you used the shipped Docker image or compose file, assume it listens on all interfaces.
Block /tools at the edge. Put the API server behind a reverse proxy that requires authentication, and deny /tools and /tools/call outright unless you actually use them.
Turn off the shell tool. If your deployment doesn't need shell commands, remove or disable that tool rather than relying on network controls alone.
Don't run as root. Rebuild the image with a non-root user and a read-only filesystem where you can, so one bad request doesn't own the container.
Look at your logs. Search the API server or proxy logs for POST /tools/call from addresses you don't recognize, and if you find any, treat the host and any keys on it as compromised.
Audit your own agent apps. Search for routes that take a tool name from the request and invoke it. Every one needs authentication and an allow-list, whatever framework you use.

Sources

If you're building agent backends and want a checklist for this kind of trust boundary, the Trust Boundary pack covers it.

This article was drafted with AI assistance and edited by a human. All facts come from the advisory, its CVE record and the source files it references.