· via dev.to (home feed)
DB-GPT hit by two unauthenticated path-traversal file-write flaws; only one fixed in 0.8.1
Two unauthenticated path-traversal bugs let attackers write files anywhere DB-GPT runs. The skill-upload flaw is fixed in 0.8.1, but the python-upload user_id flaw still ships in the latest PyPI release.

What happened
Two distinct unauthenticated path-traversal vulnerabilities allow arbitrary file writes in DB-GPT, according to a write-up on dev.to (originally published by HOL). The first, tracked as CVE-2026-80104, targets the skill upload API. The second, CVE-2026-73034, targets the python file upload API. Both let an attacker with no credentials place files outside the intended upload directory. The critical detail: upgrading to the latest PyPI release, 0.8.1, closes only the first flaw. The second is still unfixed in any tagged release.
Bug one: skill upload filename traversal
In DB-GPT 0.8.0, the skill_upload handler in agentic_data_api.py joined the multipart file's filename straight onto pilot/tmp with no validation, so a name containing ../ segments could land a file outside the upload directory. Authentication provides no barrier here: per the write-up, get_user_from_headers in dbgpt-serve's auth utility is a mock that returns role="admin" whether or not a user_id header is supplied.
GitHub issue #3026 tracks the flaw. The fix arrived as commit aecad1a9 (PR #3065, May 2026), which added a _validate_upload_filename helper that rejects absolute paths and multi-segment names. That helper is present in tagged v0.8.1 on PyPI. CVE-2026-80104 was assigned on 2026-08-25.
Bug two: python upload user_id traversal
CVE-2026-73034 works differently. The python upload handler constructs its upload directory by joining the base directory, a python_uploads folder, and the value of the user_id HTTP header (FastAPI maps it as user-id). An existing containment check, _resolve_upload_path, only validates the filename relative to that attacker-influenced directory, so traversal sequences placed in the user_id header escape the uploads root entirely. GitHub issue #3104 confirmed an unauthenticated write outside the working directory, and the same mock authentication applies.
No release carries the fix. According to the write-up, v0.8.1 — still the newest version for both dbgpt and dbgpt-app on PyPI at research time — lacks the patch, which exists only on the main branch as commit e0c741bd, introducing _SAFE_USER_ID_RE and _resolve_user_id validation. There is no v0.8.2 GitHub tag or PyPI release. The author warns that secondary reports claiming the issue is "fixed in 0.8.2" describe a release that does not exist; operators need a build containing e0c741bd or an equivalent backport.
Scope and mitigation
Deployments that do not expose the skill upload routes (/v1/agentic_data/skill/upload and related) or the python upload route (/api/v1/python/file/upload) are not reachable through these paths, even if the code is present. The write-up also draws a line around the story: other DB-GPT problems such as plugin code execution, skill script execution and Jinja SSTI in skill.md are separate bugs with separate fixes.
The recommended path is to upgrade dbgpt-app to 0.8.1 for CVE-2026-80104, then verify the installed tree actually contains both helpers. A short Python check against the installed package shows whether _validate_upload_filename exists in agentic_data_api.py and whether _SAFE_USER_ID_RE exists in python_upload_api.py. On stock PyPI 0.8.1, the first returns True and the second False. For CVE-2026-73034, run a checkout or image that includes e0c741bd, cherry-pick or backport the user_id validation, or keep the python upload API off any untrusted network boundary and place real authentication in front of it — something the stock mock does not provide.
Why it matters
An arbitrary file write on a server hosting an agent framework is a direct compromise primitive: files can be dropped into code or configuration paths the application later loads or executes. The broader lesson is about partial remediation. "We are on the latest release" is a comfortable answer that is currently wrong for half of this problem, and third-party write-ups citing a patch version that was never published make it easier for operators to believe they are covered. Anyone running DB-GPT with either upload API exposed should verify the specific fixes exist in their installed tree rather than trusting version numbers or advisories alone.
- #dbgpt
- #security
- #path-traversal
- #cve
- #open-source