CVE-2024-7046
| CVE ID | CVE-2024-7046 |
| 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) |
GET /api/v1/auths/admin/details exists to tell a user awaiting approval who to contact in order to get approved. Non-administrators are its entire purpose. It returns two fields, the instance owner's display name and contact email, and it returns them only while the administrator has SHOW_ADMIN_DETAILS switched on. With that setting off the endpoint returns HTTP 400 and discloses nothing.
Restricting it to administrators, as the report asks, would remove its only function and leave pending users with no way to reach the person who can approve them. Nothing is bypassed: the data is published deliberately, through a dedicated toggle, to the audience it was built for.
The endpoint returns a name and an email address that an administrator opted to publish, to the users it exists to serve. The record was nonetheless minted, scored 4.3 Medium as missing authorization, and published against this project, where it has stood for over a year.
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
A report filed through our GHSA channel on 2024-10-10 mentions this endpoint, but only in passing under "Additional info"; its subject was role manipulation at login. The CVE ID for this record had already been reserved on 2024-07-23, before that report reached us.
What the CVE Claims
In Open WebUI v0.3.8, the endpoint GET /api/v1/auths/admin/details returns the instance owner's details without verifying that the caller is an administrator, so any authenticated user can call it and retrieve the first administrator (owner) account's details. The record classifies this as CWE-862 (Missing Authorization) and scores it CVSS 4.3 (Medium).
Why This Is Not a Vulnerability
The endpoint exists to show the instance owner's contact details to the instance's users, so that someone waiting for approval knows who to ask. The people who call it are the ones waiting to be approved, and the name and address it returns are what the waiting screen puts in front of them. Restricted to administrators, it would answer nobody who has a reason to ask, and a user waiting for approval would be shown a screen with no way to reach the person who can approve them.
It Returns Only Contact Information, and Only When the Admin Intends It
The handler returns exactly two fields, the administrator's display name and email, and nothing else. No credentials, tokens, roles, session data, configuration, or any other user's data are exposed. Those two fields are the owner's contact details, and surfacing them when the feature is enabled is the entire point: a pending user needs a way to reach whoever can approve their account, and this endpoint is that way. Exposing the owner's contact point to the users who need it is the feature, not a leak.
The disclosure is gated by the SHOW_ADMIN_DETAILS setting (auth.admin.show). When an administrator turns it off, the endpoint returns HTTP 400 and discloses nothing at all. Whether the owner's contact details are visible is therefore a per-instance configuration decision that the administrator controls, not a flaw. Configuration options and expected behavior are not vulnerabilities.
The Data Is a Contact Primitive, Not a Secret
The "attacker" in this report is an authenticated user of the same self-hosted instance, and the "victim" is the instance owner whose contact email the administrator has chosen to publish. In Open WebUI's single-trust-domain, authenticated, role-based model, showing the owner's name and contact email to that instance's own authenticated users is a collaboration and contact primitive, not a data breach. Treating it as one misreads the architecture.
CWE-862 Is Misapplied
CWE-862 (Missing Authorization) describes a resource that should be gated by an authorization check but is not. That is not what this endpoint is. It requires an authenticated session (Depends(get_current_user)) and then returns data the administrator has explicitly opted to publish via SHOW_ADMIN_DETAILS. No authorization control is being bypassed.
The report does not describe the bypass of an existing control. It asserts that an administrator-only check should exist on an endpoint that is deliberately not administrator-only, precisely because its function is to serve non-administrators. An expectation that a control should exist where one was never intended is not CWE-862.
Severity
Because this is intended, administrator-controlled 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 only data returned is a display name and a contact email that the administrator has chosen to expose through a dedicated toggle, and when that toggle is off the endpoint returns nothing.
Applicable Security Policy Rules
- Rule 1: Configuration options and expected behavior are not vulnerabilities. The endpoint exposes the owner's contact details by design, under an administrator-controlled setting, and crosses no security boundary.
- Rule 3: Reports must reflect an understanding of the affected components. The record asks for an administrator-only check on an endpoint whose entire purpose is to answer users who are not administrators, so the control it says is missing would remove the feature rather than fix anything.
- Rule 7: The report treats authenticated-user visibility of the owner's contact details in a self-hosted, single-trust-domain instance as a data-exposure flaw, which misreads the project's architecture.
- Rule 8: A submitted score must reflect the finding accurately. The record claims a loss of confidentiality over a display name and a contact address the administrator chose to publish through a dedicated setting, and which the instance already shows on its waiting-for-approval screen.
Impact to Users
No action required. The endpoint returns only the administrator's display name and contact email, and only when SHOW_ADMIN_DETAILS is enabled. If you do not want the owner's contact details visible to authenticated users of your instance, set SHOW_ADMIN_DETAILS to false (auth.admin.show), and the endpoint will disclose nothing.