# CVE-2024-7806 Source: https://docs.openwebui.com/security/vendor-dispositions/cve-2024-7806 | | | | --- | --- | | CVE ID | CVE-2024-7806 | | Vendor Disposition | Rejected, not a vulnerability | | Published | 2025-03-20 | | Issuing CNA | huntr / Protect AI (from a bounty report) | | Claimed Severity | High (CVSS 8.0, CVSS:3.0/AV:N/AC:L/PR:L/UI:R/S:U/C:H/I:H/A:H) | > **The cookie policy the record blames is the thing that blocks the attack** > > The record states that remote code execution is available to non-admin users because the session cookie is set to `SameSite=Lax` and no CSRF token is present. `SameSite=Lax` sends the cookie only on top-level navigations using a safe method. It withholds the cookie on cross-site `POST`, which is the only method the endpoints in question accept. The property cited as the cause of the vulnerability is the property that prevents it. > > > > The privilege claim is also wrong in the opposite direction. Every pipeline endpoint in the affected version requires an administrator, so a cross-site request against one needs an administrator victim, and a non-admin's session receives an authorization error. The proof of concept does use an ordinary account, but only in the attacker's own browser, to read the id of an existing pipeline. The privileged action is performed by the administrator's browser, and the ordinary account confers no privilege on it. The record's `PR:L` scores the reconnaissance rather than the attack. > > > > Neither point requires interpretation. The method each endpoint accepts and the authorization dependency each one carries are both visible in the source of the version named in the record. The proof of concept refutes itself on the first point: the page it builds submits an ordinary HTML form by `POST` from another site, which is precisely the request the stated cookie policy strips the credential from. What arrives at the server is an unauthenticated upload, and it is refused. > > > > The record is published at High severity, scored 8.0, as remote code execution obtainable by an ordinary user. --- ## 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-08-14 | huntr / Protect AI reserves the identifier. | | 2025-03-20 | 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 versions up to and including v0.3.8, a non-administrator is claimed to achieve remote code execution through cross-site request forgery. The record states that the application authenticates with a cookie carrying `SameSite=Lax` and issues no CSRF token, so that a page controlled by an attacker can cause a victim's browser to modify the Python code of an existing pipeline and execute arbitrary code. The record classifies this as CWE-352 (Cross-Site Request Forgery) and scores it CVSS 8.0 (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. ### The Endpoints Are Administrator-Only Listing pipelines, installing one, removing one, changing one's settings: every one of these checks that the caller is an administrator before doing anything, and refuses everyone else. In the version the record names there is no pipeline operation an ordinary user can perform at all. A cross-site request is sent by the victim's browser, so it carries the victim's privileges and not the attacker's. Against an administrator-only endpoint that means the victim must be an administrator. The record does not say so, and does not score it. ### `SameSite=Lax` Prevents the Request the Attack Requires `SameSite=Lax` permits the cookie on top-level navigations using a safe method, and withholds it on cross-site `POST`, on sub-resource requests, and on cross-site `fetch` regardless of method. Every pipeline endpoint that submits or alters pipeline code accepts `POST` only, taking either a multipart upload or a JSON body. Neither shape can carry the cookie from an attacker's page. An HTML form can produce a cross-site multipart `POST`, but the method alone causes the browser to omit the cookie. A JSON body cannot be produced by an HTML form at all, and a cross-site `fetch` receives no cookie under `Lax` even when credentials are requested. The request arrives unauthenticated and is rejected. The frontend does not rely on the cookie in the first place: it holds the session token and sends it as an `Authorization` header, which a page on another origin can neither read nor attach. The distinction that decides this is whether the cookie carries the attribute explicitly. Browsers apply a temporary allowance that lets a recently issued cookie accompany a top-level cross-site `POST`, and that allowance exists only for cookies on which no `SameSite` attribute was set, where the browser supplied the default itself. Open WebUI's cookie carries the attribute in the response header, so the allowance never applies to it and there is no interval after sign-in during which the described request would succeed. The report's cited line range is also worth noting. It points at a block of HTTP middleware definitions containing no pipeline handler, no authentication and no cookie handling, and reads as the place where the reporter's suggested fix would be inserted rather than as the code the claim rests on. ### The Code Would Not Execute in Open WebUI Open WebUI receives the file, holds it briefly, sends it on to whichever server the administrator registered to run pipelines, and deletes its own copy. It never opens the file, never imports it, and never runs it. The code in the report would run on the other machine. The proof of concept sends it to whatever occupies the first connection slot, and that slot holds OpenAI's own API unless an operator put something else there. Where no pipeline server has been deployed and registered, there is nowhere for any of this to happen. The record places the impact inside Open WebUI, which is the one place it cannot occur. ### Replacing a Pipeline by Filename Is How the Pipelines Server Works The proof of concept names its file after a pipeline that already exists, and the report describes the result as modifying that pipeline's code. That is what happens. The pipeline server keeps each pipeline in a file named after it and reloads them all once an upload arrives, so sending a file under a name already in use replaces what was there. Installing and replacing pipelines is what an administrator uses that endpoint for. It also happens somewhere else. The pipeline server is a separate application with its own repository and its own releases, which an operator chooses to deploy and connect. A record naming Open WebUI as the affected product is describing how a different program handles uploads. ### Applicable Security Policy Rules - **[Rule 1](/security/security-policy#reporting-guidelines):** A vulnerability must be a real, exploitable weakness that crosses a security boundary. The described attack cannot be performed: the endpoints require an administrator, and the cookie policy cited as its cause withholds the credential from the request it depends on. - **[Rule 4](/security/security-policy#reporting-guidelines):** A proof of concept must demonstrate the boundary being crossed and reproduce as written. This one does not run. Its page submits the upload as a cross-site form post, which is the request the browser refuses to attach the session cookie to, so the upload arrives unauthenticated and is rejected. - **[Rule 3](/security/security-policy#reporting-guidelines):** Reports must reflect an understanding of the affected components. The record attributes the code execution to Open WebUI, which forwards the file and deletes its copy without ever running it, and names an endpoint operation that does not exist. - **[Rule 7](/security/security-policy#reporting-guidelines):** Reports must reflect an understanding of the role-based architecture. Every endpoint in question is administrator-only, and the record is titled and scored as an attack available to ordinary users. - **[Rule 8](/security/security-policy#reporting-guidelines):** A submitted score must reflect the finding accurately. The privileges-required metric describes the account used to look up a filename rather than the account whose session performs the action, and the scope metric places the impact inside Open WebUI when the described effect would occur in a separate application. --- ## Impact to Users **No action required.** The pipeline endpoints are restricted to administrators, and the session cookie is not sent on the cross-site requests this record describes. --- ## References - [CVE-2024-7806 on CVE.org](https://www.cve.org/CVERecord?id=CVE-2024-7806) - [NVD Entry](https://nvd.nist.gov/vuln/detail/CVE-2024-7806) - [Open WebUI Security Policy](/security/security-policy)