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.
Open WebUI lets a client define a model inline on a chat request instead of selecting a saved workspace model. The knowledge attached to such an inline model was used as-is, without checking that the caller can read what it points at. Any authenticated user who knows another user's file id could therefore have the builtin knowledge tools return that file's indexed content back to them. Preconditions Authenticated user of any role, no admin rights needed. The request must carry a session id and use native function calling, which is the default (only functioncalling: legacy opts out), and the model's builtintools capability must not be disabled (default enabled). The attacker must already know the target file's id; ids are UUIDs and are not enumerable through this path. No admin setting needs to be turned on: enabling Direct Connections is not required for the backend to accept an inline model. Knowledge bases attached this way were never affected, their own access grants were…
Recommended action: Upgrade to 0.11.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
A user with write access to one knowledge base could delete directories, and drop file embeddings, belonging to knowledge bases they do not control. The sync cleanup endpoint verified write access on the knowledge base named in the URL and then acted on the directory and file ids supplied in the request body without checking that those objects belonged to that knowledge base. Preconditions Default configuration, no flags involved. The attacker needs write access to at least one knowledge base, which comes from owning one, from a write access grant, or from the admin role; workspace.knowledge is off by default, so an ordinary user cannot simply create one. They also need the victim's directory or file id, which are UUIDs and are not enumerable, so in practice the attacker is someone who can already see the target knowledge base, typically a read-only collaborator on a shared one. Deployments where no knowledge base is shared beyond its owner are not reachable. Impact The…
Recommended action: Upgrade to 0.11.0 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 access to a terminal server could get script of their choosing to run in the Open WebUI origin itself. The HTML file preview rendered terminal-served files in an iframe whose sandbox always granted allow-same-origin alongside allow-scripts, and the file is served from a path on the application's own origin, so the sandbox provided no isolation at all. Script in a previewed file could read the victim's session token and take over the account. Preconditions - At least one terminal server configured by an admin (TERMINALSERVERCONNECTIONS, empty by default) and reachable by the victim. Deployments with no terminal server configured are not affected. - The attacker needs a normal authenticated account with access to that terminal server, no admin rights. - No victim interaction beyond having the chat open: a displayfile tool call opens the preview automatically. - TERMINALPROXYHEADERS unset, which is the default. An operator who had already set a…
Recommended action: Upgrade to 0.11.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Open WebUI fetches user-supplied URLs on the server for RAG URL ingestion, URL-to-markdown conversion and web-search content retrieval, and decides whether a destination is allowed by asking whether its IP address is globally routable. That test operates on the literal IPv6 address and does not look at the IPv4 address embedded inside it. On a deployment whose network has a NAT64 gateway, any verified user can wrap an internal or cloud-metadata IPv4 address in the NAT64 well-known prefix, pass the filter, and receive the internal response body back through the API. Preconditions - Any verified (authenticated) user account. No admin role, no elevated permission. - Default configuration: ENABLELOCALWEBFETCH off, the default WEBFETCHFILTERLIST metadata blocklist in place. Neither prevents this, because the blocklist matches hostname strings and the NAT64 literal is not one of them. - The deployment's network must provide NAT64 translation for the well-known 64:ff9b::/96 prefix,…
Recommended action: Upgrade to 0.11.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
An authenticated user whose features.imagegeneration permission has been revoked can still make the server generate images by sending the feature flag in a chat-completion request. The chat pipeline took the client-supplied features object at face value and never re-checked the permission that the direct image routes enforce, so the denial applied to the UI affordance but not to the server-side generation path. Preconditions Image generation must be enabled and a provider configured by the administrator (ENABLEIMAGEGENERATION is off by default). The per-user permission defaults to granted, so only deployments where an administrator explicitly revoked it for some users are affected. On 0.10.0 and later the caller must also set params.functioncalling to legacy; on 0.9.x and earlier the legacy mode was the default, so no special parameter was needed. Deployments on native function calling are unaffected, since that path checks the permission before registering the image tools.…
Recommended action: Upgrade to 0.11.0 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 vega and vega-lite fenced code blocks in chat content by building a Vega view in the viewer's browser without a restricted resource loader. Any user who can place such a block where another user will see it can make that user's browser issue attacker-chosen outbound GET requests, and read back responses from same-origin or CORS-permissive targets into the rendered page. Because the request comes from the browser, server-side SSRF protections never see it. Preconditions Default configuration, no flags or environment variables involved: Vega blocks render unconditionally wherever chat content is displayed. The attacker needs an account that can put content in front of the victim, which covers a shared chat, a channel message, and model, RAG or tool output the attacker can influence. The victim must open the message, so this is not zero-click. Deployments where the victim's browser has no network position of interest lose little. Impact The victim's browser…
Recommended action: Upgrade to 0.11.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
DELETE /api/v1/chats/{id} cancelled a chat's in-flight tasks before it checked whether the caller was allowed to delete that chat. Any authenticated user who knew another user's chat id could therefore abort that user's running model response, title generation or tag generation. The deletion itself was still refused, so the only missing control was on the cancellation side effect. Preconditions Default configuration, no special deployment shape. The attacker needs a normal account with the default user role and nothing else: the chat.delete permission is not required, and revoking it does not prevent the cancellation. The attacker also needs the victim's chat id, which is returned by the read-only shared-chat endpoint when a chat or a folder has been shared with them - otherwise enumerating the chat id requires guessing the chat id or brute forcing it, and the victim must have a generation running at that moment. Impact A user can repeatedly interrupt another user's…
Recommended action: Upgrade to 0.11.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
The OAuth token exchange endpoint accepts a raw provider access token and validates it by calling the provider's userinfo endpoint. A userinfo endpoint reports only that a token is valid, never which OAuth client it was issued to, and the endpoint performed no audience or client check of its own. Anyone holding an access token minted for any client registered with the same provider could exchange it for an Open WebUI session as that token's user, including applications the operator does not control and has never authorised. Preconditions - ENABLEOAUTHTOKENEXCHANGE=True. Disabled by default, so a stock deployment is not affected. - The victim already has an Open WebUI account. The endpoint does not create users. - The attacker can obtain a provider access token for the victim, typically by having them sign in to an unrelated OAuth application on the same provider. On public providers, registering that application is self-service. - The subject identifier the attacker's client…
Recommended action: Upgrade to 0.11.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
On standard channels, the message update and delete handlers accepted any caller holding write access on the channel, without checking that the caller wrote the message. Write access is the same grant a member needs in order to post, so every ordinary participant in a shared channel could rewrite or permanently delete any other participant's messages. The group and direct message branch of the same handlers enforced authorship; the standard branch did not. Preconditions Channels are disabled by default and must be enabled by an administrator (ENABLECHANNELS). The channel must be a standard channel; group and direct message channels are not affected. The attacker is any authenticated account with role user that holds write access on the channel, whether granted publicly, per user, or through a group. No ownership of the channel, channel manager role, or elevated role is required. Channel and message ids are returned by the listing endpoints the member can already call. Impact…
Recommended action: Upgrade to 0.11.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
With the Playwright web loader enabled, Open WebUI opens user-submitted URLs in a real browser and validates the destination address before allowing the request. That check only ran for the top-level page request. Every other request the page issued was passed through unvalidated, so a page could use its own JavaScript to reach addresses the validation exists to block. Because the loader returns the page's final DOM to the requesting user, anything the page read back from those addresses ends up in the web-search or RAG output. Preconditions - WEBLOADERENGINE=playwright. This is not the default; deployments on the default web loader are unaffected. - A reachable Playwright browser, either local or via PLAYWRIGHTWSURL. - Any authenticated user who can submit a URL for ingestion or trigger a web search. No administrator role is required. - Something worth reading on a network the browser can reach. A deployment whose browser container has no route to internal services loses…
Recommended action: Upgrade to 0.11.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
AI assistance was used to help inspect the code and prepare this report. Summary The fix for GHSA-r2wg-2mcr-66rv is incomplete in v0.9.6 and current main. backend/openwebui/routers/terminals.py documents sanitizeproxypath() as decoding until stable, but the implementation stops after 8 unquote() passes. A 9x percent-encoded ../... path parameter remains once-encoded after the loop, passes the posixpath.normpath() and cleaned.startswith('..') checks, and is forwarded to the configured terminal server. The upstream server then receives a decoded traversal path such as /base/../admin/system. Impact A user who has access to an admin-configured terminal connection can bypass the terminal proxy path traversal guard and cause Open WebUI to forward requests with the configured terminal credentials and X-User-Id header to paths outside the intended normalized proxy path. For orchestrator-backed terminal connections the same sanitized path is placed under /p/{policyid}/{safepath}, so the…
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.
An authenticated non-admin user with read access to an arena wrapper model can reach a restricted underlying model through task endpoints such as /api/v1/tasks/moa/completions. The normal chat route resolves arena models before the final chat dispatch and therefore re-checks the selected underlying model. The task routes call utils.chat.generatechatcompletion() directly. In that direct path, arena fallback resolution happens after the wrapper access check and then recurses with bypassfilter=True, skipping the selected submodel's access check. Technical Details Open WebUI's current model-access behavior already denies direct access to the restricted model. The normal chat path also denies the selected restricted model after arena preprocessing. The task endpoint path is inconsistent with that protected behavior because it reaches the same restricted model only through the direct arena fallback and recursive bypassfilter=True. This report does not rely on malicious provider…
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.
Current main and v0.9.6 still allow an authenticated user to turn read-only access to another user's file into write/delete access by attaching that file ID to an attacker-controlled workspace model. This is an incomplete-fix variant of GHSA-vjqm-6gcc-62cr. The current fix adds verifyknowledgefileaccess(), but the validator only checks hasaccesstofile(fileid, "read", user). The file write/delete routes later trust hasaccesstofile(fileid, "write", user), and that function grants access through any writable model whose meta.knowledge contains the file ID. The PoV includes a negative control showing the current validator rejects an inaccessible arbitrary file ID. The residual issue is narrower: a file ID that is readable only through a KB read grant is accepted into direct model file metadata, then the same model metadata satisfies later file write/delete checks. Technical Details backend/openwebui/routers/models.py::verifyknowledgefileaccess() accepts model meta.knowledge file…
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 terminal proxy in backend/openwebui/routers/terminals.py forwards the Open WebUI user's identity to the upstream terminal server / backend coordinator as an authorization claim, with no cryptographic binding to the session that produced it. The forwarded identity is attacker-influenceable on both proxy paths: 1. HTTP path (proxyterminal) sets headers['X-User-Id'] = user.id. Upstreams that trust X-User-Id as identity receive it unsigned, so an attacker who can reach the upstream by other means (directly, a compromised peer, SSRF) can spoof it. 2. WebSocket path (wsterminal) is exploitable through Open WebUI itself, with no "other means" required. It interpolates the path parameter sessionid directly into the upstream URL and then appends ?userid=<caller: sessionid is neither validated nor URL-encoded (the HTTP sibling runs sanitizeproxypath; this path runs nothing). An encoded ?/& smuggled through sessionid survives Open WebUI's single decode and is re-decoded by the…
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 administrator-configured WEBFETCHFILTERLIST (the allow/block list applied to server-side web fetches: RAG URL ingestion, URL-to-markdown, web-search content fetch) matches hostnames incorrectly, so the filter can be bypassed. Details isstringallowed (backend/openwebui/utils/misc.py) matches with str.endswith(...), and the primary web-fetch call site (backend/openwebui/retrieval/web/utils.py) called it with the full URL string, not the hostname: - Blocklist bypass via path. A blocklist entry !internal.example.com only matches a URL that ends with that string. Any URL with a path (https://internal.example.com/x) ends with /x, so the entry never matches and the fetch proceeds. The blocklist effectively only stopped path-less URLs. - Allowlist false-reject and bypass. An allowlist company.com rejected the legitimate https://api.company.com/status and admitted https://attacker.example/path/company.com. - Non-label-boundary matching at the hostname-shaped call site…
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 channel members endpoint serializes and returns full user models for channel participants, including settings objects. A normal user in a DM can retrieve admin-only sensitive configuration such as webhook URLs and tool server key material (settings.ui.toolServers[].key), which is not available via standard user info APIs. Details The endpoint GET /api/v1/channels/{id}/members returns the full serialized user model for every member in the channel. In both the DM and non-DM code paths, the handler constructs the response with [UserModelResponse(user.modeldump(), isactive=...)] and returns it as the users list. Because UserModel (models/users.py) includes a settings object (UserSettings) and arbitrary UI configuration (settings.ui), the endpoint exposes other users' sensitive configuration to any channel participant. Practically, a regular user who participates in a DM or group can call /api/v1/channels/{id}/members and receive other members' settings, including admin-only…
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.
A normal authenticated user can read the content of a message in a private channel they do not belong to. GET /api/v1/channels/{id}/messages/{messageid}/thread authorizes the caller against the URL channel, but the underlying thread lookup loads the thread parent by id and returns it without verifying the parent belongs to that channel. By requesting a thread in a channel they can access while supplying a victim channel's message id as the thread root, the attacker receives the victim message — content, channel id, and author. Affected component - backend/openwebui/models/messages.py — getmessagesbyparentid() - backend/openwebui/routers/channels.py — getchannelthreadmessages() (read), newmessagehandler() (parent/reply binding on write) Root cause getmessagesbyparentid(channelid, parentid) filters the thread replies by channelid, but loads the thread parent by id alone and appends it without requiring parent.channelid == channelid: getchannelthreadmessages() authorizes only…
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 getallmodels handlers in routers/openai.py and routers/ollama.py intended to cache their permission-filtered model lists per user, but the @cached decorator was misconfigured: it passed a key= lambda instead of keybuilder=. In aiocache 0.12.3 (the pinned version), key= is a static cache key — a callable passed there is used as a constant object, not invoked per call. As a result the per-user key was never computed, and all callers collided onto a single shared cache entry within the TTL window. During that window, one user's permission-filtered model list could be served to a different authenticated user, crossing the per-user authorization boundary. Impact - Boundary crossed: Confidentiality (cross-user). A caller can receive the model list scoped to a different security principal than themselves. - A user (or admin, or — depending on endpoint reachability — anonymous caller) who populates the cache causes the next caller within the TTL to receive that list rather than…
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.
Open WebUI upload metadata can add files to knowledge bases without write permission Summary Open WebUI's file upload background processing trusts the client-supplied metadata.knowledgeid value and inserts a knowledgefile association before validating that the uploading user has write access to the target knowledge base. A verified user with only read access to a knowledge base can upload an arbitrary file and set metadata={"knowledgeid":"<target knowledge id"}. The normal /api/v1/knowledge/{id}/file/add endpoint correctly requires knowledge-base write access, but the upload auto-link path bypasses that authorization check. The immediate result is unauthorized modification of the target knowledge base's file membership. The attached attacker-controlled file becomes visible through /api/v1/knowledge/{id}/files, and readers/owners of that knowledge base can retrieve the file through the normal file endpoints because file access is derived from KnowledgeFile membership. Affected Version…
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.
An authenticated low-privilege user can execute arbitrary code-interpreter Python and tools inside another user's authenticated session. The Socket.IO event-caller (geteventcall) delivers execute:python / execute:tool events to a client-supplied sessionid after only checking that the session is connected, never that it belongs to the requester. Combined with ydoc:document:join, which exposes the live socket ids of everyone in a shared note's collaboration room to any read-access participant, an attacker can target a victim's session and run attacker-chosen code/tools in the victim's browser context. When the victim is an administrator, that hijacked context reaches the admin-only Functions API, whose source is executed server-side, yielding remote code execution as the server process (root in the default container). Affected component - backend/openwebui/socket/main.py — geteventcall() / eventcaller - backend/openwebui/main.py — chat-completion metadata (sessionid taken from…
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.
Any authenticated user can overwrite the content of a message in a channel they do not belong to (including private and DM channels) by sending a chat completion request with a channel:-prefixed chatid and a target messageid. The channel: path routes pipeline output through makechannelemitter, which writes to the Messages table using the caller-supplied messageid without binding it to the channel. This advisory consolidates two filings of the same flaw: the original single-model form, and a multimodel messageids variant that survives the partial fix shipped in v0.9.6 (see "Fix status" below). Details (as introduced in v0.9.5) When a user submits a chat completion request with a chatid starting with channel:, three authorization gaps combined in v0.9.5: 1. Ownership check skipped (main.py): the channel: prefix caused the entire ownership/membership verification block to be skipped, with no channel membership/write check replacing it. 2. Message ID from user input: id (and each…
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.
With Redis configured, Open WebUI supports JWT revocation: POST /api/v1/auths/signout (per-token jti) and OIDC back-channel logout (per-user revokedat) record revocations in Redis, and HTTP auth (getcurrentuser) rejects revoked tokens with 401. The realtime authentication surfaces do not perform this check: Socket.IO connect / user-join / join-channels / join-note and the terminal websocket first-message auth validate tokens with decodetoken() only (signature + expiry). A JWT revoked by sign-out or back-channel logout therefore continues to authenticate new realtime connections, even though the same token is rejected on HTTP. Affected component - backend/openwebui/socket/main.py — Socket.IO connect, user-join, join-channels, join-note - backend/openwebui/routers/terminals.py — terminal websocket first-message auth - backend/openwebui/utils/auth.py — the revocation check was applied to HTTP only Root cause HTTP auth enforces revocation: Realtime auth calls decodetoken() only,…
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 Socket.IO server is configured with alwaysconnect=True (lines 78, 91 in backend/openwebui/socket/main.py) and the connect handler (line 329) never rejects unauthenticated connections. Two Ydoc event handlers have zero authentication checks, allowing unauthenticated clients to interact with collaborative document sessions. Vulnerable Code ydoc:awareness:update (line 741) — No auth check at all ydoc:document:leave (line 711) — No auth check at all Root Cause: alwaysconnect=True (line 78) The connect handler (line 329) adds authenticated users to SESSIONPOOL but never returns False or raises an exception for unauthenticated connections. Exploitation 1. An unauthenticated attacker connects via Socket.IO (no token needed) 2. The attacker emits ydoc:awareness:update with: - documentid: a known/guessed note UUID (format: note:{uuid}) - userid: spoofed to impersonate any user - update: arbitrary awareness data (fake cursor positions, selections) 3. The fake awareness data 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.
POST /api/v1/images/edit performed no authorization beyond requiring a verified account. Every other image-editing surface in Open WebUI enforces the global image-edit switch and the per-user image-generation permission — the /api/v1/images/generations route, the built-in editimage tool, and the chat image-edit middleware — but the direct edit route enforced neither. A verified non-admin user could therefore invoke server-side image editing, reaching the configured image-edit provider with the administrator's credentials, even when the administrator had globally disabled image editing (ENABLEIMAGEEDIT=False) or denied that user image-generation permission. The image-editing UI is surfaced only to administrators (Playground), so the route additionally exposed an admin-only capability to any verified user. Impact An authenticated, non-admin user can: - bypass the global ENABLEIMAGEEDIT=False administrator control; - bypass a denied per-user/group features.imagegeneration…
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.
Two regexes in backend/openwebui/utils/middleware.py that parse <$skillId|label skill-mention tags backtrack in O(n²) on input that contains <$ followed by a long run with no closing . Both run synchronously, on the asyncio event loop, on every chat completion with no feature gate. Because the default deployment is a single uvicorn worker, one such input pins a CPU core inside re and freezes the entire instance for all users until the worker is killed. Any authenticated user can trigger it with one chat message; it also fires accidentally on benign retrieved content (a RAG chunk or tool output) containing the pattern. Affected versions = 0.9.2, < 0.10.0. Fixed in v0.10.0 (there is no 0.9.7 release). - SKILLMENTIONRE (the extract pattern) has been O(n²) since v0.9.2; exploitable on 0.9.2–0.9.5 with a large input (hundreds of KB). - v0.9.6 added a second, far more aggressive O(n²) in the strip pattern (introduced by the "keep label as readable text" change), so on 0.9.6 a small…
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.