Summary 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 enforced on every path.

Impact An authenticated user could read the indexed chunks of another user's or group's file, a cross-user confidentiality loss limited to files whose ids the attacker already holds. It is read-only: nothing is modified or deleted, knowledge-base permissions are unaffected, and saved workspace models were already validated at creation time.

Fix Fixed in 0.11.0 by commit 305880f2e. An inline model's attached knowledge is filtered against the caller's real read access before it is used, dropping any file, knowledge base or note the caller cannot read. Upgrading fully resolves it, no configuration change is required.

Root cause Affected component: the chat completion, chat completed and chat action endpoints, which accept an inline model definition, and the builtin knowledge tools that consume the model's attached knowledge. Affected setups: all builds from 0.8.8 through 0.10.2.

Saved workspace models have their attached file references validated against the author when the model is created, updated or imported, so a stored model can only carry files its creator can read. An inline model never passes through that path, yet everything downstream treated its attached knowledge with the same trust, including a helper that grants read access to a file purely because the running model claims it as attached knowledge. The missing control was an access check at the point where client-supplied model metadata enters the request.

Credits Reported by @whyiug.

Summary 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 deactivation sets the role to pending without revoking the token, which lasts four weeks by default. Deployments with no terminal server configured, or whose terminal grants are admin-only, are not affected.

Impact A deployment loses the account-approval boundary for terminal access. An unapproved or deactivated account gets interactive shell access, file browsing and terminal-backed tooling in the terminal environment, for as long as its token remains valid. Because the HTTP terminal routes correctly reject the same account, the two planes disagree, so an administrator who deactivates a user sees access revoked over HTTP while the WebSocket keeps working. The terminal access grants themselves are not bypassed: an account with no grant is still refused, so this only widens access to terminals already shared broadly or with a group the account remains in.

Fix Fixed in v0.11.0 by https://github.com/open-webui/open-webui/pull/27537. Token decoding, revocation checking, user lookup and the role check are consolidated into a single getverifieduserbytoken helper, and both the terminal WebSocket route and the Socket.IO handshake now go through it. The role set lives in one constant shared with the HTTP gate so the two cannot drift apart again. Upgrading fully resolves the issue; no configuration change is required.

Root cause Affected component: backend/openwebui/routers/terminals.py, the resolveauthenticatedconnection helper backing the /{serverid}/api/terminals/{sessionid} WebSocket route. Affected setup: every build from v0.8.8 onward, since the route was introduced there.

WebSocket handshakes cannot use FastAPI dependencies, so this route reimplemented authentication inline. The reimplementation reproduced the parts that are visible in the token, that it decodes and that the user row exists, and silently dropped the part that lives in the database row, the role check. Authorization then ran on two independent code paths with no shared definition of what an authenticated user is, and only one of them was updated when the role gate was introduced.

Credits Reported by @rexpository.