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.
This is not a subtle finding that reasonable reviewers could differ on. The behaviour that refutes it is documented behaviour of the hashing library the report itself names, and it refutes it in a single line. A record was nonetheless minted, scored 7.5 High, and published against this project, where it has stood for over a year.
Timeline
Open WebUI rejects this record as not a vulnerability; the assessment below is the project's official position. The issuing CNA has not responded and has not acted on the record, so the dispute has been escalated to the CVE Program Root.
| 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. |
As of 2026-08-08, the record is still in the PUBLISHED state on cve.org and the dispute is before the CVE Program Root. This disposition stands as Open WebUI's official assessment.
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
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's central assumption, that a larger password means more hashing work, is simply false. The hash function bounds its own input, so password length cannot drive resource consumption.
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: bcrypt bounds password work to 72 bytes, an unknown email does constant work, and no sign-in path scales with payload size.
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.