← Back to Feed CACHED · 2026-10-20 17:59:56 · CACHE_KEY CVE-2026-77932
CVE-2026-77932 · CWE-306 · Disclosed 2026-10-20

DB-GPT ReAct agent unauthenticated RCE via mock get_user_from_headers admin bypass

ASSESSED — NOISGATE
Vendor
—
—
—
Reassessed
—
—
—
Verdict: —
Do you agree?
01 · The Real Story

The front door was never locked — it was painted on the wall like a Wile E. Coyote cartoon

CVE-2026-77932 is an unauthenticated remote code execution flaw in DB-GPT through 0.8.2, the open-source agentic AI data-assistant framework from eosphoros-ai (~20k GitHub stars, 100k+ Docker pulls). The vulnerable endpoint is /api/v1/chat/react-agent, which calls a mock get_user_from_headers() function that unconditionally returns an admin-role UserRequest for *every* caller — authenticated or not. Because the ReAct agent's built-in code_interpreter and shell_interpreter tools are unsandboxed and execute as root inside the webserver container, any network-reachable attacker can POST a crafted prompt that runs arbitrary Python or bash. The companion CVE-2026-77933 (hardcoded MYSQL_ROOT_PASSWORD on 0.0.0.0:3306) means that same container can pivot directly into the bundled MySQL instance with FILE and SUPER privileges. All versions from 0.x through 0.8.2 are affected. No patched release exists as of 2026-10-21.

The vendor CVSS of 9.8 CRITICAL is honest — arguably even conservative. The CVSS vector (AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H) correctly captures that this is a zero-click, pre-auth, network-reachable RCE with full CIA impact. There is no complexity gate: no race condition, no heap grooming, no ASLR bypass. The 'exploit' is an HTTP POST with a natural-language prompt asking the agent to run a shell command. The attack surface is the application's *primary interface*. The only honest downward pressure is that DB-GPT is a niche product — it is not Exchange, not Fortinet, not vCenter — so the global installed base is relatively small. But for any organization actually running it, the severity is every bit of its 9.8 label.

"Mock auth hands every caller admin, enabling one-POST RCE as root in unpatched DB-GPT"
02 · The Attack Path

5 steps from start to impact.

STEP 01

Locate the DB-GPT instance

The attacker identifies a DB-GPT instance listening on its default port 5670/tcp. In Docker deployments, the docker-compose.yml maps this port to all interfaces by default. Shodan/Censys/FOFA dorks for the DB-GPT web UI title or /api/v1 path tree would surface internet-exposed instances. Censys reports 268k+ internet-facing AI tool instances across 44 products, with the category growing 63% in nine months.
Conditions required:
  • DB-GPT webserver reachable on the network (LAN or internet)
Where this breaks in practice:
  • Many DB-GPT deployments are dev/experimental sandboxes behind NAT or VPN
  • Production deployments *may* sit behind a reverse proxy with its own auth layer
Detection/coverage: Shodan dork: http.title:"DB-GPT" or http.html:"/api/v1/chat/react-agent". Censys search for port 5670 with DB-GPT fingerprint.
STEP 02

POST a prompt to /api/v1/chat/react-agent

The attacker sends an HTTP POST to /api/v1/chat/react-agent with a JSON body containing a prompt such as *"Run id && cat /etc/shadow using your shell tool."* No authentication headers, cookies, or tokens are required. The mock get_user_from_headers() function in dbgpt/app/openapi/api_v1/api_v1_auth.py returns a UserRequest(user_id='mock_admin', role='admin') unconditionally, granting full agent access.
Conditions required:
  • HTTP POST capability (curl, Python requests, browser)
Where this breaks in practice:
  • None — the function literally never checks credentials
Detection/coverage: WAF rules matching POST to /api/v1/chat/react-agent with no valid session token. API gateway logs showing unauthenticated 200 responses on agent endpoints.
STEP 03

ReAct agent dispatches to unsandboxed interpreter

The DB-GPT ReAct agent processes the prompt through its tool-selection loop. When the prompt requests code execution, the agent selects either code_interpreter (Python) or shell_interpreter (bash). Neither tool is sandboxed — the SANDBOX_RUNTIME config defaults to local (as documented in the related CVE-2026-51869 finding by researcher Ro1ME). The interpreter executes the attacker's payload directly on the host runtime.
Conditions required:
  • DB-GPT agent has code_interpreter or shell_interpreter enabled (default)
  • SANDBOX_RUNTIME is set to 'local' (default)
Where this breaks in practice:
  • None — these are default-enabled tools and the sandbox default is 'local'
Detection/coverage: Process monitoring (EDR/auditd) on the container host for unexpected child processes spawned by the DB-GPT Python process (e.g., /bin/bash -c ...).
STEP 04

