CVE-2026-44549: Open WebUI XSS Vulnerability

CVE-2026-44549 Overview

CVE-2026-44549 is a stored cross-site scripting (XSS) vulnerability in Open WebUI, a self-hosted artificial intelligence platform designed to operate entirely offline. Versions prior to 0.8.0 preview Excel file attachments unsafely. A crafted XLSX payload abuses the SheetJS sheet_to_html function to embed script content in the generated HTML. Open WebUI then injects the result into the Document Object Model (DOM) unsanitized using Svelte's @html directive, which executes the attacker's payload. The vulnerability is tracked as [CWE-79] and fixed in version 0.8.0.

Critical Impact

An authenticated user can upload a malicious XLSX file that executes arbitrary JavaScript in another user's browser session, enabling session theft, account takeover, and lateral access to AI workloads.

Affected Products

• Open WebUI all versions prior to 0.8.0
• Self-hosted Open WebUI deployments accepting Excel file attachments
• Multi-user Open WebUI instances where users can share or preview uploaded files

Discovery Timeline

• 2026-05-15 - CVE-2026-44549 published to the National Vulnerability Database (NVD)
• 2026-05-19 - Last updated in NVD database

Technical Details for CVE-2026-44549

Vulnerability Analysis

The vulnerability resides in the Excel file preview pipeline of Open WebUI. When a user uploads an XLSX attachment, the application invokes the SheetJS library to convert spreadsheet content into HTML for in-browser rendering. The sheet_to_html function does not strip script-bearing constructs that an attacker can embed inside crafted cells or sheet metadata. The resulting HTML string is then bound to the DOM through Svelte's @html directive, which performs no sanitization. Any JavaScript present in the generated markup executes in the victim's browser within the Open WebUI origin.

Because the payload triggers when a separate user previews the attachment, the attack achieves stored XSS with cross-user reach. The attacker only needs the privileges required to upload or share a file. The scope change reflected in the data indicates compromise extends beyond the vulnerable component to other browser-side resources, including authenticated AI session context.

Root Cause

The root cause is missing output sanitization on HTML produced by an untrusted-input transformation. Open WebUI treats sheet_to_html output as safe, but the function preserves cell content verbatim, including HTML tags and event handlers. Combining a non-sanitizing renderer (@html) with attacker-controlled input violates the contextual output encoding requirement defined by [CWE-79].

Attack Vector

The attack is network-reachable and requires authenticated upload access plus user interaction in the form of opening the file preview. An attacker crafts an XLSX file containing HTML or script payloads inside spreadsheet cells. The attacker uploads or shares the file in a chat, workspace, or knowledge base. When a victim previews the file, Open WebUI renders the malicious HTML and executes the embedded JavaScript under the victim's session, allowing token theft, API abuse, and prompt or model manipulation.

No verified exploit code is publicly available. See the GitHub Security Advisory GHSA-jwf8-pv5p-vhmc for technical details.

Detection Methods for CVE-2026-44549

Indicators of Compromise

• XLSX files uploaded to Open WebUI containing HTML tags such as <script>, <img onerror=>, or <iframe> inside cell values
• Browser console errors or unexpected outbound requests originating from the Open WebUI origin during file preview
• Session tokens or API keys appearing in outbound traffic toward attacker-controlled domains shortly after a preview action
• New or modified administrative accounts created shortly after an XLSX preview by a privileged user

Detection Strategies

• Inspect uploaded XLSX files for embedded HTML, JavaScript URIs, or event-handler attributes in cell content before they are stored
• Monitor the Open WebUI application for unusual fetch or XMLHttpRequest calls initiated from the file preview view
• Correlate file upload events with subsequent authentication or privilege changes in the same session
• Apply a Content Security Policy (CSP) report-only header and alert on violations triggered by inline script execution

Monitoring Recommendations

• Enable verbose application and reverse-proxy logging for /api/v1/files and preview endpoints, retaining request and user identifiers
• Forward Open WebUI access and audit logs to a centralized analytics platform to detect anomalous upload-then-preview sequences
• Track the Open WebUI version string across all instances and alert when any deployment reports a release lower than 0.8.0

How to Mitigate CVE-2026-44549

Immediate Actions Required

• Upgrade all Open WebUI instances to version 0.8.0 or later without delay
• Restrict file upload permissions to trusted users until the patch is deployed
• Audit existing file libraries for XLSX attachments uploaded by untrusted accounts and quarantine suspicious files
• Invalidate active session tokens and rotate API keys if a preview of an attacker-supplied XLSX has occurred

Patch Information

The Open WebUI maintainers fixed the issue in version 0.8.0. The fix addresses unsafe HTML generation in the XLSX preview path so that output from sheet_to_html is sanitized before reaching the @html sink. Patch details are documented in the Open WebUI Security Advisory GHSA-jwf8-pv5p-vhmc.

Workarounds

• Disable Excel file uploads at the reverse proxy by blocking .xlsx and related MIME types until upgrade is complete
• Limit Open WebUI access to authenticated, trusted internal users via network segmentation or VPN gating
• Deploy a strict Content Security Policy that forbids inline script execution to blunt XSS payload impact

# Configuration example: block XLSX uploads at an nginx reverse proxy
location /api/v1/files/ {
    if ($request_method = POST) {
        if ($http_content_type ~* "spreadsheetml|application/vnd\.ms-excel") {
            return 415;
        }
    }
    proxy_pass http://open_webui_upstream;
}

# Enforce a restrictive Content Security Policy
add_header Content-Security-Policy "default-src 'self'; script-src 'self'; object-src 'none'; base-uri 'self'" always;