Vulnerabilities

Open WebUI versions 0.6.41 until 0.11.1 contain an authentication flaw in the user-lookup functions get_user_by_oauth_sub and get_user_by_scim_external_id (backend/open_webui/models/users.py): on SQLite, their JSON 'contains' matching compiles to SQL LIKE substring matching, leaving percent (%) and underscore (_) characters unescaped as LIKE wildcards. An OAuth subject or SCIM external ID containing these wildcard characters can therefore resolve to a different stored identity — potentially an administrator account — and the attacker is issued that account's session, effectively an authentication bypass that grants the privileges of the matched account. Exploitation requires unusual conditions (an attacker-controllable identity value with wildcard characters that collides with another account, e.g. an admin), reflected in the high attack complexity of the 8.1 High CVSS score. Only deployments using the SQLite backend with OAuth or SCIM login are affected; PostgreSQL deployments are not. No public proof-of-concept, CISA KEV listing, or known in-the-wild exploitation exists as of this analysis.

Do: Upgrade to Open WebUI 0.11.1 or later, which escapes the wildcard matching. If immediate upgrade is not possible, either migrate the backend to PostgreSQL (not affected) or restrict/disable OAuth and SCIM logins, and check whether any user's OAuth sub or SCIM external ID contains '%' or '_' characters that could collide with other accounts — especially administrators. Review active sessions on privileged accounts for logins you cannot attribute.

open-webui before 0.3.14 contains a cross-origin resource sharing misconfiguration allowing arbitrary origins with allow_origins=* and authenticated requests to the /api/v1/functions endpoint. Attackers can execute arbitrary code on the openwebui instance by crafting malicious cross-site requests from attacker-controlled websites when an admin user visits them.

Open WebUI is an extensible, feature-rich, and user-friendly self-hosted AI platform. Prior to 0.10.0, get_event_call delivered execute:python and execute:tool Socket.IO events to a client-supplied session_id after checking only that the session was connected, allowing authenticated users who learned another socket ID through ydoc:document:join to run code interpreter Python or tools in that user session. This issue is fixed in version 0.10.0.

Open WebUI is a self-hosted artificial intelligence platform designed to operate entirely offline. Prior to 0.9.6, backend/open_webui/utils/oauth.py::_process_picture_url calls validate_url(picture_url) on the initial URL only, then invokes aiohttp.ClientSession.get(picture_url, ...) without allow_redirects=False. aiohttp's default is allow_redirects=True, max_redirects=10; the function does not pass the project's AIOHTTP_CLIENT_ALLOW_REDIRECTS 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 profile_image_url field. This vulnerability is fixed in 0.9.6.

Open WebUI is a self-hosted artificial intelligence platform designed to operate entirely offline. Prior to 0.9.6, the terminal-server reverse proxy in `backend/open_webui/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: first, raw path forwarding / single-encoded traversal (original report); and second, a bypass of the subsequently-added `_sanitize_proxy_path` mitigation using double-encoded dots (`%252e%252e`). The attacker-controlled input is the request `path`, supplied by the non-admin user, not anything an administrator configures, so this is not an admin-trust / Rule-9 situation. Version 0.9.6 fixes the issue.