CVE-2026-80104: DB-GPT Skill Upload Path Traversal (and Sibling CVE-2026-73034)
CVE-2026-80104: v0.8.1 contains the original skill-upload fix, but v0.8.2 regresses it; v0.8.2 fixes sibling CVE-2026-73034
Contents
CVE-2026-80104: DB-GPT skill upload writes past the upload directory
Two different unauthenticated path-traversal arbitrary file writes hit DB-GPT upload APIs. CVE-2026-80104 is the skill-upload multipart filename bug in agentic_data_api.py. Its sibling CVE-2026-73034 is the python-upload user_id HTTP header bug in python_upload_api.py. DB-GPT v0.8.1 contains the original skill-upload filename fix for CVE-2026-80104. The later v0.8.2 GitHub release fixes the sibling user_id path traversal, but its tagged agentic_data_api.py again writes file.filename under upload_dir without the v0.8.1 validation call.
Who is not in scope
Deployments that do not expose the agentic skill upload HTTP API (/v1/agentic_data/skill/upload and related skill upload routes) and do not expose the python file upload HTTP API (/api/v1/python/file/upload) are not on these paths. Builds that carry both _validate_upload_filename in agentic_data_api.py and _SAFE_USER_ID_RE / _resolve_user_id in python_upload_api.py are past both bugs. Current main still carries the python-upload user_id validation, but its skill-upload path no longer calls _validate_upload_filename as of 2026-09-21. This article is not about other DB-GPT upload issues (plugin code execution, skill script execution, Jinja skill.md SSTI). Those are separate bugs with separate fixes.
What broke
In DB-GPT 0.8.0, skill_upload in packages/dbgpt-app/src/dbgpt_app/openapi/api_v1/agentic_data_api.py took the multipart file.filename and joined it onto pilot/tmp with no filename validation. A name with ../ segments writes outside the intended upload directory. Auth does not stop this: get_user_from_headers in packages/dbgpt-serve/src/dbgpt_serve/utils/auth.py is a mock that returns role="admin" whether or not a user_id header is set. GitHub issue #3026 tracks the skill-upload traversal. The fix landed as commit aecad1a9 (PR #3065, May 2026), which adds _validate_upload_filename and rejects absolute paths, multi-segment names, and ... That helper is present on tagged/PyPI v0.8.1. CVE-2026-80104 was assigned 2026-08-25.
CVE-2026-73034 is a different write. The python upload handler builds upload_dir = os.path.join(base_dir, "python_uploads", user_id) from the user_id header (FastAPI maps it as user-id). Filename containment via _resolve_upload_path only checks the filename relative to that already-poisoned directory, so a traversal in user_id escapes the uploads root. GitHub issue #3104 confirmed an unauthenticated write outside the working directory. The same mock auth applies. This bug is still present on tagged and PyPI v0.8.1: that tree has no _SAFE_USER_ID_RE. The user_id fix exists on current main as commit e0c741bd. DB-GPT also published GitHub release v0.8.2 on 2026-08-26, and its release notes explicitly include the user_id path-traversal fix. The separate skill-upload filename validation is absent from the tagged v0.8.2 handler.
What this is not
This is not a single bug. CVE-2026-80104 is not the user_id-header bug. NVD still bounds CVE-2026-80104 as 0.8.0 < 0.8.1, which matches the original v0.8.1 skill-upload fix. Released-source inspection adds a current caveat: v0.8.2 exists and its skill-upload handler has regressed to the raw filename write, while v0.8.2 fixes the sibling user_id path traversal. Treat the two code paths separately rather than inferring that both are fixed from one version number.
How to check
Print the package you actually installed:
pip show dbgpt-app
# note the installed version, then verify both upload code paths below
Then confirm both helpers in the installed tree (adjust the path to your site-packages or checkout):
python - <<'PY'
from importlib.util import find_spec
from pathlib import Path
spec = find_spec("dbgpt_app")
root = Path(spec.origin).resolve().parent
agentic = root / "openapi" / "api_v1" / "agentic_data_api.py"
python_up = root / "openapi" / "api_v1" / "python_upload_api.py"
print("agentic_data_api", agentic)
print("_validate_upload_filename", "_validate_upload_filename" in agentic.read_text())
print("python_upload_api", python_up)
print("_SAFE_USER_ID_RE", "_SAFE_USER_ID_RE" in python_up.read_text())
PY
On stock PyPI 0.8.1 you should see _validate_upload_filename True and _SAFE_USER_ID_RE False. If both are True, you are on a build that already carries the main-line user_id fix. If the skill upload or python upload routes are not mounted at all, these CVEs are not reachable even when the helpers are missing.
How to fix
For CVE-2026-80104, v0.8.1 contains the original filename validation, while the tagged v0.8.2 source regresses that check. For the sibling CVE-2026-73034, v0.8.2 contains the released user_id validation. There is not a single verified released tree here that should be assumed to cover both bugs. Verify both upload paths in the exact build you deploy.
This article is the operator write-up for both upload-path writes. The HOL Guard evidence page is the source record for CVE-2026-80104; sibling evidence for CVE-2026-73034 is at HOL Guard CVE-2026-73034.
References
Continue reading
All posts
FortiMail unauthenticated path traversal hits CISA KEV
How to fix CVE-2026-104286: disable FortiMail IBE (config system encryption ibe / set status disable) or upgrade to 8.0.2 / 7.6.7 / 7.4.9 or later

Self-managed GitLab: unauth commits API file read hits CISA KEV
How to fix CVE-2026-85706: upgrade GitLab to 18.11.12 / 19.0.9 / 19.1.8 / 19.2.6 / 19.3.2

BREAKING: CVE-2026-86259 lets unauth OpenMAIC callers pull cloud credentials via SSRF
How to fix CVE-2026-86259: upgrade OpenMAIC to 1.0.1
