CVE-2024-7036
| CVE ID | CVE-2024-7036 |
| Vendor Disposition | Rejected, not a vulnerability |
| Published | 2025-03-20 |
| Issuing CNA | huntr / Protect AI (from a bounty report) |
| Claimed Severity | High (CVSS 7.5, CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/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 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, an unauthenticated attacker is claimed to be able to sign up with excessively large text in the name field, causing the admin panel to become unresponsive. The record classifies this as CWE-400 (Uncontrolled Resource Consumption) and scores it CVSS 7.5 (High).
Why This Is Not a Vulnerability
The name field is stored verbatim as a string. The server performs no amplifying work on it: it is written to the database and read back. There is no server-side resource-exhaustion primitive, and no server denial of service occurs.
There Is No Denial of Service
The name value is stored and served as an ordinary string, so nothing on the server is exhausted and no denial of service occurs. The report's claim that the admin panel becomes unresponsive does not describe any server-side condition: the server, its API, and every other user are unaffected. At most it refers to how a browser renders a very long value in a list, which is a characteristic of the browser and not a security weakness in Open WebUI.
Signup Is Governed by a Setting
Self-registration is gated by ENABLE_SIGNUP (ui.enable_signup). Once an instance has users, signup is reachable only when the administrator has enabled it, so the "unauthenticated" reach the report relies on is itself a configuration the administrator opts into.
CWE-400 Is Misapplied
Uncontrolled resource consumption requires unbounded server-side work. Storing a string is bounded work, and the observed slowdown is browser-side rendering of an oversized value, not server resource consumption.
Applicable Security Policy Rules
- Rule 1: Storing a string is bounded server-side work and the observed effect is client-side rendering rather than a server denial of service. No security boundary is crossed.
- Rule 3: Reports must reflect an understanding of the affected components and their impact. The record presents the administration screen becoming slow as server-side resource exhaustion, when the value is only stored and served back and the slowdown is how a browser draws an unusually long piece of text.
- Rule 6: Findings must reproduce on the out-of-the-box configuration. The unauthenticated reach the record depends on exists only while the administrator leaves self-registration switched on, which is a setting they control.
Impact to Users
No action required. The name field is stored as-is with no server-side amplification, and no denial of service occurs. How a browser renders a very long value is a front-end characteristic, not a security weakness, and self-registration is governed by the ENABLE_SIGNUP setting.