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.
The POST /api/v1/notes/{id}/pin endpoint performs a write operation (toggling the ispinned field) but only checks for read permission. Users with read-only access to a shared note can pin/unpin it, which is a state-modifying action that should require write permission. All other write endpoints (update, delete, access/update) correctly check for write permission. Details Affected code: backend/openwebui/routers/notes.py lines 412-444 Compare with update endpoint (correct, line 318-327): PoC Environment: Open WebUI v0.9.2, default configuration with notes sharing enabled. Setup: 1. UserA creates a note 2. UserA shares note with UserB with read permission via POST /api/v1/notes/{id}/access/update with {"accessgrants":[{"principaltype":"user","principalid":"USERBID","permission":"read"}]} Test: E2E Verified Result: - Step 1: UserB reads note (READ) - 200 OK ✓ - Step 2: UserB updates note (WRITE) - 403 Forbidden ✓ (correctly blocked) - Step 3: UserB pins note (WRITE via READ) -…
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.
As part of our research on improving our AI pentest, we have uncovered the following issue in Open WebUI. We've manually verified and tided up the report, but you can also find the original agent finding at the bottom of this report. Summary The channel webhook create/update flow accepts arbitrary profileimageurl values, including data:image/svg+xml;base64,... payloads. The profile image endpoint then decodes and serves this SVG as image/svg+xml without sanitization, allowing attacker-controlled script handlers (for example onload) to execute when the profile-image URL is opened in the browser. Details The server accepts data:image/svg+xml;base64,... values for profileimageurl when creating or updating a webhook. Later, GET /api/v1/channels/webhooks/{webhookid}/profile/image detects data:image, base64-decodes it, derives the media type from the header (e.g., image/svg+xml), and returns a StreamingResponse with Content-Disposition: inline and mediatype set to image/svg+xml. There is…
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.
The audio transcription upload endpoint takes the file extension from the user-supplied filename and saves the file under CACHEDIR/audio/transcriptions/<uuid.<ext. The /cache/{path} route serves these files via FileResponse, which sets Content-Type from the on-disk extension and emits no Content-Disposition. A verified user with the default-on chat.stt permission can upload a polyglot WAV+HTML file named pwn.html and trick any other user into opening the resulting URL — the response comes back as text/html and any embedded <script runs in the Open WebUI origin. Details Verified on main @ 8dae237a (v0.9.2): - backend/openwebui/routers/audio.py:1244-1249 — ext = safename.rsplit('.', 1)[-1] from user-supplied filename, then filename = f'{id}.{ext}'. No allowlist, no cross-check against file.contenttype. - backend/openwebui/main.py:2768-2779 — /cache/{path:path} returns FileResponse(filepath). Starlette derives Content-Type from the filename extension and sets no…
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.
Through the HTML rendering view, scripts can be injected and executed. 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 The frontend provides a function to visualize the HTML content of a current chat. The content is embedded in an iFrame with the following sandbox directive: sandbox="allow-scripts allow-forms allow-same-origin" This means that the content is placed in a sandbox but with permission to execute scripts and access the parent’s data (e.g., local storage). As a result, only a few functions are restricted (e.g., displaying an alert box), but in effect, the sandbox attribute is largely nullified. PoC If an HTML document containing a script is included in the chat, this script will be embedded in the view and executed. This can be achieved with a message like the following: By…
Recommended action: Upgrade to 0.6.5 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
A missing permission check in all files related API endpoints allows any authenticated user to list, access and delete every file uploaded by every user to the platform. Details All files/ related endpoints lack permission checks. Listing all files For example, let's see how file listing is implemented: https://github.com/open-webui/open-webui/blob/e2b7296786053dfc77f6ae0205a1b195e05a712c/backend/apps/webui/routers/files.py#L107-L110 https://github.com/open-webui/open-webui/blob/e2b7296786053dfc77f6ae0205a1b195e05a712c/backend/apps/webui/models/files.py#L26 Notice the endpoint depends only on an authenticated user check, no file filtering is done to match the uploaded files' userid to the requesting user. This problem repeats itself throughout the various route implementations, allowing any user to perform actions on any file. Some note worthy functions: Accessing the content of any file…
Recommended action: Upgrade to 0.3.16 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
The profileimageurl field on the user profile update form accepted arbitrary data: URI values without MIME-type validation. Two distinct attack paths were independently demonstrated by separate reporters: 1. data:text/html;base64,... in a new browser tab (raresvis, 2025-04-17) — when a victim right-clicks a user's profile picture and chooses "Open image in new tab", the browser navigates to the data: URL and executes embedded scripts in the data: origin. Limited to social-engineering / redirect attacks because the script does not run in the application origin. 2. data:image/svg+xml;base64,... re-served by the application origin (Gh05t666nero, 2026-01-09) — GET /api/v1/users/{userid}/profile/image decoded the base64 and returned StreamingResponse(mediatype=<user-controlled) extracted from the data: header. With mediatype=image/svg+xml and Content-Disposition: inline, the SVG-embedded scripts executed in the application origin, enabling JWT theft from localStorage and full…
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.
Authorization controls surrounding the memories API were inconsistent, resulting in the ability of a standard user to delete, restore, and view the contents of other users' memories. Details Using a newly created non-admin user with no existing memories, it is possible to view existing memories via POST /api/v1/memories/query. See below under the PoC section, where a call to GET /api/v1/memories/ returns [] (as expected) but a call to POST /api/v1/memories/query reveals memories created by other users. Similarly, even if a non-admin user cannot modify another user's memory data via POST /api/v1/memories/{memoryid}/update, the endpoint's response improperly leaks the content of that memory if a valid memoryid is known. The DELETE /api/v1/memories/{memoryid} can also be used by any user to delete an existing memory. Deleted memories can then be restored by calling the POST /api/v1/memories/{memoryid}/update endpoint again. PoC 1 Example of a user with no memories able to query…
Recommended action: Upgrade to 0.6.19 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Vulnerability Description In standard channels (i.e., channels whose channel.type is neither group nor dm), the endpoint POST /api/v1/channels/{channelid}/messages/{messageid}/update can be accessed with read permission only. When accesscontrol is set to None, the authorization check hasaccess(..., type="read") evaluates to True, allowing users who are not the message owner to update messages. As a result, unauthorized modification of other users’ messages is possible. --- Attack Prerequisites - The attacker is an authenticated user (role user or higher) - The target channel is a standard channel (i.e., not group or dm) - accesscontrol is None or allows read access - The attacker can obtain the target messageid (e.g., via the channel’s message list) Attack Scenario 1. The attacker (User B) retrieves another user’s messageid from the message list in a standard channel 2. The attacker sends a request to POST /api/v1/channels/{channelid}/messages/{messageid}/update 3. The message…
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.
There's an IDOR in the channels message management system that allows authenticated users to modify or delete any message within channels they have read access to. The vulnerability exists in the message update and delete endpoints, which implement channel-level authorization but completely lack message ownership validation. While the frontend correctly implements ownership checks (showing edit/delete buttons only for message owners or admins), the backend APIs bypass these protections by only validating channel access permissions without verifying that the requesting user owns the target message. This creates a client-side security control bypass where attackers can directly call the APIs to modify other users' messages. The vulnerability affects both message content modification and deletion, allowing users to tamper with message integrity and audit trails in collaborative channel environments. Source - Sink Analysis Source: User-controlled messageid parameter in URL…
Recommended action: Upgrade to 0.6.19 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
CONFIDENTIAL Vulnerability Disclosure Analysis Documentation ----------------------------------------------- Vulnerability Details --------------------- 1. Discoverer: Taylor Pennington of KoreLogic, Inc. 2. Date Submitted: June 11, 2024 3. Title: Open WebUI Arbitrary File Write, Delete via Path Traversal 4. High-level Summary: Attacker controlled files can be uploaded to arbitrary locations on the web server's filesystem by abusing a path traversal vulnerability. After the file is written, it is deleted. 5. Affected Vendor: Open WebUI 6. Affected Product(s): Open WebUI (Formerly Ollama WebUI) 7. Affected Version(s): 0.1.105 8. Platform/OS: Debian GNU/Linux 12 (bookworm) 9. Vector: HTTP web interface 10. CWE: 22 Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal') 11. Technical Analysis: When attaching files to a prompt by clicking the plus sign (+) on the left of the message input box when using the Open WebUI HTTP interface, the file is uploaded to a…
Recommended action: Upgrade to 0.6.10 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
GitHub Security Lab (GHSL) Vulnerability Report, open-webui: GHSL-2024-174, GHSL-2024-175 The GitHub Security Lab team has identified potential security vulnerabilities in open-webui. We are committed to working with you to help resolve these issues. In this report you will find everything you need to effectively coordinate a resolution of these issues with the GHSL team. If at any point you have concerns or questions about this process, please do not hesitate to reach out to us at securitylab@github.com (please include GHSL-2024-174 or GHSL-2024-175 as a reference). See also this blog post written by GitHub's Advisory Curation team which explains what CVEs and advisories are, why they are important to track vulnerabilities and keep downstream users informed, the CVE assigning process, and how they are used to keep open source software secure. If you are NOT the correct point of contact for this report, please let us know! Summary Due to a CORS misconfiguration and session validation…
Recommended action: Upgrade to 0.3.33 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
CONFIDENTIAL KL-CAN-2024-002 Vulnerability Details | | Field | Value | |---|-------|-------| | 1 | Discoverer | Jaggar Henry & Sean Segreti of KoreLogic, Inc. | | 2 | Date Submitted | 2024.03.12 | | 3 | Title | Open WebUI Arbitrary File Upload + Path Traversal | | 5 | Affected Vendor | Open WebUI | | 6 | Affected Product(s) | Open WebUI (Formerly Ollama WebUI) | | 7 | Affected Version(s) | 0.1.105 | | 8 | Platform/OS | Debian GNU/Linux 12 (bookworm) | | 9 | Vector | HTTP web interface | | 10 | CWE | CWE-22: Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal'), CWE-434: Unrestricted Upload of File with Dangerous Type | --- 4. High-level Summary Attacker controlled files can be uploaded to arbitrary locations on the web server's filesystem by abusing a path traversal vulnerability. --- 11. Technical Analysis When attaching files to a prompt by clicking the plus sign (+) on the left of the message input box when using the Open WebUI HTTP interface, the file…
Recommended action: Upgrade to 0.1.124 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
CONFIDENTIAL Vulnerability Disclosure Analysis Documentation --- Vulnerability Details | | Field | Value | |---|-------|-------| | 1 | Discoverer | Taylor Pennington of KoreLogic, Inc. | | 2 | Date Submitted | June 11, 2024 | | 3 | Title | Open WebUI Improper Authorization Control | | 5 | Affected Vendor | Open WebUI | | 6 | Affected Product(s) | Open WebUI (Formerly Ollama WebUI) | | 7 | Affected Version(s) | 0.1.105 | | 8 | Platform/OS | Debian GNU/Linux 12 (bookworm) | | 9 | Vector | HTTP web interface | | 10 | CWE | 285 Improper Authorization | --- 4. High-level Summary There is a missing authorization check affecting user accounts with a pending status allowing the user to make authenticated API calls as a user context. --- 11. Technical Analysis The Open WebUI web application has three user role classifications: user, admin, and pending. By default, when Open WebUI is configured with new sign-ups enabled, the default user role is set to pending. In this configuration, an…
Recommended action: Upgrade to 0.1.124 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Excel file attachments are previewed in an unsafe way. A crafted XLSX file payload can be used to cause the sheetjs function sheettohtml to embed an XSS payload into the generated HTML. This is subsequently added to the DOM unsanitized via @html causing the payload to trigger. Details The function used to convert XLSX documents to HTML for preview does not perform any input validation or sanitisation for the generated HTML https://github.com/open-webui/open-webui/blob/a7271532f8a38da46785afcaa7e65f9a45e7d753/src/lib/components/common/FileItemModal.svelte#L120-L133 XLSX attachments are processed by this function, converted to HTML with XLSX.utils.sheettohtml before ultimately being assigned to the variable excelHtml. Later there is logic that causes this to be assigned directly to the DOM when the preview tab is selected. https://github.com/open-webui/open-webui/blob/a7271532f8a38da46785afcaa7e65f9a45e7d753/src/lib/components/common/FileItemModal.svelte#L358-L400 PoC A python…
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.
Vulnerability Details CWE-79: Cross-site Scripting (XSS) The AccountPending.svelte component renders the admin-configured "Pending User Overlay Content" using marked.parse() inside {@html} with an incorrect DOMPurify application order: Vulnerable Code src/lib/components/layout/Overlay/AccountPending.svelte (lines 43-48): DOMPurify is applied to the raw Markdown input before marked.parse() processes it. This is the wrong order. DOMPurify sanitizes the Markdown text (which contains no HTML tags), then marked.parse() converts Markdown link syntax into HTML <a tags with javascript: href, and the result is rendered with {@html} unsanitized. The correct pattern (used elsewhere in the codebase, e.g., NotebookView.svelte:77) is: Steps to Reproduce Prerequisites - Open WebUI v0.8.10 - Admin account - A second user account with "pending" role Steps 1. Log in as admin and navigate to Admin Settings → Settings → General. 2. Set Default User Role to pending. 3. In the Pending User Overlay Content…
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.
Unauthorized File and Knowledge Base Content Access via RAG Vector Search Affected Component RAG source resolution in chat completion pipeline: - backend/openwebui/retrieval/utils.py (lines 963-965, 1063-1068, 1126-1131 in getsourcesfromitems) Affected Versions Current main branch (commit 6fdd19bf1) and likely all versions with RAG functionality. Description The getsourcesfromitems function resolves file and knowledge base references into vector search queries during chat completion. Three of the five code paths perform vector store queries without any authorization check, allowing users to extract content from files and knowledge bases they do not have access to. | Path | Lines | Access Check | |------|-------|-------------| | type: "file", full-context | 1044-1050 | ✅ hasaccesstofile | | type: "file", non-full-context (default) | 1063-1068 | ❌ None | | type: "collection" | 1070-1118 | ✅ Present | | type: "text" with collectionname | 963-965 | ❌ None | | Bare…
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.
Deactivated Channel Members Retain Full Access to Group/DM Channels Affected Component Channel membership authorization check: - backend/openwebui/models/channels.py (lines 663-673, isuserchannelmember) - Used at 15 locations in backend/openwebui/routers/channels.py Affected Versions Current main branch (commit 6fdd19bf1) and likely all versions with the group/DM channel feature. Description The isuserchannelmember function checks whether a ChannelMember row exists but does not check the isactive field. When a user is deactivated from a group or DM channel (removed by the channel owner, or leaves voluntarily), their membership row persists with isactive=False and status='left'. Because the authorization check ignores this field, the deactivated user retains full read and write access to the channel via direct API calls. The channel correctly disappears from the deactivated user's channel list (the listing query at getchannelsbyuserid properly filters on isactive), but all 15…
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.
Read-Only Users Can Modify Collaborative Documents via Socket.IO Affected Component Socket.IO collaborative document editing handler: - backend/openwebui/socket/main.py (lines 667-721, ydoc:document:update handler) Affected Versions Current main branch and likely all versions with collaborative note editing. Description The ydoc:document:update Socket.IO event handler checks whether the sender is a member of the document's Socket.IO room (line 678) but does not verify that the sender has write permission. Users with read-only access join the document room via ydoc:document:join, which only requires read permission (line 520). Once in the room, the user can emit ydoc:document:update events that modify the in-memory Yjs document state and are broadcast to all other collaborators in real time. The documentsavehandler (line 600) correctly checks write permission before persisting to the database, so the attacker cannot directly save changes. However, the tampered content is visible to…
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.
Ollama Model Access Control Bypass via /api/generate, /api/embed, /api/embeddings, and /api/show Affected Component Ollama proxy endpoints missing model access control: - backend/openwebui/routers/ollama.py (lines 955-995, generatecompletion) - backend/openwebui/routers/ollama.py (lines 835-881, embed) - backend/openwebui/routers/ollama.py (lines 891-937, embeddings) - backend/openwebui/routers/ollama.py (lines 791-820, showmodelinfo) Affected Versions Current main branch (commit 6fdd19bf1) and likely all versions with Ollama model access control support. Description Four Ollama proxy endpoints accept any model name from the user and forward the request to the Ollama backend without checking whether the user is authorized to access that model. These endpoints only require getverifieduser (any authenticated non-pending user) and validate that the model exists in the full unfiltered model list, but never check AccessGrants.hasaccess(). This is in direct contrast with the…
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.
Model Import Overwrites Any Model Without Ownership Check Affected Component Model import endpoint: - backend/openwebui/routers/models.py (lines 254-308, importmodels) Affected Versions Current main branch (commit 6fdd19bf1) and likely all versions with model import functionality. Description The POST /api/v1/models/import endpoint allows users with the workspace.modelsimport permission to overwrite any existing model in the database, regardless of ownership. When an imported model's ID matches an existing model, the endpoint merges the attacker's payload over the existing model data and writes it to the database with no ownership or access grant validation. Additionally, filterallowedaccessgrants is never called, bypassing the access grant restrictions enforced on all other model mutation endpoints. Compare with properly-guarded endpoints: - updatemodelbyid (line 499): checks ownership/write access AND calls filterallowedaccessgrants - updatemodelaccessbyid (line 571): checks…
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.
Missing Access Check on Channel Members Endpoint for Standard Channels Affected Component Channel members listing endpoint: - backend/openwebui/routers/channels.py (lines 445-507, getchannelmembersbyid) Affected Versions Current main branch and likely all versions with the channels feature. Description The GET /api/v1/channels/{id}/members endpoint only checks membership for group and dm channel types (lines 467-469). For standard channels — including private ones — there is no channelhasaccess check before returning the member list. Any authenticated user who knows a private channel's UUID can enumerate all users with access to that channel. Compare with other channel endpoints (e.g., getchannelmessages at line 688) which correctly call channelhasaccess(user.id, channel, permission='read') for standard channels. CVSS 3.1 Breakdown | Metric | Value | Rationale | |--------|-------|-----------| | Attack Vector | Network (N) | Exploited remotely via API call | | Attack Complexity | Low…
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.
Global Knowledge Base Enumeration via knowledge-bases Meta-Collection Affected Component Retrieval collection access validation: - backend/openwebui/routers/retrieval.py (lines 2330-2355, validatecollectionaccess) - backend/openwebui/routers/retrieval.py (query endpoints, e.g. POST /query/doc) Affected Versions Current main branch (commit 6fdd19bf1) and likely all versions with the knowledge base subsystem. Description The validatecollectionaccess function uses an incomplete allowlist that only enforces ownership checks for collections matching user-memory- and file- patterns. All other collection names pass through unchecked — including the system-level knowledge-bases meta-collection, which stores the IDs, names, and descriptions of every knowledge base on the instance. Any authenticated user can query this meta-collection directly via the retrieval query endpoints to obtain a global index of all knowledge bases across all users. This finding is the enabler for the KB destruction…
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.
Knowledge Base Destruction and RAG Poisoning via Unauthorized Collection Overwrite Affected Component Retrieval web/YouTube processing endpoints: - backend/openwebui/routers/retrieval.py (lines 1810-1837, processweb) - backend/openwebui/routers/retrieval.py (the parallel processyoutube endpoint) - backend/openwebui/routers/retrieval.py (line 1445, savedocstovectordb call chain) Affected Versions Current main branch (commit 6fdd19bf1) and likely all versions with RAG/knowledge base functionality. Description The POST /api/v1/retrieval/process/web endpoint accepts a user-supplied collectionname and an overwrite query parameter (default: True). It performs no authorization check on whether the calling user owns or has write access to the target collection. When overwrite=True, savedocstovectordb calls VECTORDBCLIENT.deletecollection() on the target collection before writing new content. Combined with the knowledge base enumeration vulnerability (separate report), an attacker 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.
Channel Access Grants Bypass filterallowedaccessgrants Affected Component Channel creation and update endpoints: - backend/openwebui/routers/channels.py (lines 291-340, createnewchannel) - backend/openwebui/routers/channels.py (lines 617-638, updatechannelbyid) - backend/openwebui/models/channels.py (lines 825-826, setaccessgrants call without filtering) Affected Versions Current main branch (commit 6fdd19bf1) and likely all versions supporting user-created group channels with access grants. Description All resource routers in Open WebUI (knowledge, models, notes, prompts, tools, skills) call filterallowedaccessgrants() before persisting access grants. This function strips principalid: "" wildcard grants from users who lack the relevant sharing.public permission, and strips individual user grants from users who lack accessgrants.allowusers permission. The channel router does not call filterallowedaccessgrants on either create or update paths. A non-admin user who can create group…
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.
The /responses endpoint in the OpenAI router accepts any authenticated user and forwards requests directly to upstream LLM providers without enforcing per-model access control. While the primary chat completion endpoint (generatechatcompletion) checks model ownership, group membership, and AccessGrants before allowing a request, the /responses proxy only validates that the user has a valid session via getverifieduser. This allows any authenticated user — regardless of role or group assignment — to interact with any model configured on the instance by sending a POST request to /api/openai/responses with an arbitrary model ID. Impact As per OWASP TOP 10 LLM: - Model Denial of Service (OWASP LLM04): An unauthorized user can submit resource-intensive requests to expensive models (e.g., o1-pro, GPT-4o) that were explicitly restricted by the administrator. In shared deployments, this can exhaust API budgets or rate limits, causing total service disruption for all legitimate users.…
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.