DB-GPT CVE-2026-77932: Unauthenticated Shell as Root

DB-GPT CVE-2026-77932 is an unauthenticated remote code execution flaw in one of the most popular open-source AI agent frameworks, and it is not alone. It is one of six CVEs published in mid-October 2026 across five open-source agent platforms, all found by Lasso Security researchers Noy Pearl, Michael Sromin and Ophir Dror, and all variations on one bug class: a path to a host shell behind either no authentication at all or an approval gate that sub-agents, schedulers and headless runs never reach. Only one of the five products has a stated fix. If you self-host any of these tools, this is the week to find them. Source

What CVE-2026-77932 actually is

The VulnCheck advisory is blunt about the mechanism. DB-GPT through version 0.8.2 exposes a ReAct agent at /api/v1/chat/react-agent. The endpoint's get_user_from_headers function is a mock that returns an admin user for every request, so authentication on that path simply does not exist. The agent's code_interpreter tool runs model-generated Python as a plain subprocess, and its shell_interpreter tool runs bash on the host while bypassing the project's own SANDBOX_ALLOW_LOCAL_RUNTIME guard. Both execute as root inside the webserver container. The advisory scores it 9.3 under CVSS 4.0 and classifies it as CWE-306, missing authentication for a critical function. Source

One detail from the researchers' proof of concept matters for how you think about agent security. Exploitation required the model to actually emit the tool call. Against DB-GPT v0.8.1 running local models, llama3.1:8b and qwen3:8b complied, while mistral:7b failed on tool-call formatting. The vulnerability is in the platform, but the trigger is the model's behavior, which means "our model would never do that" is not a control. In one documented run the interpreter also logged into the co-located MySQL database using its default credentials. Source

That default credential is a separate CVE, CVE-2026-77933. DB-GPT's shipped docker-compose.yml sets a fixed MySQL root password, publishes port 3306 to the host, and connects the web server as root. Anyone who reaches that port gets a superuser with FILE and SUPER privileges, and the same credential sits in the environment of the container an attacker has just compromised. Source

The same shape in four more platforms

Langchain-Chatchat, another widely deployed open-source agent stack, carries CVE-2026-75128 through version 0.3.1.3. Its POST /tools/call endpoint invokes any registered tool by name with no authentication, and it ignores the per-tool "use" flag that is supposed to keep dangerous tools away from the agent. A shell tool is always registered. The API server binds to 0.0.0.0 on port 7861 by default, the shipped compose file uses host networking, and the image runs as root. One nasty operational detail: the command executes before the response is serialized, so the endpoint returns an error even when the attack succeeded. Source

The uncomfortable coda: a public GitHub issue reporting this exact endpoint, with a working curl proof of concept, was opened on the Langchain-Chatchat repository in April 2026 and closed as stale in May, months before the CVE was assigned in October. The maintainers were told. Source

The other three platforms do have approval gates somewhere, just not on the paths that matter. EvoScientist's async sub-agents, including its scheduler, were built without the framework's interrupt_on or excluded_tools settings, so the underlying deepagents framework attached its built-in execute tool anyway, guarded only by a seven-command denylist. In the documented EvoSci serve --auto-approve deployment, text the agent ingested from messaging channels could run commands as the process owner. LangAlpha binds Bash and ExecuteCode tools with no allow-list and no human interrupt while the same agent fetches web pages and filings; injected instructions run in a sandbox that holds vault secrets in a JSON file protected only by a natural-language prompt. OpenSRE's shell_run and cli_exec tools never set requires_approval, its headless presenter approves everything unconditionally, and the researchers demonstrated injected Grafana and Loki alerts driving kubectl config changes and a sudo systemctl restart against local qwen3 models. Source

The scores do not agree, so name your source

The headline severity depends on who scored it. Lasso's own listing puts the DB-GPT pair and Langchain-Chatchat at 9.8, EvoScientist at 9.9, LangAlpha at 9.6 and OpenSRE at 9.0, without naming a CVSS version or vector. VulnCheck's advisories score five of the six at 9.3 under CVSS 4.0 and LangAlpha at 8.6. A third-party NVD mirror lists LangAlpha at 8.1 under CVSS 3.1 with user interaction required. All of these are critical or high; quote any single figure only with its scorer attached. One genuinely useful data point: Lasso's database marks none of the six as having a known exploit in the wild as of the advisories. Source

Fix status: one of five

EvoScientist 0.2.5 is the only product with a fix visible in the sources. The tracking issue was opened in late July and closed days later through a commit titled "unified HITL approval for sync + async sub-agents," which extends approval to synchronous sub-agents and makes async research agents refuse piped-to-interpreter commands and recursive deletes. Whether that release also closes the scheduler's execute tool is not stated in the release notes, so verify before treating 0.2.5 as complete. Source

For the other four, the advisory pages state no patched version. DB-GPT's newest release is v0.8.2, the exact version the advisory lists as affected, and Langchain-Chatchat shows nothing after v0.3.1. Absence from a changelog is not proof that no fix exists, so confirm against the repositories before assuming either way, but plan as if you are mitigating, not patching. Source

What to do this week

Start with inventory. Internal DB-GPT, Chatchat, OpenSRE and LangAlpha instances are easy to forget because they arrive as experiments and stay as infrastructure. Anything reachable from an untrusted network needs to come off it or sit behind real authentication today. Upgrade EvoScientist to 0.2.5 or later and stop running --auto-approve against channels you do not control. For DB-GPT specifically, change the MySQL root password, stop publishing port 3306, and give the web server a non-superuser database role. Then rotate every secret in the environment of any instance that was exposed: model API keys, database URLs, Slack, Grafana, Datadog and cloud credentials all inherit the compromise. Source

The deeper fix applies to agent code you run or write. Require explicit approval on shell and code execution tools for every execution path, including sub-agents, schedulers and headless runs, and fail closed when no approver exists. Do not use a denylist or a prompt as the security boundary, and pass child processes a scoped environment rather than the full one. Treat alert text, web pages and filings as untrusted input that can carry instructions. Our AI agent security checklist walks through these gates one by one, and the MCP server security best practices post covers the tool-permission side in more depth.

Why this keeps happening

Six CVEs across five projects reduce to two missing gates: no authentication on the agent endpoint, and no approval on the execution paths humans do not watch. Agent frameworks are shipping tool capability ahead of tool governance, and the defaults favor demos over deployment. A shell tool that works out of the box makes a great five-minute video and a terrible production posture. Until the defaults change, the perimeter for an agent platform is not the model and not the prompt; it is the endpoint and the approval gate, and both are your job to set. The pattern matches what the OWASP Agentic AI Top 10 flags about excessive agency and unsecured tool access.