EUVD-2026-44628
GHSA-5p6h-xfw9-p64q
Severity by source
CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:P/VC:H/VI:H/VA:N/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X
Authenticated OAuth user needed (PR:L) and victim must open the image endpoint (UI:R); token theft yields account takeover (C:H/I:H), no availability impact and same-origin script keeps scope unchanged.
Primary rating from Vendor (VulnCheck).
CVSS VectorVendor: VulnCheck
Lifecycle Timeline
4DescriptionCVE.org
Open WebUI before 0.9.5 contains a stored cross-site scripting vulnerability in the OAuth authentication flow where the picture claim URL MIME type is inferred from file extension rather than Content-Type header, allowing SVG files to bypass the profile image validator and be stored as data URIs. Authenticated users who visit the profile image endpoint receive attacker-controlled SVG content with inline disposition and no default security headers, enabling script execution in the same origin to steal authentication tokens and achieve account takeover.
AnalysisAI
Stored cross-site scripting in Open WebUI before 0.9.5 lets an attacker plant a malicious SVG as a victim's OAuth profile image and execute script in the application's origin. During OAuth login, the picture claim URL is fetched and its MIME type is guessed from the file extension rather than the response Content-Type, so a .svg URL is stored as a data:image/svg+xml;base64,... URI that bypasses the profile-image allowlist; when an authenticated user opens the profile image endpoint the SVG is served inline with no default CSP, running JavaScript that reads localStorage.token for account takeover. Reported by VulnCheck with a detailed GHSA source-code advisory; no public exploit identified at time of analysis and it is not in CISA KEV.
Technical ContextAI
The flaw lives in Open WebUI's OAuth identity-provisioning code (backend/open_webui/utils/oauth.py, _process_picture_url). When a user authenticates via an OpenID Connect / OAuth provider, Open WebUI downloads the image referenced by the IdP picture claim, base64-encodes it, and derives the MIME type using Python's mimetypes.guess_type(picture_url) - an extension-based lookup that trusts the URL string and ignores the actual HTTP Content-Type. This is a classic CWE-20 improper input validation / trust-boundary error: the normal validate_profile_image_url Pydantic validator (in utils/validate.py) restricts profile images to PNG/JPEG/GIF/WebP, but the OAuth existing-user (oauth.py:1536-1540) and new-user (oauth.py:1556-1574) write paths call SQLAlchemy directly via Users.update_user_profile_image_url_by_id / Auths.insert_new_auth, never instantiating those Pydantic models, so the allowlist is skipped entirely. SVG is an active content type - it can carry inline <script> and event handlers - and the endpoint GET /api/v1/users/{id}/profile/image returns the stored data URI with the attacker-chosen image/svg+xml Content-Type and Content-Disposition: inline, while CSP and X-Content-Type-Options are environment-gated and unset by default. The only affected product is open-webui/open-webui (CPE cpe:2.3:a:open-webui:open-webui:*:*:*:*:*:*:*:*). The advisory notes this is the same trust-boundary class as CVE-2025-64496 and CVE-2025-64495 but a distinct sink and code path.
RemediationAI
Vendor-released patch: 0.9.5 - upgrade Open WebUI to 0.9.5 or later, which routes OAuth-supplied profile images through proper validation. If you cannot upgrade immediately, apply concrete compensating controls: enable a restrictive Content-Security-Policy and set X-Content-Type-Options: nosniff via the environment-gated security-header settings (this neutralizes inline SVG script execution but may require testing against any legitimate inline-content features), and enforce a server-side allowlist so profile images stored as data URIs are limited to PNG/JPEG/GIF/WebP (blocking image/svg+xml). Where feasible, disable OAuth-based profile-image import or the OAuth login path entirely until patched (trade-off: users lose IdP avatar sync / SSO convenience). Reference the vendor advisory GHSA-3wgj-c2hg-vm6q for the authoritative fix. Do not invent alternate version numbers - 0.9.5 is the confirmed fixed release.
More in Open Webui
View allA vulnerability in open-webui/open-webui version 0.3.8 allows an attacker with a user-level account to perform a session
An XSS vulnerability exists in open-webui/open-webui versions <= 0.3.8, specifically in the function that constructs the
A Stored Cross-Site Scripting (XSS) vulnerability exists in the chat file upload functionality of open-webui/open-webui
A vulnerability in open-webui/open-webui versions <= 0.3.8 allows remote code execution by non-admin users via Cross-Sit
Attacker controlled files can be uploaded to arbitrary locations on the web server's filesystem by abusing a path traver
Open WebUI is a self-hosted artificial intelligence platform designed to operate entirely offline. Prior to 0.6.37, a St
Open WebUI is a self-hosted artificial intelligence platform designed to operate entirely offline. Prior to 0.6.37, a Se
A stored cross-site scripting (XSS) vulnerability exists in open-webui/open-webui version 0.3.8. Rated high severity (CV
In version v0.3.10 of open-webui/open-webui, the `api/v1/utils/pdf` endpoint lacks authentication mechanisms, allowing u
In open-webui version 0.3.8, the endpoint `/models/upload` is vulnerable to arbitrary file write due to improper handlin
The `/openai/models` endpoint in open-webui/open-webui version 0.3.8 is vulnerable to Server-Side Request Forgery (SSRF)
In version 0.3.32 of open-webui/open-webui, the absence of authentication mechanisms allows any unauthenticated attacker
Same weakness CWE-20 – Improper Input Validation
View allShare
External POC / Exploit Code
Leaving vuln.today