CVE-2024-12534
| CVE ID | CVE-2024-12534 |
| 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 claim is that an oversized password exhausts the server through hashing. bcrypt hashes only the first 72 bytes of its input by design and discards the rest, so a 72-byte password and a 72-megabyte password cost exactly the same to verify. No work anywhere in the sign-in path scales with the size of the password, and that scaling is the report's entire premise.
The behaviour described is also not Open WebUI's to have. The 72-byte bound is a property of bcrypt, so if it were a defect it would be a defect in bcrypt rather than in this project. The record is published against Open WebUI as a High-severity denial of service, scored 7.5, for an effect its own stated mechanism cannot produce.
The behaviour that refutes this is documented behaviour of the hashing library the report itself names, and it holds in every version that has ever shipped. The record was nonetheless minted, scored 7.5 High, 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
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 sign-in endpoint is claimed to lack length validation on the email and password fields, so an attacker could submit very large payloads to exhaust resources and render the service unavailable without authenticating. The record classifies this as CWE-400 (Uncontrolled Resource Consumption) and scores it CVSS 7.5 (High).
Why This Is Not a Vulnerability
Nothing below rests on how Open WebUI draws its threat model, on configuration, or on where a security boundary is placed. It rests on what the cited code does, in the affected version as published, and it would hold under any threat model at all.
The report's premise is factually incorrect. Submitting a large email or password does not cause resource exhaustion, because no step of the sign-in path performs work that scales with the size of either field.
The Password Is Capped at 72 Bytes Before Any Work
Password verification uses bcrypt. By design, bcrypt hashes only the first 72 bytes of its input and ignores everything after: a 72-byte password and a 72-megabyte password cost exactly the same to verify. The length of the submitted password is therefore irrelevant to the work performed, and there is nothing for a large password to exhaust. Current releases go further and reject passwords over 72 bytes outright, before any hashing, so an oversized password is refused rather than processed.
The report rests on a larger password meaning more hashing work. The hashing step reads a fixed number of bytes and discards everything after them, so the size of what was sent never reaches it.
An Unknown Email Does Constant Work
For an email that matches no account, the sign-in path does not hash anything against attacker-supplied data. It performs a single verification against a fixed placeholder hash, a constant-time measure that exists to avoid leaking account existence, and returns. No per-attempt work scales with the payload. The email lookup itself is one indexed database query; it does not do work proportional to the length of a multi-megabyte string, and an oversized email simply matches no row.
There Is No Denial of Service to Describe
Every path in sign-in performs constant or input-independent work, regardless of how large the submitted values are. There is no amplification, and there is no resource consumption that grows with the payload at all. This is not a low-severity finding, and it is not a defence-in-depth gap: the mechanism the report depends on, server work that scales with input size, does not exist in the code. The denial of service the report describes cannot occur.
CWE-400 Is Misapplied
CWE-400 (Uncontrolled Resource Consumption) requires an attacker-controlled, unbounded quantity of work. Here every path is bounded independently of payload size: bcrypt's 72-byte cap makes password length irrelevant, an unknown email performs a single constant placeholder verification and returns, and the email lookup is one indexed query. There is no uncontrolled consumption to point to.
Severity
Because the described resource exhaustion does not occur, no CVSS score applies. The 7.5 (A:H) rating asserts an availability impact the mechanism cannot produce: no code path in sign-in scales its work with the size of the email or the password.
Applicable Security Policy Rules
- Rule 1: A vulnerability must be a real, exploitable weakness. The reported resource-exhaustion denial of service does not exist: the password hashing bounds its own input at a fixed size, an unknown email address does the same constant amount of work every time, and no sign-in path scales with the size of what was sent.
- Rule 3: Reports must reflect an understanding of the affected components. The size limit the record trips over is documented behaviour of the password-hashing function the report itself names, so the property described belongs to that library rather than to this project, and it is the very thing that makes the described attack impossible.
- Rule 8: A submitted score must reflect the finding accurately. The record asserts a full loss of availability, but no step of the sign-in path does work that grows with the size of the submitted values, so there is no availability impact to score.
Impact to Users
No action required. Sign-in performs bounded work regardless of payload size: bcrypt hashes only the first 72 bytes of a password (and current releases reject longer ones), and an unknown email performs a single constant-time placeholder verification. An oversized sign-in payload cannot exhaust server resources, because no part of the sign-in path does work proportional to the size of the values submitted.