CVE-2026-26193: Open WebUI Stored XSS Vulnerability

CVE-2026-26193 Overview

Open WebUI is a self-hosted artificial intelligence platform designed to operate entirely offline. A stored cross-site scripting (XSS) vulnerability exists in versions prior to 0.6.44 that allows attackers to inject malicious scripts through manually modified chat history. The vulnerability stems from improper handling of the embeds property on response messages, which are loaded into an iFrame with a sandbox configuration that includes allow-scripts and allow-same-origin, bypassing the "iframe Sandbox Allow Same Origin" configuration setting.

Critical Impact

This stored XSS vulnerability enables attackers to create shareable links containing malicious payloads that can be distributed to any user on the Open WebUI instance, potentially compromising user sessions and sensitive data.

Affected Products

• Open WebUI versions prior to 0.6.44

Discovery Timeline

• 2026-02-19 - CVE CVE-2026-26193 published to NVD
• 2026-02-19 - Last updated in NVD database

Technical Details for CVE-2026-26193

Vulnerability Analysis

This vulnerability is classified as CWE-79 (Improper Neutralization of Input During Web Page Generation), commonly known as Cross-Site Scripting (XSS). The flaw allows authenticated attackers to bypass security controls by manually manipulating chat history to set the embeds property on response messages.

The core issue lies in the iFrame sandbox configuration within the ResponseMessage.svelte component. When embedding content, the application sets both allow-scripts and allow-same-origin sandbox attributes simultaneously. This combination is particularly dangerous because it effectively negates the security benefits of sandboxing—scripts running within the iFrame can access the parent document's DOM and cookies as if no sandbox existed.

The vulnerability has significant implications for confidentiality and integrity, as successful exploitation could allow attackers to steal session tokens, manipulate displayed content, or perform actions on behalf of authenticated users. The attack requires user interaction (clicking a shared link) and low privileges (authenticated access), but the network-accessible nature of the platform increases the overall risk.

Root Cause

The root cause is the insecure iFrame sandbox configuration in the ResponseMessage.svelte component. The application fails to properly restrict embedded content permissions by allowing both script execution (allow-scripts) and same-origin access (allow-same-origin) within the sandbox. This configuration ignores the application's "iframe Sandbox Allow Same Origin" setting, creating a security bypass that enables stored XSS attacks through the embeds property of chat messages.

Attack Vector

The attack vector is network-based and requires an authenticated attacker with the ability to modify chat history. The exploitation flow involves:

1. An authenticated attacker manually modifies their chat history to inject a malicious payload into the embeds property of a response message
2. The malicious content is rendered within an iFrame that has dangerous sandbox permissions
3. The attacker shares the compromised chat using the platform's sharing functionality
4. When other users access the shared link, the malicious script executes in their browser context with same-origin privileges
5. The script can then access session data, perform unauthorized actions, or further propagate the attack

The vulnerability can be exploited through the shared chat format, making it particularly effective for targeting multiple users across the Open WebUI instance. For technical implementation details, refer to the GitHub Code Snippet and GitHub Security Advisory.

Detection Methods for CVE-2026-26193

Indicators of Compromise

• Unusual modifications to chat history records containing embeds properties with script content
• Shared chat links containing suspicious JavaScript or HTML payloads
• Unexpected network requests originating from iFrame contexts to external domains
• User reports of unexpected behavior when accessing shared chat links

Detection Strategies

• Monitor chat database records for the presence of embeds properties containing HTML or JavaScript content
• Implement Content Security Policy (CSP) violation logging to detect script execution attempts from embedded content
• Review web server access logs for patterns indicating distribution of malicious shared chat links
• Deploy browser-based XSS detection tools to identify script injection attempts in chat content

Monitoring Recommendations

• Enable verbose logging for chat history modifications and sharing events
• Implement real-time alerting for CSP violations related to iFrame content
• Monitor user activity patterns for unusual chat sharing behavior, especially bulk sharing operations
• Configure SentinelOne Singularity Platform to detect and block XSS attack patterns targeting web applications

How to Mitigate CVE-2026-26193

Immediate Actions Required

• Upgrade Open WebUI to version 0.6.44 or later immediately
• Audit existing shared chat links for potential malicious content
• Review chat history records for suspicious embeds property modifications
• Invalidate and regenerate session tokens for all users as a precautionary measure

Patch Information

The vulnerability has been addressed in Open WebUI version 0.6.44. Organizations should upgrade to this version or later to remediate the vulnerability. The fix properly restricts the iFrame sandbox configuration to prevent the allow-same-origin permission from being set in conjunction with allow-scripts. For complete details about the security fix, refer to the GitHub Security Advisory.

Workarounds

• Disable the chat sharing feature until the patch can be applied
• Implement additional Content Security Policy headers to restrict script execution in embedded content
• Restrict user access to chat history modification capabilities where possible
• Deploy a web application firewall (WAF) with XSS detection rules to filter malicious payloads

# Example: Add restrictive Content Security Policy header
# In your reverse proxy (nginx example):
add_header Content-Security-Policy "frame-src 'self'; script-src 'self'; frame-ancestors 'self';" always;