CVE-2024-7039
| CVE ID | CVE-2024-7039 |
| Vendor Disposition | Rejected, out of scope; severity inflated |
| 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 | High (CVSS 8.3, CVSS:3.0/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:L) |
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; severity inflated. |
| 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 "Delete administrators", claims an incorrect-authorization issue: an attacker, in its own words "acting as an admin", can delete other administrators through DELETE /api/v1/users/{user_id}. Its reasoning is that because the interface shows a "The requested action has been restricted as a security measure" notice and hides the delete control for an administrator account, administrators are meant to be undeletable, so removing one through the API is an authorization bypass. It is classified as CWE-863 (incorrect authorization) and scored PR:L (8.3 High).
Why This Is Out of Scope
The endpoint, DELETE /api/v1/users/{user_id} (the delete_user_by_id 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. The report's own description confirms the actor is "acting as an admin".
Deleting Administrators Is Intended Functionality
Managing accounts is a core administrative function. Administrators can create users, edit them, change their roles and remove them, including other administrators. This is intended and necessary for account lifecycle, offboarding and recovery. The admin interface shows delete controls for administrator accounts and always has: removing an administrator is a normal, supported action. The report's premise, that administrators are meant to be undeletable and the interface enforces this, does not match how the product works.
The Primary Admin Is a Safety Affordance, Not a Boundary
The one account the interface does not offer to delete is the first administrator to register, the primary admin. This account is identified purely by timestamp: it is the earliest-created user (get_first_user, ordering by created_at). In the reported version (v0.3.8) that protection was UI-level, so the primary admin could still be removed through the API. The current code additionally enforces it server-side, returning 403 for the first user, to prevent accidental removal.
That is a safety affordance, not a security boundary. Removing the primary admin is sometimes a legitimate operational need, for example when the person who first stood up the deployment leaves the organization, so the account must stay removable, and it does. An administrator can remove the primary admin through any capability they already hold:
- Server access: act on the host or container directly.
- Database access: delete the account's rows from the
userandauthtables. - A Function: read
DATABASE_URLfrom the environment, connect to the database and delete the account. - A custom routine: reimplement the deletion the endpoint already performs without the first-user check, and run it as a Function.
The server-side 403 only stops a one-click accidental deletion of the bootstrap account, and the unwanted admin re-assignment that could follow from it. It does not, and cannot, stop an administrator who intends to remove the primary admin. The handler otherwise enforces only that an administrator cannot delete their own account (if user.id != user_id), a guard against self-lockout.
No Security Boundary Exists Between Administrators
The same holds for any administrator, not only the primary one. Administrators share a single trust boundary, and any of them can remove or take over any other through capabilities every administrator holds: database access, Tools and Functions and server access. Enforcing "administrators cannot delete administrators" would be a cosmetic control over a boundary that does not exist, a false sense of separation rather than real isolation. This is the same disposition as CVE-2024-7040, where both parties are likewise administrators of one instance.
CWE Mismatch and Inflated Severity
CWE-863 (incorrect authorization) does not apply. The endpoint's only access control is Depends(get_admin_user), and that check is enforced correctly: it passes for the requesting administrator, as intended. No authorization control is bypassed. The report describes an expectation that a boundary should exist between administrators, which it never did, not the bypass of an existing one.
The published CVSS scores privileges required as PR:L (low), inflating the base score to 8.3 (High). This contradicts the report's own text ("acting as an admin"): the action requires an administrator, so the accurate value is PR:H. Corrected, it does not reach High severity.
Applicable Security Policy Rules
- Rule 9: The action requires an administrator, and the target is a peer administrator within the same trust boundary. Administrators have full system control.
- Rule 8: The CVSS vector is inaccurate. PR:L contradicts the report's own "acting as an admin" description; the correct privilege requirement is PR:H.
- Rule 7: The report does not account for Open WebUI's self-hosted, multi-administrator architecture in which administrators share trust at the infrastructure level.
Impact to Users
No action required. If your deployment has multiple administrators, be aware that administrators share a trust boundary and can manage each other's accounts, including removing them. This is inherent to the administrator role, consistent with how comparable self-hosted systems handle shared administrative access. See CVE-2024-7040 for the recommended practice of separating admin accounts from day-to-day user accounts.