CVE-2024-7049
| CVE ID | CVE-2024-7049 |
| Vendor Disposition | Rejected, not a vulnerability |
| Published | 2024-10-10 |
| Issuing CNA | huntr / Protect AI (from a bounty report) |
| Claimed Severity | Medium (CVSS 5.4, CVSS:3.0/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:L/A:N) |
The record states that a user awaiting administrator approval receives a token on sign-in and can therefore act without that approval. Receiving the token is intended. Acting without approval is not possible.
The endpoints that carry privilege, chat and completions, the model backends, retrieval, files, chats, memories, and every administrative function, are guarded by a dependency that admits only user and admin, and a pending account is refused by name at each of them. What the record demonstrates is not one of them. A pending account holding a token can confirm who it is, change its own password, and see that it is waiting, which is exactly what the screen it is shown needs in order to render.
The record's own proof of concept shows this. After creating an account and signing in, the single action it performs with the token is a request that changes the account's own display name to hai123333333333333333. That handler takes its target from the authenticated session rather than from the request, and it accepts a display name and an avatar URL and nothing else, so the demonstration is a user renaming themselves.
The record scores that as a confidentiality impact and an integrity impact, at Medium severity, 5.4. Nothing belonging to another party is read, and nothing belonging to the instance is changed. On what the proof of concept establishes, both impact metrics are zero.
Timeline
This CVE is formally disputed. Open WebUI's assessment below is the basis of that dispute, and the record remains published in the meantime.
| Date | Event |
|---|---|
| 2024-07-23 | huntr / Protect AI reserves the identifier. |
| 2024-10-10 | huntr / Protect AI publishes the CVE. |
| 2026-08-18 | Open WebUI publishes this disposition, rejecting the report as not a vulnerability. |
| 2026-08-18 | Open WebUI contacts huntr / Protect AI to dispute the record. |
Disclosure Pathway
This record was never reported to Open WebUI through its published security channel. It does not appear anywhere in Open WebUI's advisory corpus, in any state, and no notification about it was received from huntr / Protect AI at any point before or after the identifier was published.
What the CVE Claims
In Open WebUI v0.3.8, a user whose account is still in the pending role is issued a session token when signing in. The record states that this allows the user to perform actions without administrator confirmation, bypassing the intended approval process. It classifies this as CWE-488 (Exposure of Data Element to Wrong Session) and scores it CVSS 5.4 (Medium).
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.
Approval Is Enforced at Authorization, Not at Token Issuance
The approval step does not work by withholding a credential. It works by naming the two roles allowed to use one. Sending a message, listing the models, uploading a file, opening a chat, storing a memory: each of these checks the caller's role first, and each accepts only an approved user or an administrator. Anything administrative checks again, more strictly.
A pending account's token is accepted as proof of who is calling and then refused at every one of those checks.
Issuing the Token Is Deliberate
Someone who has signed up and is waiting sees a screen telling them so, along with who to contact about it. That screen lives inside the application and has to know whose account it is showing, so the account is signed in while it waits. Take the credential away and there is nothing left to draw the screen with, and the user is bounced to a login form that will accept their password and then bounce them again.
The record reads the credential as the access. Here it buys the waiting room and nothing past it.
The Described Bypass Does Not Occur
An unapproved account cannot start a conversation, cannot see which models exist, cannot upload a document or query one, cannot read or create a chat, cannot reach another account, and cannot change anyone's role including its own. Every one of those is refused before the request does any work. That is the approval control, and the record does not get past it.
What the record demonstrates instead is an account changing its own display name, which the account's owner is entitled to do, on a record nobody else can see, using a credential issued to that same person moments earlier. The reporter created the account, approved nothing, and then changed a field on it that belongs to them. There is no second party anywhere in the demonstration.
The bar this would have to clear is not a high one, and it is worth stating so the disposition is not mistaken for a blanket dismissal of the area. An unapproved account reaching anything outside its own record, a single conversation, one other user's data, one administrative setting, would be a genuine finding and we would treat it as one, because keeping unapproved accounts away from exactly those things is what the approval step is for. Renaming yourself while you wait is not near that line.
CWE-488 Is Misapplied
CWE-488 covers data from one session surfacing in another. The record has one session in it. The credential is minted for the account that just signed in, carries that account's identity and nothing else, and every value in the demonstration, request and response alike, belongs to that same account.
The confidentiality and integrity impacts follow from the classification rather than from anything the record shows.
Applicable Security Policy Rules
- Rule 1: A vulnerability must be a real, exploitable weakness that crosses a security boundary, and it must cross that boundary against a party other than the reporter. Every value the record touches belongs to the account the reporter created.
- Rule 4: A proof of concept must show which boundary was crossed and what the attacker can then do. This one shows an account changing its own display name, and stops there.
- Rule 8: A submitted score must reflect the finding accurately. Confidentiality and integrity impacts are recorded for an action that reads nothing belonging to anyone else and writes nothing outside the caller's own record.
Impact to Users
No action required. Accounts awaiting approval are refused by the authorization checks on every endpoint that carries privilege. The approval process functions as documented.