# CVE-2024-12868 Source: https://docs.openwebui.com/security/vendor-dispositions/cve-2024-12868 | | | | --- | --- | | CVE ID | CVE-2024-12868 | | 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) | --- > **Resolved: this CVE is rejected** > > 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-12-20 | 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 v0.3.32, the record states that the application depends on a vulnerable version of the `starlette` package through `fastapi`, that `starlette` at or below 0.49 is subject to uncontrolled resource consumption, and that this can be exploited to exhaust memory. It notes that the issue is addressed in `fastapi` 0.115.3. It classifies this as CWE-400 (Uncontrolled Resource Consumption) and scores it CVSS 7.5 (High). The behaviour this record describes belongs to a third-party dependency reached through `fastapi`, and the fix it names is a release of that dependency chain rather than a change to Open WebUI. That is visible from the record's own text and requires no assessment of the claim. > **Reconstructed from the record's version history** > > 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](https://github.com/CVEProject/cvelistV5) repository. --- ## The Claim Is About a Dependency Two things follow from the record's own text, and neither requires assessing the claim. **The behaviour described is not in Open WebUI.** It is attributed to `starlette`, reached through `fastapi`, and the remedy the record names is a release of that dependency chain rather than any change to Open WebUI. A weakness in a library is ordinarily identified against the library that contains it, so that one identifier covers every downstream consumer. Minting a separate identifier against each package that happens to depend on it multiplies one upstream weakness into many records, each of which then circulates against a product whose code was never at issue. **Reachability is never shown.** The record establishes that a vulnerable version is present in the dependency tree and stops there. It names no endpoint, no request, and no path by which the affected code could be driven in Open WebUI as shipped or configured, and it demonstrates no exploitation against the product it was assigned to. A dependency being present in a lockfile is not the same as that dependency being exposed through the application above it. --- ## 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 in `starlette`. 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](/security/supply-chain-security/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. --- ## References - [CVE-2024-12868 on CVE.org](https://www.cve.org/CVERecord?id=CVE-2024-12868) - [NVD Entry](https://nvd.nist.gov/vuln/detail/CVE-2024-12868) - [Open WebUI Security Policy](/security/security-policy)