Signal is active with 1 mentions in latest observed window
Immediate actions
Patch affected systems immediately
Recommended action window: Monitor and triage in normal cycle
NVD description
DB-GPT v0.8.1 contains an unauthenticated path traversal vulnerability that allows remote attackers to write arbitrary files to any location on the server by injecting directory traversal sequences into the user_id HTTP header of the Python file-upload endpoint. Attackers can send a crafted multipart upload request with a traversal-poisoned user_id header to escape the intended upload directory and write attacker-controlled content to locations such as Python startup hooks, cron directories, or agent scripts, resulting in remote code execution.
🚨 CVE-2026-73034 - critical 🚨
DB-GPT <= 0.8.1 - Arbitrary File Write
> DB-GPT through 0.8.1 allows unauthenticated arbitrary file writes via a path traversa...
👾 https://cloud.projectdiscovery.io/library/CVE-2026-73034
@pdnuclei#NucleiTemplates#cve
Post summary
Advertised a critical CVE-2026-73034 in DB‑GPT version ≤0.8.1 that permits unauthenticated arbitrary file writes via path traversal, with a link to further details.
CVE-2026-73034 is the kind of bug that makes me close the laptop and go check my own servers.
DB-GPT v0.8.1 (the popular open-source AI-agent + Retrieval-Augmented Generation (RAG) framework) has an unauthenticated path traversal that ends in remote code execution (RCE). NVD rates it 9.8 Critical. Published Aug 11, 2026.
Here is the part that got me.
The injection point is not the file. It is not the body. It is the user_id HTTP header.
I went digging into how the upload endpoint builds its path. The server takes user_id straight from the request header and joins it into the save location. No auth. So you send ../../../../ inside a header that everyone treats as a harmless identity string, and you walk right out of the upload folder.
Write to a Python startup hook. Write to a cron directory. Overwrite an agent script that runs on the next task. Any of those turns "file write" into "your code runs as their process." No credentials needed. That is the whole chain.
Why does this keep happening? Because we validate the obvious inputs. We sanitize the filename. We check the body. Almost nobody treats an HTTP header as attacker-controlled data that lands in a filesystem path.
Building a document Q&A tool for a law firm on top of DB-GPT? Picture the intern upload box that anyone on the network can hit.
BEFORE (dangerous):
// user_id comes straight from the request header
path = os.path.join(UPLOAD_DIR, request.headers["user_id"], filename)
save(path, data) // ../../ walks anywhere on disk
AFTER (safe):
// never build a path from raw client input
uid = lookup_authenticated_user(session) // server-side, not a header
safe_name = secure_filename(filename)
target = os.path.realpath(os.path.join(UPLOAD_DIR, uid, safe_name))
if not target.startswith(os.path.realpath(UPLOAD_DIR)):
reject() // it escaped the upload dir, drop it
save(target, data)
Two rules that would have killed this class of bug: authenticate identity server-side (headers are not identity), and after you resolve the final path, confirm it still sits under your upload root.
If you self-host DB-GPT, patch off 0.8.1 now and check your logs for weird user_id values.
When was the last time you audited your headers as a path source, not just your form fields? And be honest: do you even log the raw user_id header today?
#AISecurity#PromptInjection#LLM
Post summary
The post describes a critical RCE vulnerability in DB‑GPT v0.8.1 caused by header-based path traversal, explains how the flaw works, and urges readers to patch immediately.
