CVE-2024-7990
| CVE ID | CVE-2024-7990 |
| Vendor Disposition | Rejected, not a vulnerability |
| Published | 2025-03-20 |
| Issuing CNA | huntr / Protect AI (from a bounty report) |
| Claimed Severity | High (CVSS 8.4, CVSS:3.0/AV:N/AC:L/PR:H/UI:R/S:C/C:H/I:H/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.8, the description field submitted to POST /api/v1/models/add is claimed to be rendered in chat without sanitization, so a stored script payload would execute for any user who views it, including administrators. The record classifies this as CWE-79 (stored cross-site scripting) and scores it CVSS 8.4 (High).
Why This Is Not a Vulnerability
The report is wrong on two independent grounds, each sufficient on its own, and both are verifiable in the code.
The Field Is Admin-Only
POST /api/v1/models/add and POST /api/v1/models/update require Depends(get_admin_user). A non-administrator cannot create or edit a model, and therefore cannot set the description field at all. The report's premise that "an attacker can inject" a payload is false: only an administrator can write this field. The record's own CVSS vector concedes this with PR:H (high privileges required). Administrator-authored content rendering inside the administrator's own single-trust-domain, admin-governed instance is administrator authority, not a cross-privilege scripting vulnerability.
The Output Is Escaped Anyway
Even setting access control aside, the chat render path passes the value through sanitizeResponseContent, which entity-escapes < and > (.replaceAll('<', '<').replaceAll('>', '>')). A <script> payload is rendered as inert text, never executed. The claimed script execution does not occur.
CWE-79 Does Not Hold
Stored cross-site scripting requires input that an attacker can control reaching a page unescaped. Here the input is not attacker-controllable (it is admin-only) and it is escaped on output. Neither condition of CWE-79 is met.
Severity
Because the field is administrator-only and the output is escaped, no CVSS score applies. The record's own PR:H already concedes that only an administrator can reach the field, and the 8.4 (High) with S:C/C:H/I:H/A:H describes an impact that cannot occur.
Applicable Security Policy Rules
- Rule 1: Expected behavior. Administrator-authored, output-escaped content crosses no security boundary.
- Rule 3: Reports must reflect an understanding of the affected components. The record describes an ordinary user injecting a script into a model's description, when only an administrator can write that field and the chat view escapes the characters a script needs before displaying it, so neither half of the described mechanism matches the software.
- Rule 7: Reports must reflect an understanding of the role-based, single-trust-domain architecture. Text an administrator writes into their own instance and that the instance's own users then see is the administrator exercising authority they already hold, not one user attacking another.
- Rule 8: A submitted score must reflect the finding accurately. The record's own privileges metric concedes that only an administrator can reach the field, yet it is scored as a high-severity loss of confidentiality, integrity and availability reaching beyond the application, an impact the described mechanism cannot produce.
- Rule 9: Setting a model description is an administrator action, and administrator actions are out of scope.
Impact to Users
No action required. The model description field is writable only by administrators, and its content is entity-escaped before rendering, so the reported script injection cannot occur.