Arbitrary code executes as root

The webserver container runs as root by default in the stock docker-compose.yml. The attacker's payload executes with UID 0 inside the container, enabling full filesystem access, network pivoting to other containers on the dbgptnet Docker bridge, and installation of persistence mechanisms. Tools like socat, curl, or Python reverse shells can establish C2.
Conditions required:
  • Container runs as root (default Docker config)
Where this breaks in practice:
  • Organizations using rootless containers or user-namespace remapping would limit blast radius
  • Hardened container runtimes (gVisor, Kata) would intercept syscalls
Detection/coverage: Container runtime security (Falco, Sysdig, Aqua) alerting on root shell spawns, network connections from the webserver container to unexpected destinations.
STEP 05

Pivot to bundled MySQL via default credentials

The companion vulnerability CVE-2026-77933 means the default docker-compose.yml sets a static MYSQL_ROOT_PASSWORD and publishes port 3306 on 0.0.0.0. From the compromised container on the shared dbgptnet Docker network, the attacker connects to MySQL as root@% with the hardcoded password. FILE privilege enables reading host files via LOAD_FILE(), and SUPER privilege enables arbitrary MySQL command execution. All DB-GPT metadata, conversation history, and any connected datasource credentials stored in the database are exfiltrated.
Conditions required:
  • Default docker-compose.yml is used
  • MySQL password has not been changed from the hardcoded default
Where this breaks in practice:
  • Operators who changed the MySQL password or restricted network binding are partially protected
  • Non-Docker deployments may use external databases with proper credential management
Detection/coverage: Database activity monitoring for root logins from unexpected source IPs. Network flow analysis for container-to-container MySQL traffic.
03 · Compensating Control

