CVE-2024-12537
| CVE ID | CVE-2024-12537 |
| 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.32, the api/v1/utils/code/format endpoint is claimed to lack authentication, so an unauthenticated attacker sending excessive content in a POST request could render the server unresponsive and deny service to other users. The record classifies this as CWE-770 (Allocation of Resources Without Limits or Throttling) and scores it CVSS 7.5 (High).
Why This Is Not a Vulnerability
The endpoint formats submitted source code with black.format_str. The work is linear in the size of the submitted code: there is no algorithmic amplification, no quadratic blow-up, and no allocation beyond the input the attacker themselves transmitted. Sending a large body costs the attacker the same bandwidth it costs the server to process, and it is bounded by the request-size and rate limits of the reverse proxy that any production deployment is expected to run in front of the application.
Every endpoint that reads a request body spends effort in proportion to what the sender transmitted. The attacker pays in bandwidth what the server pays in processing, one for one, and the request-size and rate limits any production deployment runs in front of the application bound both. Naming one endpoint as the source of a denial of service describes what accepting a request costs.
The endpoint is also no longer unauthenticated. Current releases place it behind authentication (it requires an administrator), so the unauthenticated reach the report relies on no longer exists.
CWE-770 Is Misapplied
CWE-770 describes allocation without limits, typically an attacker-controlled multiplier that consumes disproportionate server resources. Here the resource use is linear in and bounded by the attacker's own request, with no multiplier, and is further bounded by the deployment's ingress limits. There is no uncontrolled allocation.
Applicable Security Policy Rules
- Rule 1: A linear, self-bounded operation, where processing costs the server exactly what sending it cost the attacker, crosses no security boundary and is not a vulnerability.
- Rule 7: Reports must reflect an understanding of the self-hosted deployment model. The cost described is the ordinary one-for-one cost of accepting a request, which the operator bounds with the request-size and rate limits any production deployment runs in front of the application.
Impact to Users
No action required. Processing a request costs work proportional to the request, symmetrically, for this endpoint as for every endpoint; there is no amplification and no denial of service. The endpoint now requires authentication, and standard reverse-proxy request-size and rate limits bound request handling across your deployment.