CVE-2024-7045
| CVE ID | CVE-2024-7045 |
| Vendor Disposition | Rejected, not a vulnerability |
| Published | 2025-03-20 |
| Issuing CNA | huntr / Protect AI (from a bounty report) |
| Claimed Severity | Medium (CVSS 4.3, CVSS:3.0/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N) |
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 the dispute was escalated to the CVE Program. 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-22 | Open WebUI publishes this disposition, rejecting the report as not a vulnerability. |
| 2026-07-22 | Open WebUI contacts huntr / Protect AI directly to dispute the record. |
| 2026-08-03 | Open WebUI follows up with huntr / Protect AI. No response is received and the record is unchanged. |
| 2026-08-08 | With no response from huntr / Protect AI, Open WebUI escalates this record to the CVE Program Root. |
| 2026-08-12 | The CVE Program opens a formal dispute with huntr / Protect AI under CVE Program Rule 4.1 (Vulnerability Determination) and requests the CNA's response. |
| 2026-08-12 | huntr / Protect AI replies to the CVE Program and agrees to withdraw the record. |
| 2026-08-13 | Officially rejected The record is updated on cve.org. 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-14 | With the report status unchanged, 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.
Disclosure Pathway
No report corresponding to this CVE was filed through the project's official reporting channel (GitHub Security Advisories) prior to publication.
What the CVE Claims
In Open WebUI v0.3.8, the endpoints GET /api/v1/prompts/ and GET /api/v1/prompts/command/{command} return prompt data to any authenticated (verified) user without verifying that the caller is an administrator. The report states that a verified user can list every prompt (including its command identifier) through /api/v1/prompts/, then read any prompt's content through /api/v1/prompts/command/{command}. The record classifies this as CWE-862 (Missing Authorization) and scores it CVSS 4.3 (Medium).
Why This Is Not a Vulnerability
In this version, prompts are a global, instance-wide shared resource by construction. The Prompt schema is command, user_id, title, content, timestamp. There is no access_control field, no public/private flag, and no per-prompt sharing model. There is therefore nothing private to leak: every prompt is a shared slash-command template intended to be invoked by all users in chat. Reading the prompt list and a prompt's content is the feature, it is how a user picks and runs a command such as /summarize in the message composer.
Read Is Intended, Only Mutation Is Restricted
The design is deliberate, and the only restriction it defines is enforced. Any signed-in user can see the list of shared prompts and read the text of one. Writing a new prompt, changing an existing one and deleting one each require an administrator, and each is refused for everyone else. Administrators write the shared commands, and every other user picks one from the message box and runs it.
Administrators author shared prompts, and every verified user reads and uses them. The report's claim that "the application does not verify whether the attacker is an administrator" describes intended behavior: read access was never administrator-gated, only creation and editing were, and that check is present and enforced.
CWE-862 Is Misapplied
CWE-862 (Missing Authorization) describes a resource that should be gated by an authorization check but is not. Read access to shared prompts is intentionally available to verified users; no authorization control is missing or being bypassed. The report asserts an administrator-only read restriction that was never part of the design, on a resource that is shared by construction. Nor is there any per-prompt isolation model that could be "insufficiently" enforced: in this version prompts are global, so there is no isolation boundary to violate.
Severity
Because this is intended, documented shared-workspace behavior, no CVSS score applies to it. Separately, and only if the record is scored at all, the C:L confidentiality impact overstates it: the data returned is a shared slash-command template that every verified user is meant to read and run.
Applicable Security Policy Rules
- Rule 1: Expected, documented shared-workspace behavior is not a vulnerability. Prompts are shared by design; only their creation and editing is restricted, and that restriction is enforced. No security boundary is crossed.
- Rule 3: Reports must reflect an understanding of the affected components. The record assumes each prompt belongs to whoever created it, when in the version cited prompts are one shared set with no private or per-owner concept at all, so there is nothing for the endpoints to expose.
- Rule 7: Administrator-created shared prompts being readable by authenticated peers is intended collaboration in a self-hosted, single-trust-domain instance, not an authorization flaw. There is no per-prompt isolation model in the product to violate.
- Rule 8: A submitted score must reflect the finding accurately. The record claims a loss of confidentiality over material every signed-in user is meant to read and run, so there is no confidential information for the described disclosure to affect.
Impact to Users
No action required. In this version, prompts are shared slash-command templates that every verified user can read and invoke by design; only their creation and editing is restricted to administrators, and that restriction holds. There is no private-prompt concept in this schema for the cited endpoints to expose.