1
CRITICAL 9.6→MEDIUM 5.5
SEVERITY REDUCED
Block or authenticate /api/v1/chat/react-agent at the reverse proxy — Place a reverse proxy (nginx, Caddy, Traefik, or cloud ALB) in front of DB-GPT and enforce authentication (mTLS, OAuth2 proxy, or HTTP Basic Auth) on all /api/v1/chat/* endpoints. This breaks step 2 of the attack chain by preventing unauthenticated access to the agent endpoint. Deploy within 3 days per the noisgate mitigation SLA for CRITICAL findings. This is the single highest-leverage control.
2
CRITICAL 9.6→LOW 3.1
SEVERITY REDUCED
Disable code_interpreter and shell_interpreter tools — In the DB-GPT agent configuration, remove or disable the code_interpreter and shell_interpreter tool registrations. Without these tools, the ReAct agent cannot dispatch to code execution even if the mock auth grants admin. This breaks step 3 of the chain. Deploy within 3 days. Note: this degrades DB-GPT's core analytical functionality significantly.
3
CRITICAL 9.6→HIGH 8.0
SEVERITY REDUCED
Run the container as non-root with a read-only filesystem — Modify the docker-compose.yml to set user: 1000:1000 and read_only: true (with explicit tmpfs mounts for required writable paths). This limits step 4 blast radius — the attacker still gets code execution but cannot write persistence, install tools, or escalate to container-host pivots as easily. Deploy within 3 days.
4
CRITICAL 9.6→CRITICAL 9.0
Change MySQL credentials and bind to 127.0.0.1 — Replace the hardcoded MYSQL_ROOT_PASSWORD in docker-compose.yml with a strong, unique password. Change the MySQL port binding from 0.0.0.0:3306 to 127.0.0.1:3306 (or remove the host port mapping entirely, relying on Docker network only). This breaks step 5 and neutralizes CVE-2026-77933. Deploy within 3 days.
5
CRITICAL 9.6→HIGH 7.5
SEVERITY REDUCED
Network-isolate DB-GPT behind a VPN or zero-trust gateway — Remove any direct internet exposure of port 5670. Place DB-GPT behind a VPN (WireGuard, Tailscale) or zero-trust access proxy (Cloudflare Access, Zscaler ZPA) so only authenticated internal users can reach it. This breaks step 1 for external attackers. Deploy within 3 days.
What doesn't work
  • Container network policies alone — the attacker is already root inside the container and can manipulate iptables or use the Docker bridge network to reach MySQL. Network policies reduce lateral movement but do not prevent the initial RCE.
  • WAF signature for prompt injection — the exploit uses natural-language prompts to invoke legitimate agent tools, not SQL injection or XSS payloads. Standard WAF rulesets will not flag 'please run id on the shell' as malicious. Custom rules would need to block *all* POST traffic to the agent endpoint, at which point you're just doing the reverse-proxy auth control above.
  • Upgrading DB-GPT — there is no patched version. Upgrading to 0.8.2 (latest) does not help because 0.8.2 *is* the vulnerable version.
04 · Intelligence Metadata

The supporting signals.

In-the-wild exploitationNot confirmed. Not listed on CISA KEV as of 2026-10-21. No GreyNoise tags observed. However, the exploit is trivially constructible (a single HTTP POST with a natural-language prompt), so weaponization lag is expected to be extremely short.
Proof-of-conceptNo dedicated PoC repo found on GitHub or pocindex.io as of 2026-10-21. However, the exploit requires no tooling — a curl one-liner suffices. The related CVE-2026-51869 has a documented PoC by researcher Ro1ME in GitHub issue #3082 demonstrating the unsandboxed code execution path.
EPSS92nd percentile — indicating a high probability of exploitation within 30 days, per CVE Brief.
CISA KEVNot listed as of 2026-10-21. CVE reserved 2026-08-21, published 2026-10-20 — too recent for KEV inclusion absent confirmed exploitation.
CVSS vectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H — network-reachable, zero complexity, no privileges, no user interaction, full CIA impact. CVSS 4.0 score: 9.3.
Affected versionsAll DB-GPT versions ≤ 0.8.2 (PyPI package dbgpt). The mock auth function has been present since early versions. Latest release is v0.8.2 (2026-08-26).
Fixed versionNone available. No patched release exists as of 2026-10-21. The eosphoros-ai team has not published a security advisory or fix commit.
Exposure / scanningCensys 2026 State of the Internet Report: 268k+ internet-facing AI tool instances across 44 products, growing 63% in 9 months. DB-GPT is not in the top 5 exposed products but shares the same deployment anti-pattern (default Docker configs, no auth). Docker Hub: 100k+ pulls for eosphorosai/dbgpt.
Disclosure date2026-10-20 (NVD publish). CVE reserved 2026-08-21 — approximately 60-day coordinated disclosure window.
ResearchersNoy Pearl, Michael Sromin, and Ophir Dror (credited as finders on ThreatInt).

Sources.

  1. NVD / CVE Record
  2. ThreatInt CVE Detail (researcher credits)
  3. OffSec Radar — CVE-2026-77932 Threat Intel
  4. CVE Brief — October 20, 2026 (EPSS data)
  5. Censys 2026 State of the Internet — AI Exposure
  6. DB-GPT GitHub Repository
  7. DB-GPT Docker Compose Config
  8. Related: CVE-2026-51869 PoC (Ro1ME sandbox escape)
05 · The Call

Final Verdict
= UNCHANGED to CRITICAL (9.6/10)

Why this verdict

  • Zero-friction pre-auth RCE: The mock get_user_from_headers() function is not a misconfiguration — it is the *shipped default code*. Every DB-GPT installation through 0.8.2 is vulnerable out of the box with no additional conditions. The exploit is a single HTTP POST containing a natural-language prompt. There is no complexity gate, no heap spray, no timing window.
  • Root execution with no sandbox: The SANDBOX_RUNTIME defaults to local, and the Docker container runs as root. The attacker's payload executes as UID 0 with full access to the container filesystem and the Docker bridge network. This is not theoretical — the same code path was independently confirmed by researcher Ro1ME in the CVE-2026-51869 PoC.
  • Companion credential vuln amplifies blast radius: CVE-2026-77933 (hardcoded MySQL root password on 0.0.0.0:3306) means container compromise chains directly into full database takeover with FILE and SUPER privileges, enabling data exfiltration and host filesystem reads.
  • No patch exists: As of 2026-10-21, DB-GPT 0.8.2 is the latest release. There is no fix to deploy, making compensating controls the only option.
  • EPSS 92nd percentile: The exploit prediction model rates this in the top 8% for likelihood of exploitation within 30 days, consistent with the trivial exploitability.
  • Role multiplier: DB-GPT's *canonical purpose* is connecting AI agents to production databases. In any non-toy deployment, the compromised instance holds credentials to backend data stores (PostgreSQL, MySQL, MSSQL, etc.). The blast radius in a production deployment is mass data egress from every connected datasource. While DB-GPT is not a fleet-scale infrastructure component (not AD, not a hypervisor), it is a data-access-layer component where compromise directly enables exfiltration of whatever databases it touches. For the ~20k-star installed base, a meaningful fraction of production deployments connect to regulated or sensitive data. This clears the HIGH floor and, combined with zero-friction pre-auth RCE and no available patch, sustains CRITICAL.

Why not higher?

The score is already near the ceiling. A 10.0 would require Scope:Changed (e.g., escaping from the container to the host kernel), which is not documented in this CVE. The container boundary, while weak, provides *some* isolation that prevents automatic host-level root. The CVSS 4.0 score of 9.3 reflects this nuance.

Why not lower?

Downgrading to HIGH would require meaningful friction in the attack chain, and there is *none*. Every step from initial access to root code execution uses default configurations with zero authentication. The only narrowing factor is the niche installed base, but severity is assessed per-instance, not per-internet — and for any instance that exists, exploitation is trivial. The absence of a patch makes this even more urgent, not less.

06 · Verification

Crowdsourced verification payload.

Run this script from any host with network access to the DB-GPT instance (your auditor workstation, a jump box, or a CI runner). No special privileges required — it only sends HTTP requests. Invoke with: bash check_cve_2026_77932.sh <HOST> [PORT] where <HOST> is the DB-GPT server IP/hostname and PORT defaults to 5670.

noisgate-verify.sh
BASHREAD-ONLYSAFE
#!/usr/bin/env bash
# check_cve_2026_77932.sh — Detect CVE-2026-77932 (DB-GPT mock-auth RCE)
# Usage: bash check_cve_2026_77932.sh <HOST> [PORT]
# Exit codes: 1=VULNERABLE, 0=PATCHED, 2=UNKNOWN

set -euo pipefail

HOST="${1:-}"
PORT="${2:-5670}"

if [ -z "$HOST" ]; then
  echo "Usage: $0 <HOST> [PORT]"
  exit 2
fi

BASE="http://${HOST}:${PORT}"
UA="noisgate-cve-checker/1.0"

echo "[*] Checking CVE-2026-77932 against ${BASE}"
echo "[*] Testing unauthenticated access to /api/v1/chat/react-agent ..."

# Step 1: Verify the endpoint exists and accepts unauthenticated POST
# We send a benign prompt that should NOT trigger code execution
# We're checking if the endpoint responds with 200 (auth bypass) vs 401/403
HTTP_CODE=$(curl -s -o /tmp/dbgpt_check_response.json -w '%{http_code}' \
  -X POST "${BASE}/api/v1/chat/react-agent" \
  -H "Content-Type: application/json" \
  -H "User-Agent: ${UA}" \
  -d '{"message": "What tools do you have available? List them.", "conv_uid": "noisgate-check"}' \
  --connect-timeout 10 --max-time 30 2>/dev/null) || true

if [ -z "$HTTP_CODE" ] || [ "$HTTP_CODE" = "000" ]; then
  echo "[!] UNKNOWN — Could not connect to ${BASE}. Is DB-GPT running?"
  rm -f /tmp/dbgpt_check_response.json
  exit 2
fi

echo "[*] HTTP response code: ${HTTP_CODE}"

if [ "$HTTP_CODE" = "401" ] || [ "$HTTP_CODE" = "403" ]; then
  echo "[+] PATCHED — Endpoint returned ${HTTP_CODE} (authentication enforced)."
  rm -f /tmp/dbgpt_check_response.json
  exit 0
fi

if [ "$HTTP_CODE" = "404" ]; then
  echo "[?] UNKNOWN — Endpoint not found. DB-GPT may not have the react-agent module enabled."
  rm -f /tmp/dbgpt_check_response.json
  exit 2
fi

if [ "$HTTP_CODE" = "200" ] || [ "$HTTP_CODE" = "422" ]; then
  # 200 = prompt accepted and processed (vulnerable)
  # 422 = validation error but endpoint is reachable without auth (still vulnerable)
  RESPONSE=$(cat /tmp/dbgpt_check_response.json 2>/dev/null || echo "")

  # Check if response mentions tools like code_interpreter or shell_interpreter
  if echo "$RESPONSE" | grep -qiE 'code_interpreter|shell_interpreter|tool|agent|admin'; then
    echo "[!] VULNERABLE — Endpoint accepts unauthenticated requests and agent tools are active."
    echo "[!] Mock get_user_from_headers() granted access without credentials."
    echo "[!] Response snippet: $(echo "$RESPONSE" | head -c 500)"
    rm -f /tmp/dbgpt_check_response.json
    exit 1
  else
    echo "[!] VULNERABLE — Endpoint returned ${HTTP_CODE} without authentication."
    echo "[!] The mock auth function accepted the request. Agent tool status unclear from response."
    echo "[!] Response snippet: $(echo "$RESPONSE" | head -c 500)"
    rm -f /tmp/dbgpt_check_response.json
    exit 1
  fi
fi

# Any other HTTP code
echo "[?] UNKNOWN — Unexpected HTTP ${HTTP_CODE}. Manual investigation required."
echo "    Response: $(cat /tmp/dbgpt_check_response.json 2>/dev/null | head -c 300)"
rm -f /tmp/dbgpt_check_response.json
exit 2