DB-GPT CVE-2026-80104

No special conditions - remote unauthenticated exploitation against default configurations of DB-GPT 0.8.0, because get_user_from_headers grants the admin role even with no user_id header, making the skill_upload route reachable without credentials. The only real prerequisites are network reachability of the skill upload endpoint and that the server process has write permission to a directory on Python's import path (or can overwrite an already-imported module); code execution is triggered when that planted/overwritten module is next imported, so exploitation completes on the next import event rather than instantly. Limiting factors are minimal: it requires the vulnerable v0.8.0 endpoint to be exposed and the process to have write access to an importable location - filesystem permissions or a read-only package directory are the main practical constraints.

This is a genuine top-priority issue rather than a high-CVSS-but-low-real-risk finding. The CVSS 4.0 vector (AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:H/VA:H, base 9.3) aligns tightly with the described mechanics: network-reachable, low complexity, no privileges, no user interaction, full confidentiality/integrity/availability loss on the vulnerable system - and unlike many inflated scores, the description independently confirms every one of those metrics (the auth bypass justifies PR:N, and a raw filename primitive justifies AC:L). EPSS was not supplied and it is not in CISA KEV, and no POC is referenced, so there is no evidence of active or widespread exploitation yet; however, the exploit path is simple enough that any operator running v0.8.0 should treat this as urgent and patch immediately rather than wait for exploitation signals. The main uncertainty is deployment scope: DB-GPT is a widely-starred but relatively young AI project, so real production exposure is likely limited, which argues for targeted rather than mass-scanning risk in the near term.

An unauthenticated attacker sends a multipart POST to the skill upload endpoint with a filename like ../../../<app-package>/evil.py (or an absolute /path/evil.py) and an arbitrary Python payload as the body. The file lands outside the upload directory inside the application's import path, and when DB-GPT next imports that module - on the next request, task, or restart - the attacker's code runs in the server process. No POC is referenced, but the low attack complexity and absent authentication make reliable exploitation straightforward.