Cpe:2.3:a:openwebui:open_webui:*:*:*:*:*:*:*:* — CraftedSignal Threat Feedhttps://feed.craftedsignal.io/cpes/cpe2.3aopenwebuiopen_webui/Trending threats, MITRE ATT&CK coverage, and detection metadata. Fed continuously.Hugoenhello@craftedsignal.iohello@craftedsignal.ioThu, 14 May 2026 20:31:48 +0000Open WebUI Stored XSS Vulnerability via OAuth Profile Picturehttps://feed.craftedsignal.io/briefs/2026-05-open-webui-xss/Thu, 14 May 2026 20:31:48 +0000hello@craftedsignal.iohttps://feed.craftedsignal.io/briefs/2026-05-open-webui-xss/Open WebUI is vulnerable to stored cross-site scripting (XSS) via OAuth profile picture handling, allowing an attacker to inject malicious SVG code and potentially takeover user accounts by exfiltrating JWT tokens.Open WebUI versions 0.9.4 and earlier are vulnerable to a stored cross-site scripting (XSS) attack due to improper validation of profile images when users sign in via OAuth. The application fetches a URL provided in the OAuth picture claim, infers the MIME type from the URL extension, and stores it as a data URI without proper sanitization. Specifically, an attacker can host a malicious SVG file and set their profile picture URL to that file. When a victim clicks the link to the attacker’s profile image, the browser executes the SVG code, potentially leading to account takeover by exfiltrating the victim’s JWT token. This vulnerability is similar to CVE-2025-64496 and CVE-2025-64495, which highlights trust boundary errors in Open WebUI.

Attack Chain

  1. The attacker crafts a malicious SVG file containing JavaScript code to exfiltrate localStorage.token.
  2. The attacker hosts the malicious SVG file on a publicly accessible server (e.g., https://attacker.example/p.svg).
  3. The attacker configures their OAuth profile picture URL to point to the malicious SVG file.
  4. The attacker signs in to Open WebUI via OAuth, triggering the application to fetch and store the SVG data URI as their profile image.
  5. The attacker crafts a URL to their profile image endpoint (e.g., https://target.example/api/v1/users/<attacker-user-id>/profile/image) and shares it with a victim.
  6. The authenticated victim clicks on the link.
  7. The server serves the attacker-controlled SVG with Content-Type: image/svg+xml and Content-Disposition: inline.
  8. The victim’s browser renders the SVG, executes the embedded JavaScript, and exfiltrates the victim’s JWT token to the attacker’s server.

Impact

Successful exploitation can lead to account takeover of any authenticated user who clicks the malicious link. The attacker can then access the victim’s chats, API keys, and potentially achieve remote code execution (RCE) via installed tools if the victim has the workspace.tools permission. Furthermore, the lack of SSRF protection allows an attacker to potentially read internal resources by pointing the picture claim at internal URLs.

Recommendation

  • Implement server-side MIME type validation in _process_picture_url (utils/oauth.py:1336-1345) to only allow image/png, image/jpeg, image/gif, and image/webp. Use the Content-Type response header instead of the URL extension.
  • Enforce a MIME whitelist in get_user_profile_image_by_id (routers/users.py:504-528) before building the StreamingResponse.
  • Apply the validate_profile_image_url validator at the model layer (Users.update_user_profile_image_url_by_id), not just at the Pydantic form layer, to ensure all profile image updates are validated.
  • Enable X-Content-Type-Options: nosniff and set a default Content Security Policy (CSP) to mitigate XSS attacks by setting the appropriate environment variables.
]]>highadvisoryxssstored-xssoauthopen-webui