lee1981 (@lee1981b) on X

What it is

CVE-2026-77932 is a missing-authentication flaw (CWE-306) in eosphoros-ai DB-GPT through 0.8.2 inclusive (PyPI package dbgpt-app). The VulnCheck CNA published it on 20 October 2026. The page is a CyberForge "CVE of the Day" post, and it says no fixed release was verified.

How it works

At the source revision the CNA references, get_user_from_headers builds an admin-role user whether or not the optional user header is sent. The ReAct handler depends on that helper. Per the page, the Python tool starts a child interpreter, and the shell tool creates LocalRuntime directly. Lasso says the shell path bypasses the separate sandbox opt-in guard. An unauthenticated caller can therefore reach an agent that selects code or shell tools running with the application's own authority. In Lasso's lab this gave root inside the webserver container, and in one run access to the bundled database with default credentials.

Published scores, both from the VulnCheck CNA:

• CVSS v3.1 9.8: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H
• CVSS v4.0 9.3: CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N

NVD is "Deferred". Its "Primary" label on the v3.1 score is sourced to the CNA, so it is not independent NIST scoring.

Preconditions / Affected

• DB-GPT through 0.8.2, with the ReAct route and execution tools available and the backend reachable by untrusted callers.
• The CNA gives the route as /api/v1/chat/react-agent. The pinned source declares /v1/chat/react-agent, so confirm the proxy or base-path mapping locally.
• Front-end login does not prove the origin enforces authentication. Check direct listeners and alternate routes.
• Record the deployed commit or image, since dev images, source mounts and rebuilt containers may differ from a tag.

What to do

1. Restrict untrusted access to the actual backend, including alternate routes. Lasso recommends removing it from untrusted networks or adding effective authentication.
2. Preserve proxy, application/agent and container or host records before rotating or redeploying.
3. Hunt by joining the request, conversation, tool call (code_interpreter or shell_interpreter) and child process. Tool names and Python or shell activity are not unique IOCs, because legitimate analysis uses the same tools.
4. Do not trust the application's "admin" label as identity. Check it against gateway or identity-provider records.
5. Establish the real UID, mounts, capabilities, daemon access and reachable services. Reduce them with least privilege, narrower mounts and network limits.
6. Before reopening access, verify real credential checks and isolation of both execution paths through owner-approved review and controlled acceptance work. If the standalone sandbox API is deployed, review its authentication separately.

Caveats

• No fixed release is verified. GitHub's latest release (v0.8.2, 26 August) and PyPI both still show 0.8.2. The Jinja2 RCE changelog item in that release does not address this CVE. The repository advisory API returned [], and GHSA-5vjv-vw3m-qpqp is unreviewed with no fixed-version entries.
• No in-the-wild exploitation was verified. The CISA KEV catalogue retrieved (released 16 October) predates the CVE's publication, so a non-match there is weak evidence. FIRST returned no EPSS data, which means unavailable, not zero. No CISA SSVC assessment was present.
• Container root does not establish host escape. The database leg was one lab run.
• Lasso labels the issue "Known exploit: No" and shows availability as None, while both CNA vectors rate availability High. Its lab arrangement is tied to v0.8.1, while the CNA lists through 0.8.2.
• The post did no active testing. Its detection steps are source-reviewed methods, not tested detectors, and its fix proposals (real authentication and authorisation, isolated execution, narrower network and mount permissions) are researcher recommendations, not an upstream patch.