Because the product requires no authentication anywhere (user_id/user_info are plain request parameters), any network-reachable instance accepts this anonymously.

Root cause

Two properties make this reliably exploitable:

1. Absolute paths work directly — no ../ counting needed.
2. Relative traversal works too — %2e%2e%2f survives because unquote runs before any filter.

A hardening contrast inside the same codebase: the upload_faqs endpoint replaces / with _ in filenames. upload_files never got that treatment, making it the single write vector.

Note: LocalFile.__init__ has an if not os.path.exists(file_location) guard, so only new files can be created — existing files cannot be overwritten. Exploitation therefore targets new files at executable locations.

From arbitrary write to root RCE

The official Docker image runs the Python backend as root. CPython automatically imports sitecustomize.py from site-packages at interpreter startup — a fresh file dropped at:

(7×../ relative, or absolute path) is imported the next time the backend starts, executing attacker code as uid=0(root).

Why site-packages and not the app directory? CPython runs site.py before inserting sys.path[0], so a sitecustomize.py next to the entry script is not auto-imported. site-packages is the only reliable drop zone.

Other vectors were tested and ruled out (documented for completeness):

• /etc/cron.d/ — directory exists and accepts writes, but the image ships no cron daemon, so nothing ever executes the payload.
• Overwriting existing config/code files — blocked by the exists guard.

Lab reproduction

Official image + pinned vulnerable source (commit 65de104):

PoC usage (zero dependencies, Python 3 stdlib only)

The PoC script ships in this repository (poc_qanything_cve_2026_88533.py) — every evidence item below was produced by running it against the lab stack above. Clone and reproduce the exact output yourself:

--mode full restarts the target container once (documented behavior; the CPython import fires on startup). Everything ships safe by default: no reverse shell, no destructive payload — the demo payload writes a marker file containing the output of id.

What the attack traffic looks like

The entire attack is two HTTP POSTs; this is what detection content should match on (the multipart filename carrying an absolute path or ..//%2f sequences is the key signal):

Evidence

All evidence below is the actual terminal output of poc_qanything_cve_2026_88533.py (the script in this repository) run against the lab stack built from docker-compose-lab.yaml. No step was faked or simulated — the script exits non-zero unless every check passes, so you can verify the chain end-to-end yourself.

Lab stack — official image + minimal dependencies, all containers healthy:

--mode check — unauthenticated write primitive confirmed: the marker was written outside the upload dir via an absolute-path multipart filename and read back from inside the container:

--mode full — after the container restart, CPython auto-imports the planted sitecustomize.py; the payload's marker proves execution as uid=0(root):

The complete terminal transcript of the --mode full run shown above is also included, verbatim: evidence/full-chain-run-2026-09-18.log — 6/6 checks [OK], verdict RCE CONFIRMED, payload marker proving uid=0(root) with a timestamp (the nonce/kb_id values in the log are randomly generated per run, so your own run will differ — that is expected).

A screenshot of the CVE record page will be added once the record is published.

Timeline

Disclaimer

This material is published for defensive research and educational purposes. Use only against systems you own or have explicit written authorization to test. See DISCLAIMER.md.