CVE-2024-7033
| CVE ID | CVE-2024-7033 |
| Vendor Disposition | Rejected, out of scope |
| Official Resolution | Withdrawn by the issuing CNA on 2026-07-16; the record is REJECTED |
| Published | 2025-03-20 |
| Issuing CNA | huntr / Protect AI (from a bounty report) |
| Claimed Severity | Medium (CVSS 6.5, CVSS:3.0/AV:N/AC:L/PR:H/UI:N/S:U/C:N/I:H/A:H) |
The issuing CNA has withdrawn the record, so the official CVE entry now carries the REJECTED state and NVD and downstream feeds inherit it. The public record now matches Open WebUI's vendor disposition below, confirming our assessment that this was not a genuine vulnerability. There is no advisory and no affected Open WebUI release.
Timeline
This CVE was withdrawn by its issuing CNA after review. Open WebUI's assessment below is the basis on which the record was rejected.
| Date | Event |
|---|---|
| 2025-03-20 | huntr / Protect AI publishes the CVE. |
| 2026-07-08 | Open WebUI publishes this disposition, rejecting the report as out of scope. |
| 2026-07-08 | Open WebUI contacts huntr / Protect AI directly to dispute the record. |
| 2026-07-16 | Officially rejected huntr / Protect AI accepts the dispute and withdraws the record. The CVE record is now officially REJECTED. |
| Still open | The huntr report page has not followed the withdrawal. The report is still shown as Valid with a green check and its status as "Awaiting fix", while the CVE field on the same page reads Rejected. |
| 2026-08-08 | Open WebUI asks huntr / Protect AI to bring the report validity and fix status in line with the withdrawal, and to make those fields follow CVE state transitions so it does not recur. Awaiting response. |
| 2026-08-14 | With huntr / Protect AI unresponsive on that request, Open WebUI raises the matter with the CVE Program, asking that records withdrawn by the CNA no longer be presented as valid and awaiting a fix. CNA Rule 4.5.2.3 states that a CNA's published vulnerability information "MUST generally support and MUST NOT contradict information published by the CNA in corresponding CVE Records". |
The record is now in the REJECTED state on cve.org, and that state propagates to NVD and downstream feeds. No action is required from users, and the CVE should not be treated as an Open WebUI vulnerability.
What the CVE Claims
The report, titled "Arbitrary File Write leading into Remote Code Execution when deployed in Windows", concerns the model-download endpoint. It explains that the endpoint downloads a file from a URL on an allowed host (huggingface.co), derives the destination filename from the URL path by splitting on / only, and writes it to file_path = f"{UPLOAD_DIR}/{file_name}". Because backslashes are not handled, on a Windows host an administrator can submit a URL whose path contains \..\ sequences (the proof of concept uses https://huggingface.co/.../main/\..\..\..\..\..\WINDOWS\Temp\pwned) and have the download written outside UPLOAD_DIR to an arbitrary path. The report argues this can overwrite system files and be escalated to remote code execution. It is classified as CWE-29 (path traversal, \..\filename).
Why This Is Out of Scope
The endpoint, POST /ollama/models/download (the download_model handler), is gated by Depends(get_admin_user). Only an administrator can call it. This was true in the reported version (v0.3.8) and remains true today, and it applies only to Windows deployments. The report's own CVSS vector scores this as PR:H (high privileges required): the party in the scenario is an administrator.
What This Actually Is
The traversal is in the URL the administrator supplies, not in a model that acts on its own. The host allowlist on this endpoint exists to keep downloads pointed at the intended model source, guarding against an administrator fetching from an unintended host or a mistyped one; it constrains which host the request reaches, not where the downloaded bytes land, and was never a filesystem-write boundary. It checks only the URL prefix (https://huggingface.co/), and the filename is taken from the URL path split on /, so backslash sequences placed after the allowed prefix survive into the filename and, on Windows, resolve as path separators. The bytes written come from whatever repository the administrator points the request at (the proof of concept uses a repository the reporter created for the purpose). In plain terms, an administrator crafts a request that writes chosen content to a chosen path on the server they operate. A normal model download from a normal URL writes into UPLOAD_DIR as intended; the escape happens only when the administrator places traversal sequences in the URL themselves.
An Administrator Already Has This Capability
An administrator operates the server and already has arbitrary file write and arbitrary code execution on it, directly (shell, container or host access) and through the application: installing Tools and Functions runs arbitrary Python on the server by design (see Rule 10). Writing a file to an arbitrary path through a crafted download URL grants an administrator nothing they cannot already do in one line, and the report's escalation to "remote code execution" is circular, because an administrator already has code execution on the instance as a designed feature. Even in the variant where an administrator is tricked into submitting a crafted URL, that is social engineering of an administrator, which is out of scope, and it still yields only what the administrator already controls. There is no path by which an unprivileged user reaches this endpoint.
Applicable Security Policy Rules
- Rule 9: The action requires an administrator, or, in the tricked-admin variant, social engineering of an administrator. Administrators have full system control, including server-level file access and code execution.
- Rule 10: The "remote code execution" the report escalates to is functionality administrators already have. Running code on the server via Tools and Functions is intended behavior.
- Rule 7: The report does not account for Open WebUI's self-hosted, role-based architecture, in which administrators are trusted operators of the server.
Impact to Users
No action required. The endpoint is reachable only by administrators, applies only to Windows deployments, and grants no capability an administrator does not already have on the server they operate. There is no exposure to unprivileged users.