Four self-hosted AI agent frameworks shipped unauthenticated RCE
On October 20, 2026, the NVD published five critical CVEs — scored 9.8 to 9.9 — against the AI agent frameworks Letta, Langchain-Chatchat, DB-GPT, and Piflow: tool-execution endpoints with no authentication and databases shipped with default credentials. If you run one of these frameworks, take it off the public internet until you have checked the version and port exposure.
October 20, 2026. The NVD publishes five critical CVEs — scored 9.8 to 9.9 — against the self-hosted AI agent frameworks Letta, Langchain-Chatchat, DB-GPT, and Piflow. Same day. The common thread is structural, not accidental: endpoints that execute tools without authentication, and databases shipped with default passwords. Why it matters: deploying one of these frameworks as-is means exposing a root shell to anyone who reaches the port.
The flaw class: tool execution with no front door
An AI agent is not just a language model. It is an orchestrator that calls tools — a Python interpreter, a shell, a database — to get a task done. The whole question comes down to one thing: who is allowed to trigger those tools, and under what conditions.
The wave published on October 20, 2026 shows that many open-source frameworks answer that question with “no one, and none.” All four cases share the same design error: the endpoint that executes the tool is exposed without authentication, or grants every caller the admin role by default.
The result is always the same. A remote attacker sends a single request, names the shell or exec_shell tool, and gets arbitrary command execution as root inside the container — often with the LLM API keys sitting in environment variables as a bonus.
Four frameworks, five CVEs, one pattern
The five entries read like a single technical sheet applied to four products.
CVE-2026-77936 — Letta (≤ 0.16.8). The default compose.yaml does not enable LETTA_SERVER_SECURE. The password middleware is never added, every API route stays unauthenticated, and the service exposes a superuser PostgreSQL with default credentials. Result: arbitrary Python execution via POST /v1/tools/run, user management via /v1/admin, and OS commands via COPY PROGRAM.
CVE-2026-75128 — Langchain-Chatchat (≤ 0.3.1.3). The POST /tools/call endpoint invokes any registered tool by name, with no authentication. The shell tool, which is always registered, is therefore callable by anyone: one request is enough to run OS commands as root, since that is the container user in the shipped Docker image.
CVE-2026-77932 — DB-GPT (≤ 0.8.2). The /api/v1/chat/react-agent endpoint relies on a mock get_user_from_headers function that grants the admin role to every caller. An unauthenticated attacker can then send prompts that make the ReAct agent’s code_interpreter and shell_interpreter tools run arbitrary Python or bash, as root.
CVE-2026-77933 — DB-GPT (≤ 0.8.2). The default docker-compose.yml sets a static MYSQL_ROOT_PASSWORD and publishes port 3306 on all interfaces. An attacker who reaches that port, or the shared internal network, authenticates as root@% with full privileges, including FILE and SUPER.
CVE-2026-109442 — Piflow (2.0.0 to 2.0.1). The DeepAgents chat agent exposes POST /chat and POST /chat/stream without authentication. An attacker asks the agent to call the exec_shell tool, which runs commands through subprocess.run with no human approval and no allow-list — exposing environment secrets such as LLM API keys and database credentials along the way.
What this cluster reveals
Five CVEs of the same type landing on the same day is not a calendar coincidence; it is the signature of a category tipping over. In a matter of months, agent development has produced a generation of frameworks that prioritize demonstrability — “look, the agent runs code” — over the authentication boundary.
Three factors stack up. First, tool execution is the product’s central feature, so it is exposed first and documented first. Second, those tools are inherently dangerous: a Python interpreter or a shell has no read-only surface. Third, the defaults — compose.yaml, Docker images, static passwords — are designed for a one-command start on a developer laptop, not for an internet-facing deployment.
The concrete risk is self-hosting. These are precisely the frameworks a team installs on a VPS or a NAS to keep control of its data and keys. The self-hosted version is supposed to be the safe one; here it is the vulnerable one, because nobody re-checks the defaults before publishing the port.
What to do now
Remediation is quick to state and slower to apply if the instance is already in production.
- Check the version. Move to a patched release of each framework as soon as one ships. For Letta, enable
LETTA_SERVER_SECURE; for DB-GPT, replace the staticMYSQL_ROOT_PASSWORDand stop publishing port 3306. Do not assume the latest image is clean: the CVEs cover “up to” a version, and the boundary is recent. - Cut the exposure. If the instance has no reason to be reachable from the internet, put it behind a VPN or an authenticated reverse proxy. A tool-execution endpoint should never be the first thing a scanner sees.
- Treat the container as compromised. Unauthenticated RCE means you assume access, not just patch it. If the instance was exposed, rotate the LLM API keys and database credentials stored in the container environment, then rebuild the image from scratch.
- Harden the network by default. Publish database ports only on an internal interface and deny unnecessary egress. Half the flaws above exploit a MySQL or PostgreSQL port nobody meant to expose.
Verdict
If you self-host an AI agent framework, treat it as a first-class service: cut the default exposure, enable middleware authentication, replace static credentials, and check the version before publishing any port. If you deploy generative AI across a team, take the structural lesson: the tool-execution endpoint is the new critical surface of your estate, and the defaults of open-source agent projects are not calibrated for exposed deployment — closing the door they leave open is on you.