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's OAuth token exchange endpoint issues a session for a provider access token without running the OAuth role management that the normal OAuth login callback runs. A user whose provider roles the login callback would refuse, or would demote, could still obtain a working session at their existing role through this endpoint. Preconditions - ENABLEOAUTHTOKENEXCHANGE=True. It is disabled by default, so a default deployment is not affected. - ENABLEOAUTHROLEMANAGEMENT=True together with OAUTHALLOWEDROLES or OAUTHADMINROLES. Role management is off by default, and deployments not using it are not affected. - A valid, unexpired access token on the configured provider. - An Open WebUI account already linked to that provider subject, or an account with a matching email when OAUTHMERGEACCOUNTSBYEMAIL is enabled. This endpoint never creates accounts, so a token for a subject with no existing account is rejected. Impact An admin who relies on OAuth role management expects a user…
Recommended action: Upgrade to 0.11.1 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
The OIDC back-channel logout endpoint is unauthenticated by design, because the identity provider calls it without a browser session. Before checking whether the submitted logout token was genuine, the handler fetched the provider's discovery document and its signing keys over the network, and repeated both fetches on every request because nothing was cached. The signing-key fetch also ran as a blocking call inside the async event loop. A small number of requests carrying a worthless token was therefore enough to make the whole instance stop answering. Preconditions - ENABLEOAUTHBACKCHANNELLOGOUT=true. The default is False, so a stock deployment is not affected. This setting is recommended in the Open WebUI hardening documentation, which is why the issue is treated as in scope. - At least one OIDC provider configured (OAUTHCLIENTID, OAUTHCLIENTSECRET, OPENIDPROVIDERURL). - No account, credential, session or secret identifier is required. The attacker needs network access to…
Recommended action: Upgrade to 0.11.1 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 suppress calendar alerts instance-wide via a non-numeric alert value Summary Calendar events carry a free-form meta object that is stored exactly as submitted, with no validation of the values inside it. The scheduler reads the per-event alert offset out of that object in a single pass that covers every user's upcoming events, and compares it numerically without checking that it is a number. Any verified user could store a text value there, which made the comparison raise and abort the whole pass, so no calendar reminder fired for anyone on the instance while that event stayed inside the lookahead window. Preconditions - Calendar is enabled (ENABLECALENDAR / calendar.enable, default True). - The attacker is a verified user (role user or admin) holding the calendar feature permission, which is granted to all users by default (USERPERMISSIONSFEATURESCALENDAR, default True). - The event's start time falls inside the scheduler's one hour lookahead window, so…
Recommended action: Upgrade to 0.11.1 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 move one of their own folders under itself, leaving a loop in their folder tree. The re-parent endpoint performed no check that the new parent was not the folder itself or one of its own subfolders, and the folder tree walks did not track which folders they had already visited. A single request against a folder in a loop therefore never finishes. Preconditions Folders must be enabled (ENABLEFOLDERS, default true) and the acting user's role must hold the folders feature permission (USERPERMISSIONSFEATURESFOLDERS, default true). Both are on in a default install. Any authenticated account is sufficient: no administrator, no second user, no shared folder and no victim interaction. Deployments that disable folders, or withhold the folders feature permission from non-admin roles, are not affected. Impact A single request that never returns. It keeps running after the client disconnects, holds a CPU core and grows its in-memory folder list at roughly 0.6…
Recommended action: Upgrade to 0.11.1 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
A user who is demoted from admin by an identity provider keeps admin-level read and write access to every user's notes, over any Socket.IO connection that was already open when the demotion happened. Open WebUI caches the user's role on the socket at connection time, and the two SSO role-sync paths, the reverse-proxy trusted role header and OAuth role mapping, changed the role in the database without tearing that cached session down. Only the admin user-management endpoints invalidated sessions, so a demotion driven by the identity provider left the old privileges live on the socket. Preconditions A role-sync SSO mode has to be enabled. Either trusted-header authentication with WEBUIAUTHTRUSTEDROLEHEADER set, which is unset by default, or OAuth with role mapping enabled, which is off by default. Deployments that change roles only through the admin panel are not affected, because that path already invalidated the user's sockets. The account has to be an admin at the moment it…
Recommended action: Upgrade to 0.11.1 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
When more than one external tool server is reachable in the same request, a tool call to a server configured for bearer authentication can arrive carrying the calling user's Open WebUI session cookies alongside that server's own key. The cookie jar is built per connection, but the callable that performs the request reads it late instead of per connection, so every tool callable built in the same pass sends the cookies belonging to whichever connection was processed last. An administrator who configures a server with its own API key has not chosen to send that server anything else, and the operator of that server receives a live session credential for the user who triggered the call. Preconditions At least two external tool servers must be attached to the same request, and at least one of them must be set to session or system OAuth authentication, since no cookie jar is assembled otherwise. The connection using that authentication mode must be the one processed last, which…
Recommended action: Upgrade to 0.11.1 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
On SQLite deployments, the lookup that maps an external identity to a local account does a substring match instead of an exact match. A subject value containing SQL wildcard characters therefore matches accounts the value was never issued for, and the sign-in binds to whichever account the database returns first, which can be an administrator. The same defect affects SCIM external-ID resolution. PostgreSQL deployments are not affected, because they take a separate and correct code path. Preconditions The database is SQLite. This is the default backend. PostgreSQL deployments are not affected at all. OAuth or OIDC sign-in is configured, or SCIM provisioning is enabled. Both are off by default. For an attacker to steer the match deliberately, they must control the value of the claim Open WebUI uses as the subject. That value is normally assigned by the identity provider and is not attacker-controlled: the shipped GitHub and Feishu configurations use provider-assigned numeric…
Recommended action: Upgrade to 0.11.1 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
The built-in knowledge search tool returns knowledge bases the calling user has no access to. The tool works out which knowledge bases the caller may read and hands that set to the vector store as a search filter, and that filter is the only access control on the path. Most of the shipped vector backends accept the filter argument on their search method and never apply it, so the search returns matches from every knowledge base in the shared collection. The sibling query method on those same backends does apply a filter, which is why the omission is invisible from the calling code. Preconditions - The deployment must use one of the affected vector backends, selected with VECTORDB, which defaults to chroma. Chroma applies the filter, so a default deployment is not affected. - Eleven of the fifteen shipped backends ignore the filter: both Qdrant clients, Elasticsearch, OpenSearch, both Milvus clients, openGauss, Oracle 23ai, Pinecone, S3 Vectors and Weaviate. Chroma, pgvector,…
Recommended action: Upgrade to 0.11.1 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Any member of a channel who can post to it could also replace the text of a message written by a different member. The channel branch of the chat completions endpoint checked that the caller may write to the channel, and that the targeted message belongs to that channel, but never checked that the caller actually wrote the message being edited. The message kept its original author, so the replacement text was displayed and stored as though the victim had written it. The dedicated channel message edit route performed the authorship check correctly and refused the same edit, so the two paths disagreed about who may modify a message. Preconditions - Channels must be enabled. ENABLECHANNELS defaults to False, so a default deployment is not affected until an administrator turns channels on. - The attacker must be an approved user holding write access to the target channel, which is the ordinary state for any participant. No elevated role, group membership or additional permission…
Recommended action: Upgrade to 0.11.1 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 shared terminal server could get script of their choosing to run in the Open WebUI origin itself. The in-app port preview rendered the content of a previewed port in an iframe whose sandbox always granted allow-same-origin alongside allow-scripts, and that content is served from a path on the application's own origin, so the sandbox provided no isolation at all. Script served on a previewed port 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 both the attacker and the victim. Deployments with no terminal server configured are not affected. - The attacker needs a normal authenticated account with access to that terminal connection, no admin rights, plus the ability to start a process listening on a port there. - Personal terminals a user configures for themselves are not affected. Those carry…
Recommended action: Upgrade to 0.11.1 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 checks the address behind a user-submitted URL before allowing the request, then handed the request to the browser to perform. The browser resolved the hostname a second time, on its own, and that answer was never checked. An attacker who controls the authoritative DNS for a hostname they submit can answer the first lookup with a public address and the second with an internal one, so the browser connects to an address the check exists to block. The connection-layer pinning that protects the other fetch paths could not apply here, because the request ran inside the browser rather than through our own HTTP clients. Preconditions - WEBLOADERENGINE=playwright. This is not the default, and 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.…
Recommended action: Upgrade to 0.11.1 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
The chat-completions endpoint reads a folder id out of the request body and saves the newly created chat into that folder without checking that the caller is allowed to write there. Any authenticated user who knows a folder's id can put a chat of their own into another user's folder, including a shared folder where they hold read-only access and a folder they have no access to at all. The chat then shows up in that folder for everyone who can read it, under a title and with content the attacker controls. The dedicated chat-creation and chat-move endpoints already enforced this check, the chat-completions path did not. Preconditions - An authenticated account of any role. No elevated permission, no admin involvement. - Folders enabled, which is the default (ENABLEFOLDERS=true, USERPERMISSIONSFEATURESFOLDERS=true). - The attacker needs the target folder's id. A member of a shared folder gets it from the shared-folder listing. Sharing a folder with named users is available to…
Recommended action: Upgrade to 0.11.1 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
External knowledge connections are created and owned by administrators, and are shared by every external knowledge base bound to them. Deleting an external knowledge base also removed that connection from the instance configuration, with no check on the caller's role and no check for other knowledge bases still using it. Any authenticated user holding a write grant on a single external knowledge base could therefore wipe a shared connection that other knowledge bases depend on, and the dedicated administrator route for deleting a connection explicitly refuses that same operation while the connection is still in use. Preconditions The deployment uses external knowledge bases, backed by the qdrant, milvus or pgvector external providers. Instances with only local knowledge bases are not affected. An administrator created at least one external connection and at least one external knowledge base bound to it. Both of those actions are admin-only. The attacker is an ordinary…
Recommended action: Upgrade to 0.11.1 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 and web search, and screens the resolved addresses so internal destinations cannot be reached. That screen decided whether a destination was external by asking Python's standard library whether the address is globally routable. Several addresses reserved for internal use answer yes to that question, including 168.63.129.16, the Azure platform channel every Azure virtual machine can reach. Any authenticated user could therefore make the server issue requests to those addresses and read the responses back through the API. Preconditions - The affected paths are the server-side URL fetches: RAG URL ingestion and web search. Both require an authenticated, verified account. No administrator role and no special workspace permission are needed. - ENABLELOCALWEBFETCH must be at its default of false. Setting it to true disables the address screen by design, and internal destinations are reachable on purpose. -…
Recommended action: Upgrade to 0.11.1 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 OAuth token exchange endpoint issues a session for a provider access token without applying the email domain allowlist that the normal OAuth login callback enforces. An account whose email domain the login callback would refuse could still obtain a working session through this endpoint. Preconditions - ENABLEOAUTHTOKENEXCHANGE=True. It is disabled by default, so a default deployment is not affected. - OAUTHALLOWEDDOMAINS set to something other than . Deployments without a domain allowlist are not affected. - A valid, unexpired access token on the configured provider. - An Open WebUI account already linked to that provider subject, or an account with a matching email when OAUTHMERGEACCOUNTSBYEMAIL is enabled. This endpoint never creates accounts, so a token for a subject with no existing account is rejected. Impact An admin who narrows the domain allowlist expects users outside it to lose access at their next sign-in. The login callback does deny them. Token…
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.
Chat histories are stored as an unvalidated JSON object. After a message is deleted, the code that picks the chat's new current message walked down the childrenIds links without recording where it had already been. Any account with the default user role could store a chat whose messages list each other as children, then delete a message from it, and the walk would run forever. That walk runs on the server's request loop, so it blocks every other user's requests until the process is killed. Preconditions One account with the default user role. No administrator rights, no additional permissions, no configuration change and no non-default setting: creating and deleting chats is available to every user out of the box. The attack runs entirely against the attacker's own chat, so no knowledge of any other user's data is needed. Versions before 0.10.0 are unaffected because neither the message-deletion endpoint nor the affected code existed. Impact The walk is synchronous and runs…
Recommended action: Upgrade to 0.11.1 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Open WebUI protects server-side web fetches with two controls: the operator's list of excluded hosts, and a check that refuses private and internal addresses. Neither control was applied to the destination of an HTTP redirect. On a deployment where redirect following is enabled, any authenticated user who can cause the server to fetch a URL could submit a page that redirects, and the server would fetch the redirect destination without either control being applied to it. The server therefore connects to hosts the operator excluded, and to internal addresses including loopback, private networks and cloud metadata endpoints. Preconditions AIOHTTPCLIENTALLOWREDIRECTS must be set to true. Its default is false, and on the default the affected fetch paths do not follow redirects at all, so a deployment that has not changed this setting is not affected. The attacker needs an authenticated account of any role, with access to any feature that causes the server to fetch a URL. Web…
Recommended action: Upgrade to 0.11.1 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Chat histories are stored as an unvalidated JSON object. The walk that reconstructs a chat's message chain detected repeats using each message's own id field while moving through the history by map key, so a message that simply omitted id was never recorded as visited. A history whose messages referenced each other in a parent cycle therefore made the walk run forever. Any account with the default user role could store such a chat and trigger the walk, blocking the server for everyone. Preconditions One account with the default user role. No administrator rights, no additional permissions, no configuration change and no non-default setting: creating a chat is available to every user out of the box. The attack runs entirely against the attacker's own chat, so no knowledge of any other user's data is needed. Instances where every account is trusted are affected in the sense that the fault is reachable, but require a user acting deliberately. Impact The walk is synchronous and…
Recommended action: Upgrade to 0.11.1 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
A user granted write access to a shared chat folder could permanently delete chats and messages belonging to the folder's owner. Deleting a folder cascades into the owner's chats and the entire subfolder subtree, and the deletion handler required only write access on subfolders instead of ownership. Root folders were restricted to the owner or an admin, subfolders were not. Preconditions The Folders Sharing permission (user.permissions.sharing.folders) must be enabled; it is off by default. The victim must have shared a folder with the attacker at write access. features.folders and the chat.delete permission are enabled by default and are both required. Deployments that leave folder sharing disabled are not affected, and neither are single-user instances. Impact Permanent, irreversible destruction of another user's chat history within and beneath a shared folder. With deletecontents=false the same request instead force-moved the owner's chats out of the folder, an…
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 built-in knowledge search tools let a chat participant choose the pattern used to grep knowledge files. Patterns containing regex metacharacters were compiled with Python's backtracking re engine and run against every line of every reachable file, with no time limit anywhere on that path. A single crafted pattern and a single short line of matching text pin one CPU core for as long as the attacker wants, and because the search runs synchronously inside the event loop, that worker serves nobody else while it spins. Preconditions - Default configuration. The knowledge builtin tool group is enabled by default, and with ENABLEKBEXEC at its default of False the model is handed grepknowledgefiles, which is the affected path. - Any authenticated user, no elevated role and no workspace permission. - One file the attacker can read. USERPERMISSIONSCHATFILEUPLOAD defaults to true and a user always has read access to their own upload, so both halves of the input are…
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 can store a chat message whose math block makes KaTeX fail with a stack overflow instead of a parse error. When that happens the renderer falls back to inserting the original math source into the page as HTML rather than as text, so script in the message runs in the browser of whoever views it. Every surface that renders messages is affected, including shared chats and channels, and the missing control is output escaping on the error path. Preconditions Default configuration, no flags involved. The attacker needs a normal user account and a way to get the target to open the content: a shared chat link, a channel the target reads, or any other message surface. No admin rights and no non-default settings are required on either side. Impact Script executes in the viewer's browser on the Open WebUI origin, which puts the session token in localStorage within reach and therefore allows taking over the viewing account. If the viewer is an administrator, that…
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 workspace tool shared with a read grant returned its full Python source to the recipient. Any authenticated non-admin who could use a shared tool could also read its source, including any user on the instance when a tool was shared publicly. Source is meant to be a writer-only tier: the list response schema deliberately omits it and source export sits behind its own permission. The read endpoints delivered it anyway. Preconditions - Authentication enabled (WEBUIAUTH=true, default) and plugins enabled (ENABLEPLUGINS=true, default). - The attacker is an authenticated non-admin without the workspace.tools permission and without a write grant on the tool. - A tool is shared with a read grant to the attacker, to one of their groups, or to all users (user:). Deployments that share no tools, or share them only with users who already hold write access, are not affected. Impact A non-admin obtains another user's server-side tool source. Tool source commonly embeds hard-coded API…
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 terminal WebSocket route authenticates its own first-message JWT instead of going through the HTTP dependency chain, and never applies the role check that getverifieduser enforces on every HTTP terminal route. An account whose role is pending, meaning registered but not approved, or approved and later deactivated back to pending, can therefore open an interactive terminal session that the HTTP terminal endpoints would refuse. The missing control is the verified-user role gate, not the terminal access grants, which are evaluated correctly. Preconditions At least one terminal server must be configured, which is off by default, and its access grants must cover the account: either public read (principalid: "") or a group the account still belongs to. The attacker needs a valid, unexpired JWT for a pending account and the terminal server id. Both are obtainable by an account that registered while approvals are pending, or by one that held access and was deactivated, since…
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.
In every affected release, automation recurrence parsing anchors minutely and hourly rules at a fixed date of 2000-01-01 and then walks forward one interval at a time to find the next run. A single FREQ=MINUTELY rule therefore enumerates roughly a quarter-century of occurrences, synchronously, on the event loop that also serves the scheduler, HTTP and WebSocket traffic. Nothing bounds the walk, and nothing moves it off the loop. Preconditions Any user who can create an automation. USERPERMISSIONSFEATURESAUTOMATIONS defaults to false, so on a default deployment only an admin can reach the create path; it becomes reachable by ordinary users on any deployment that has granted the automations feature, which is the normal way to make the feature usable. UVICORNWORKERS defaults to 1, so there is no second worker to absorb the stall. The rule needs no unusual syntax: FREQ=MINUTELY with no DTSTART, or with a DTSTART set well in the past, is enough. Impact Availability, against every…
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 vetted user-supplied URLs by resolving the hostname once and rejecting private, loopback and link-local addresses, then let the HTTP client resolve that hostname again at connect time. An attacker who controls the authoritative DNS for a hostname they submit can answer with a public address during the check and an internal one at connect, so the fetch reaches an address the check was meant to block. Every user-reachable fetch gated by that check was affected, and most of them hand the internal response back to the attacker. Preconditions - An account on the instance. No admin rights and no non-default configuration. - Control of the authoritative DNS for a hostname the attacker submits, serving a TTL of 0 and alternating answers. - One of the affected entry points: URL ingest for retrieval, an imageurl in a chat completion, image editing, or the OAuth profile-picture fetch. - The OAuth path additionally needs OAuth login configured and a picture claim…
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.