CVE-2024-7999
| CVE ID | CVE-2024-7999 |
| Vendor Disposition | Withdrawn by the issuing CNA. Never disclosed to Open WebUI. |
| Published | 2025-03-20 |
| Withdrawn | 2025-04-15 |
| 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 record carries the REJECTED state on cve.org, and NVD and downstream feeds inherit it. The issuing CNA withdrew it on its own initiative. There is no advisory and no affected Open WebUI release.
Timeline
This record was assigned, published and withdrawn without Open WebUI being told at any stage. It is documented here because it was published for twenty-six days before the CNA withdrew it, and because the corresponding report is still presented as valid on the CNA's platform today.
| Date | Event |
|---|---|
| 2024-08-19 | huntr / Protect AI reserves the identifier. Open WebUI is not contacted. |
| 2025-03-20 | huntr / Protect AI publishes the CVE. No report on this subject was filed through the project's official reporting channel (GitHub Security Advisories), and no notification of the assignment reached the project. |
| 2025-04-15 | huntr / Protect AI withdraws the record on its own initiative, twenty-six days after publication, as part of a batch that also covered records against other projects. Open WebUI is not notified of the withdrawal either. |
| 2026-08-14 | Open WebUI establishes that the record exists, by reconstructing it from the version history of the CVE Program's record repository. Its description and references had been stripped on rejection, so it is not discoverable through the CVE Record or NVD. |
| Still open | The huntr report page has not followed the withdrawal. Sixteen months after the CNA withdrew the record, the report is still shown as Valid with a green check and its status as "Awaiting fix". |
| 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 in the REJECTED state on cve.org. 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 prior to publication, and the project received no notification of the assignment, of the publication, or of the withdrawal.
What the CVE Claimed
In open-webui at commit 79778fa, an attacker is claimed to be able to cause a denial of service by uploading a file with a malformed multipart boundary. The record states that appending a large number of characters to the end of the boundary makes the server process each character in turn, rendering the application inaccessible to every user until it recovers. It classifies this as CWE-400 (Uncontrolled Resource Consumption) and scores it CVSS 7.5 (High).
The record identifies the affected version only as a commit hash, with the affected range given as <= latest.
The description, references and metrics above are not visible on the current record. They are stripped when a record is rejected. The text summarised here was recovered from the pre-rejection revision in the CVE Program's cvelistV5 repository.
Open WebUI's Position
Open WebUI has not assessed this claim on its merits, and takes no position here on whether the behaviour it describes was real. The record was withdrawn by its own issuing CNA before the project knew it existed, so there was never an occasion to examine it.
What this page records is the handling, on two points.
The record was assigned and published without contact. Open WebUI's security policy designates GitHub Security Advisories as the sole reporting channel, and that channel was in active use throughout the period: unrelated researchers reached the project through it repeatedly in these same months. No report on this subject arrived through it, and no notification of the assignment reached the project by any other route. The project learned of the identifier sixteen months after it was withdrawn, and only by reconstructing it from the CVE Program's own repository.
The withdrawal has not reached the CNA's platform. The record has carried the REJECTED state since 2025-04-15. The corresponding report on the issuing CNA's platform is still published, still marked Valid, and still shows its status as "Awaiting fix". "Awaiting fix" is a statement about this project's remediation posture, made about a record its own issuing CNA has withdrawn, by a party the project cannot correct.
The practical consequence is that publication is not undone by withdrawal. An identifier that is live for twenty-six days is ingested downstream in that window, and a proportion of those consumers never process the rejection. Where a downstream database treats the CNA's platform as authoritative, it finds a report still presented as valid and awaiting a fix. See Rejected CVEs in Vulnerability Databases for how withdrawn identifiers continue to circulate.
Impact to Users
No action required. The record is rejected, there is no advisory, and no Open WebUI release is affected by it.