Open actionable advisories and recorded vendor fixes. This public package view has no inventory attached and cannot establish whether your deployment is affected. A vendor fix never resolves your finding; verify your installed version and the source guidance.
Open advisories
145 actionable advisories, newest first. Withdrawn advisories and news are excluded. Coverage is partial.
Any authenticated user can permanently delete files owned by other users via DELETE /api/v1/files/{id} when the target file is referenced in any shared chat. The hasaccesstofile() authorization gate unconditionally grants access through its shared-chat branch. It checks neither the requesting user's identity nor the type of operation being performed. File UUIDs (which would otherwise be impractical to guess) are disclosed to any user with read access to a knowledge base via GET /api/v1/knowledge/{id}/files. Details The root cause is in hasaccesstofile() in backend/openwebui/routers/files.py. When a user calls DELETE /api/v1/files/{fileid}, the endpoint delegates authorization to hasaccesstofile(fileid, accesstype="write", user=requestinguser). Inside that function, one branch checks whether the file is referenced in any shared chat: This branch has two missing checks: 1. No user check: It asks "does any shared chat anywhere reference this file?", not "does the requesting user…
Recommended action: Upgrade to 0.9.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
GET /api/v1/memories/ef is accessible without authentication and executes request.app.state.EMBEDDINGFUNCTION(...). This allows any unauthenticated caller to trigger embedding generation which can lead to direct cost exposure if a paid provider is used. Code reference: backend/openwebui/routers/memories.py (@router.get("/ef") - calls request.app.state.EMBEDDINGFUNCTION("hello world")). Details GET /api/v1/memories/ef is reachable without authentication and triggers request.app.state.EMBEDDINGFUNCTION("hello world"). This crosses an intended security boundary by allowing unauthenticated users to invoke potentially expensive embedding computation and/or paid upstream embedding APIs. PoC 1. Start Open WebUI in default configuration (no special env hardening; default ENABLEMEMORIES is true). 2. From an unauthenticated client (no cookies/Authorization header), call: curl -i http://\<host\:\<port\/api/v1/memories/ef 3. Observe the server performs embedding generation and returns a…
Recommended action: Upgrade to 0.8.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
The API /api/v1/notes/{noteid} endpoint lacks proper authorization checks, allowing authenticated users to retrieve notes belonging to other users by guessing or enumerating UUIDs. This results in unauthorized disclosure of potentially sensitive or private user data. Details - if notes is enabled from UI (Settings General Features Notes (Beta)) - From API, attacker can access other user notes - if notes is disabled from UI (Settings General Features Notes (Beta)) - Then attacker can enable the notes from /api/config and access other user notes PoC - Step 1: Log in to the application as a valid user (User A). - Step 2: Intercept or inspect the response from the endpoint GET /api/config. - Step 3: Observe the field "enablenotes": false in the JSON response. - Step 4: Manually change "enablenotes" to true using browser DevTools or by intercepting and modifying the response via a proxy like Burp Suite. (Please note, the occurrence of this API comes twice, hence modification needs…
Recommended action: Upgrade to 0.8.11 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Cross-User File Access via Unchecked fileid in Folder Knowledge and Knowledge-Base Attach Endpoints Summary Multiple endpoints accept a user-supplied fileid and attach the referenced file to a resource the caller controls (folder knowledge, knowledge-base contents) without verifying that the caller owns or has been granted access to the file. The file's content then becomes reachable through the downstream RAG / file-content paths, allowing any authenticated user to exfiltrate any other user's private file — and on the knowledge-base path, also to overwrite it — given knowledge of the file's UUID. Affected code paths Path 1 — Folder knowledge ingestion via folders.update backend/openwebui/routers/folders.py:156 — POST /api/v1/folders/{id}/update accepts a FolderUpdateForm whose data: Optional[dict] field is written verbatim into the folder. The folder consumer at backend/openwebui/utils/middleware.py:2409 spreads folder.data['files'] directly into formdata['files'] for the next chat…
Recommended action: Upgrade to 0.9.5 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
When a user signs in via OAuth, Open WebUI fetches the picture claim URL, infers a MIME type from the URL extension via mimetypes.guesstype, and stores data:<mime;base64,... as the user's profile image. The OAuth code path does not go through the validateprofileimageurl Pydantic validator that normally restricts profile images to PNG/JPEG/GIF/WebP. A .svg URL in the picture claim lands in the database as data:image/svg+xml;base64,.... The profile image endpoint GET /api/v1/users/{id}/profile/image returns the stored data URI with the attacker-controlled MIME type as Content-Type and Content-Disposition: inline. Security headers (CSP, X-Content-Type-Options) are env-gated and not set by default. An authenticated user navigating directly to that URL gets the SVG as a top-level document, executing <script/onload in the same origin and able to read localStorage.token → account takeover. Same class of trust-boundary error as CVE-2025-64496 (trust of untrusted model servers) and…
Recommended action: Upgrade to 0.9.5 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Server-Side Request Forgery (SSRF) Bypass via HTTP Redirect Following in Web-Fetch, Image-Load, and Chat-Completion Endpoints Summary The validateurl() function in backend/openwebui/retrieval/web/utils.py only validates the initial URL submitted by the caller. The HTTP clients used downstream (sync requests, async aiohttp, langchain's WebBaseLoader) follow HTTP 3xx redirects by default and do not re-validate the redirect target against the private-IP / metadata-IP block list. Any authenticated user can therefore submit a public URL that 302-redirects to an internal address (e.g. 127.0.0.1, 169.254.169.254, RFC1918) and read the internal response body via the /api/v1/retrieval/process/web endpoint, the /api/v1/images/... endpoints, the /api/chat/completions endpoint with an imageurl content part, and any other route that calls these helpers. Affected code paths The bypass exists across multiple call sites; each independently follows redirects without re-validation. Path 1 — sync…
Recommended action: Upgrade to 0.9.5 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
In the open-webui project, a parsing difference between the urlparse and requests libraries led to an SSRF bypass vulnerability. Details In the current project, URL validation is performed using the function validateurl. <img width="1323" height="1145" alt="QQ20260322-202854-22-1" src="https://github.com/user-attachments/assets/896d19f2-c7c3-499a-9052-12aea756ac47" / The current checking logic uses urlparse to parse the hostname part of the URL for verification. <img width="1122" height="429" alt="QQ20260322-203014-22-2" src="https://github.com/user-attachments/assets/653520e9-e311-4a5e-8345-a2446e217d88" / However, there are actually differences in parsing between urlparse and the library that actually sends the request. For example, in files.py, validateurl is used first for URL validation, and then requests.get is used to send the request. <img width="1269" height="915" alt="QQ20260322-203122-22-3"…
Recommended action: Upgrade to 0.9.5 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Any authenticated user with low privileges can enumerate active background tasks across the system and stop tasks belonging to other users via the GET /api/tasks and POST /api/tasks/stop/{taskid} methods. This allows a casual user to disrupt system-wide chat usage by continuously canceling other users' active tasks. This is a real authorization vulnerability affecting integrity and usability in multi-user deployments. Details Open WebUI exposes GET /api/tasks and POST /api/tasks/stop/{taskid} to any verified user. These endpoints operate on a global task namespace and accept raw taskid values without checking whether the task belongs to the current caller. As a result, a normal authenticated user can enumerate active global task IDs and stop tasks belonging to other users. Root cause: 1. Route authorization is too weak. In backend/openwebui/main.py, both endpoints only require getverifieduser: getverifieduser accepts both user and admin roles in…
Recommended action: Upgrade to 0.9.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
IDOR: Retrieval API Bypasses Knowledge Base Access Controls Author: Andrew Orr <aorr@tenable.com Summary validatecollectionaccess() (PR #22109) checks the user-memory- and file- collection name prefixes but does not check knowledge base collections, which use raw UUIDs as collection names. Any authenticated user who knows a private knowledge base UUID can read its content through the retrieval query endpoints, even though the knowledge API correctly denies that user access. The same gap affects the retrieval write endpoints (/process/text, /process/file, /process/files/batch, /process/web, /process/youtube), allowing an attacker to inject content into or overwrite another user's knowledge base. Reproduced on main at commit 4d058a125 (v0.8.11) on March 26, 2026. Severity - CWE-639: Authorization Bypass Through User-Controlled Key - CVSS 3.1: 7.5 (AV:N/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H) -- AC:H because exploitation requires knowing a target UUID; I:H and A:H because the write path allows…
Recommended action: Upgrade to 0.9.5 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Vulnerability Type: Information Disclosure / Missing Authentication Severity: Medium Component: backend/openwebui/routers/retrieval.py — getstatus() (GET /) Affected Endpoint: GET /api/v1/retrieval/ Affected Version: Open WebUI main branch — confirmed unpatched through v0.9.2 Authentication Required: None — internet-facing with zero credentials CVSSv3.1 Score: 5.3 (AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N) --- Summary GET /api/v1/retrieval/ returns live RAG pipeline configuration to any unauthenticated HTTP client. No Authorization header, cookie, or API key is required. Every adjacent endpoint on the same router (/embedding, /config) is correctly guarded by getadminuser making this a targeted omission. --- Root Cause backend/openwebui/routers/retrieval.py:262 Compare with every adjacent endpoint on the same router: --- Proof Of Concept — No Token Required --- Disclosed Information and Its Value to an Attacker | Field | What it reveals | |---|---| | RAGEMBEDDINGENGINE | Backend type…
Recommended action: Upgrade to 0.9.5 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Mass Assignment in Feedback Creation Allows User ID Spoofing and Evaluation Data Manipulation Summary The POST /api/v1/evaluations/feedback endpoint in Open WebUI v0.9.2 is vulnerable to mass assignment via FeedbackForm, which uses modelconfig = ConfigDict(extra='allow'). Due to an insecure dictionary merge order in insertnewfeedback(), an authenticated attacker can inject a userid field in the request body that overwrites the server-derived value, creating feedback records attributed to any arbitrary user. This corrupts the model evaluation leaderboard (Elo ratings) and enables identity spoofing. Details The vulnerability exists in two layers: 1. Model Layer — Insecure Dict Merge Order File: backend/openwebui/models/feedbacks.py, lines 148–160 In Python, when a dictionary literal contains duplicate keys, the last value wins. Since formdata.modeldump() appears after 'userid': userid, any userid field in the form data overwrites the authenticated user's ID. 2. Schema Layer —…
Recommended action: Upgrade to 0.9.5 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
When setting model permissions so that a group has read access to it, intending for other users to use it, those users also can read the model's system prompt. However users may consider their system prompt confidential, so we consider this a security issue. Compare https://genai.owasp.org/llmrisk/llm072025-system-prompt-leakage/ or prompt injections to get popular chatbots on the internet to reveal their prompt. Details We discovered that users can open the workspace model edit page /workspace/models/edit?id=notmymodel for models that do not appear in their workspace. Saving is not possible, that permission check is correct. On the API level: - - returns the model details, most importantly params.system - even though does NOT contain the model since it checks for write permission. - contains the model correctly and does not reveal the system prompt. It seems inconsistent that the REST API list does not contain an item, but if you know the id, you can access it anyway. PoC -…
Recommended action: Upgrade to 0.9.5 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Pin/Unpin is a write operation (modifies the message's ispinned , pinnedby, pinnedat fields), but in standard channels it only checks read permission, allowing users with read-only access to pin/unpin any message. Details https://github.com/open-webui/open-webui/blob/9bd84258d09eefe7bf975878fb0e31a5dadfe0f8/backend/openwebui/routers/channels.py#L1218 The channelhasaccess function https://github.com/open-webui/open-webui/blob/9bd84258d09eefe7bf975878fb0e31a5dadfe0f8/backend/openwebui/routers/channels.py#L75 checks user permissions against the AccessGrants table: The AccessGrant table distinguishes between read and write permission levels. PoC admin creates Standard Channel with Read-Only Access for test1 : admin posts a Message in the Channel, and test1 has read permission only. <img width="1024" height="423" alt="image" src="https://github.com/user-attachments/assets/e9912bd7-3908-44f2-8984-22d0535dc66f" / test1 attempts to Pin Message: Successfully pinned admin's message.…
Recommended action: Upgrade to 0.9.5 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
An IDOR vulnerability exists in the Channels feature of Open WebUI, allowing any channel member to modify messages sent by other members (including administrators) within the same channel. This vulnerability affects the latest version (v0.8.12) of Open WebUI. Details In the updatemessagebyid function, for group or dm type channels, only the caller's membership in the channel is checked via the isuserchannelmember function, without verifying message ownership. This allows any channel member to modify messages sent by other members within the same channel. The problematic code is as follows (https://github.com/open-webui/open-webui/blob/main/backend/openwebui/routers/channels.py#L1355) : Non-group/dm types include a check for the user ID, while the group/dm type clearly lacks this verification. PoC The Channels feature is disabled by default and can be enabled first through the admin interface. <img width="1024" height="618" alt="image"…
Recommended action: Upgrade to 0.9.5 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
An internal-only bypassfilter parameter is exposed on the /openai/chat/completions and /ollama/api/chat HTTP endpoints via FastAPI query string binding, allowing any authenticated user to append ?bypassfilter=true and bypass model access control checks to invoke admin-restricted models. Details The generatechatcompletion route handlers in both routers/openai.py and routers/ollama.py declare bypassfilter as a function parameter: routers/openai.py, line 937–941: routers/ollama.py, line 1283–1288: Because FastAPI automatically binds unrecognized function parameters to the query string, any HTTP client can set this value by appending ?bypassfilter=true to the request URL. When bypassfilter is true, the access control check is skipped entirely: routers/openai.py, line 980: This parameter is intended for internal use only — the server-side chat pipeline in utils/chat.py (lines 238, 253) passes bypassfilter=True as a Python function argument when making recursive calls to base…
Recommended action: Upgrade to 0.8.11 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
A regular user [non-admin] can view the system prompt of the model which is set by an admin. Details When a regular user [non-admin] logs into the application, a http://IP:8080/api/models? web request is initiated by the application and in response, it reveals the system prompt of available models set by admin on models pages in workspace affecting the confidentiality of application Affected System Open WebUI v0.6.40 "main" branch Vulnerability Details and Advisory from OWASP LLM07:2025 System Prompt Leakage - https://genai.owasp.org/llmrisk/llm072025-system-prompt-leakage/ PoC 1. Regular User [Non-Admin] login on Open WebUI application. 2. A series of web requests get generated by the application, and the http://IP:8080/api/models? is also gets generated by application . 3. The response of http://IP:8080/api/models? web request reveals the system prompt of all the available models which is set is by the admin on models pages in workspace. <img width="940" height="352"…
Recommended action: Upgrade to 0.8.9 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Open WebUI v0.6.43 contains a vulnerability in its chat completion API, which allows attackers to bypass tool restrictions, potentially enabling unauthorized actions or access. Details In the chatcompletion API, the parameters toolids and toolservers are supplied by the user. These parameters are used to create a toolsdict by the middleware. This is then used by gettoolbyid to retrieve the appropriate tool. However, there is no checks in that ensures the user that uses the API has permission to use the tool, meaning that a user can invoke any server tool by supplying the correct toolid or toolservers parameters via the chat completion API. Moreover, the authentication token stored in the server would be used when invoking the tool, so the tool will be invoked with the server privilege. PoC To reproduce the issue, create an admin user and create an external tool via the admin settings. Set the type to "MCP Streamable HTTP" for the tool, and the url pointing to a mcp server.…
Recommended action: Upgrade to 0.8.6 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Any user X can continue the conversation of any other user Y, as long as the Chat ID of Y is known. User X does not even need to be an admin to do so. Details A user just needs to use the API endpoint: /api/chat/completions with their own API key (generated in OWUI) and the Chat ID of another user. OWUI does not check to match the Chat ID with the user that created that Chat ID. Note that both users will need access to the same model. This is especially relevant if there is a shared pipeline model between users. PoC 1. Using OWUI v0.6.18 2. Sign in with any user X 3. Generate an API Key for user X using the settings 4. Create another user Y, and have a conversation in OWUI. Copy the Chat ID from the URL. 5. User X can now use the API /api/chat/completions and the Chat ID from step 4 to continue the conversation of user Y Impact Large impact to any user in OWUI. People can read your conversations, and access private information if they know your Chat ID (which is in the URL of…
Recommended action: Upgrade to 0.9.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Blind server side request forgery (SSRF) via the PDF generate function. The finding resulted from a penetration test for a customer. It is suspected that the root cause of the issue lies within the core of Open WebUI, which is why it is being reported as a security issue here. Tested on Open WebUI 0.5.4. Details In the PDF export, user inputs are interpreted as HTML and embedded into the PDF. According to tests, scripts and some potentially dangerous tags (iFrame, Object, etc.) are blocked, preventing server-side content from being read through this vulnerability. However, an image tag can be used to force a server-side request (SSRF), as shown in the following below. PoC Start a chat and export the PDF: Intercept the request and insert an <img tag into the title: A HTTPS callback was received at https://d5jok0s7ghl1p77v5brlqlxwmnsega4z.oastify.com. Impact A user can force server-side GET requests. During the available testing time, no method was found to read the responses…
Recommended action: Upgrade to 0.5.11 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
A user can modify another user's model even if its visibility is set to Private. The finding resulted from a penetration test for a customer. It is suspected that the root cause of the issue lies within the core of Open WebUI, which is why it is being reported as a security issue here. Tested on Open WebUI 0.5.4. Details / PoC The user Victim created a private model with the visibility set to private: The user Attacker can edit this model using the following POST request: Request / Response Impact A user can modify another user's model even if its visibility is set to Private. By changing the access permissions during editing, unauthorized access can be gained.
Recommended action: Upgrade to 0.5.7 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Open WebUI allows admins to restrict which API endpoints an API key can access. When an API key is restricted from `/api/v1/messages`, requests using the `Authorization: Bearer sk-...` header are correctly blocked with 403. However, the same key sent via the `x-api-key` header bypasses the restriction entirely — the request is authenticated, the model is invoked, and a full response is returned. Details Open WebUI's Anthropic-compatible API path accepts authentication via `x-api-key` header (standard for the Anthropic API). The endpoint restriction check only applies to keys presented via the `Authorization` header. When the same `sk-...` key is supplied in `x-api-key`, the restriction check is skipped but the key is still valid for authentication. This means any API key, regardless of its configured endpoint restrictions, can access any API endpoint by simply using `x-api-key` instead of `Authorization`. PoC Verified against Open WebUI v0.8.11. Setup:…
Recommended action: Upgrade to 0.9.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
A Server-Side Request Forgery (SSRF) vulnerability exists in processpictureurl() in backend/openwebui/utils/oauth.py (line ~1338). The function fetches arbitrary URLs from OAuth picture claims without applying validateurl(), allowing an attacker to force the server to make HTTP requests to internal resources and exfiltrate the full response. Vulnerable Code The codebase already uses validateurl() for the same SSRF protection pattern in other paths: - backend/openwebui/utils/files.py:38 - validateurl(url) before requests.get(url) - backend/openwebui/routers/images.py:800 - validateurl(data) before requests.get(data) The omission in processpictureurl() is inconsistent with the project's own security practices. Affected Code Paths 1. New user OAuth signup (line ~1556): pictureurl = await self.processpictureurl(pictureurl, token.get('accesstoken')) 2. Existing user picture update on login (line ~1536): when OAUTHUPDATEPICTUREONLOGIN=true Steps to Reproduce Prerequisites - Open…
Recommended action: Upgrade to 0.9.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
SSRF Bypass via IPv6/IPv4-mapped IPv6/IPv4-reserved-ranges in validateurl() Summary validateurl() in backend/openwebui/retrieval/web/utils.py calls validators.ipv6(ip, private=True), but the validators library does NOT implement the private keyword for IPv6 — the call raises a ValidationError (which is falsy in a boolean context), so every IPv6 address passes the filter. In addition, IPv4-mapped IPv6 (::ffff:10.0.0.1) bypasses the IPv4 check entirely, and several reserved IPv4 ranges (0.0.0.0/8, 100.64.0.0/10, 192.0.0.0/24, etc.) are not blocked. The vulnerability has existed since the validateurl() function was introduced and was NOT actually fixed by GHSA-c6xv-rcvw-v685 / CVE-2025-65958 despite that patch's intent. It affects every endpoint that calls validateurl(), including /api/v1/retrieval/process/web, /api/v1/images/edit, and others. Affected code backend/openwebui/retrieval/web/utils.py validateurl(): Proof of concept End-to-end exploit: Impact Any authenticated user can…
Recommended action: Upgrade to 0.9.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
An application-wide Cross-Site Request Forgery (CSRF) vulnerability was found Open-WebUl's image uploading functionality. An attacker can set an image URL to a malicious endpoint, allowing them to perform actions on behalf of a victim user. Any authenticated user can exploit this vulnerability, and any user who views the compromised image (e.g., a profile picture) will unknowingly send a GET request to the attacker-controlled URL. This can lead to cookie theft, denial of service (DoS), or other malicious actions. This can be exploited in various locations, including: • Profile picture • Model picture • Hidden images in shared chats • Images within shared notes Details Vulnerable Code: This appears to occur in most locations where images can be uploaded/rendered. Here are found sinks: Profile Image in chat • Note: rendering profile picture in chat • Location:…
Recommended action: Upgrade to 0.9.3 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Related advisory This advisory tracks a regression of the original Excel-preview XSS that was publicly disclosed and patched under GHSA-jwf8-pv5p-vhmc (patched in v0.8.0). The same root cause — XLSX.utils.sheettohtml() output rendered via {@html excelHtml} without DOMPurify — was reintroduced sometime after v0.8.0 and is exploitable again as of v0.8.12 and through the version range listed above. This advisory additionally covers the related fileOfficeHtml sink in src/lib/components/chat/FileNav.svelte (lines 458 and 1285) which was not part of the jwf8 advisory's scope. Summary Open WebUI renders user-uploaded Office files (Excel, DOCX) as HTML using Svelte's {@html} directive without DOMPurify sanitization. While the codebase has DOMPurify available and uses it in 9 out of 23 {@html} locations (39%), three file-preview rendering paths bypass it entirely, allowing Stored XSS when a user uploads a malicious document. This is a classic defense propagation failure: the sanitization…
Recommended action: Upgrade to 0.9.3 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.