CVE-2026-109300: Open WebUI: stored XSS via tool-call embeds in Markdown
MEDIUMCISA: TRACK*Open WebUI versions 0.6.31 up to (but not including) 0.11.4 contain a stored cross-site scripting flaw: the Markdown renderer treats user-authored tool-call blocks as trusted tool output and loads their embeds attribute into script-enabled iframes. Any authenticated user can plant JavaScript in channel messages, chats, or citations that runs in the browser of anyone who views them, enabling in-app phishing and, where iframeSandboxAllowSameOrigin is enabled, session hijacking. Severity is medium (CVSS 4.6) and there is no CISA KEV listing, public exploit, or Nuclei template, and no EPSS score is available, so mass exploitation is not currently indicated. However, multi-user and shared-channel deployments carry elevated exposure, since a low-privileged insider or compromised account can target administrators. Upgrade to 0.11.4 or later, and until then disable iframeSandboxAllowSameOrigin and restrict who can post in shared channels.
What is the risk?
Medium overall. Exploitation is network-reachable, low complexity, and needs only a low-privileged authenticated account plus a victim viewing the content (UI:R). Confidentiality and integrity impact are rated low in the CVSS vector, but the practical risk rises sharply in multi-user deployments where admins view user-generated content, and where iframeSandboxAllowSameOrigin is enabled, because script then runs with the Open WebUI origin and can reach session tokens. No public exploit, scanner template, or KEV listing exists as of publication, and the package has 184 other CVEs, which points to a recurring flaw pattern in the project. Package risk score is 38/100 with 3 tracked downstream dependents, so blast radius through the supply chain is small, but direct deployments are common for self-hosted LLM front ends.
How does the attack unfold?
What systems are affected?
| Package | Ecosystem | Vulnerable Range | Patched |
|---|---|---|---|
| Open WebUI | pip | — | No patch |
Do you use Open WebUI? You're affected.
How severe is it?
What is the attack surface?
What should I do?
1 step1) Upgrade open-webui (pip) to 0.11.4 or later. 2) Until patched, disable iframeSandboxAllowSameOrigin in the Open WebUI settings so injected iframes cannot access the application origin. 3) Restrict channel posting and account creation, disable open signup, and review accounts with write access to shared channels. 4) Add or tighten a Content-Security-Policy (frame-src, script-src) at the reverse proxy. 5) Search stored chats, channel messages, and citation content for details blocks of type tool_calls containing an embeds attribute or unexpected iframe/script payloads. 6) Rotate API keys and invalidate sessions for any user who may have viewed suspicious content. 7) Track the vendor advisory GHSA-9wj4-mcm3-ppj6 for follow-up guidance.
What does CISA's SSVC say?
Source: CISA Vulnrichment (SSVC v2.0). Decision based on the CISA Coordinator decision tree.
How is it classified?
Which compliance frameworks are affected?
This CVE is relevant to:
Frequently Asked Questions
What is CVE-2026-109300?
Open WebUI versions 0.6.31 up to (but not including) 0.11.4 contain a stored cross-site scripting flaw: the Markdown renderer treats user-authored tool-call blocks as trusted tool output and loads their embeds attribute into script-enabled iframes. Any authenticated user can plant JavaScript in channel messages, chats, or citations that runs in the browser of anyone who views them, enabling in-app phishing and, where iframeSandboxAllowSameOrigin is enabled, session hijacking. Severity is medium (CVSS 4.6) and there is no CISA KEV listing, public exploit, or Nuclei template, and no EPSS score is available, so mass exploitation is not currently indicated. However, multi-user and shared-channel deployments carry elevated exposure, since a low-privileged insider or compromised account can target administrators. Upgrade to 0.11.4 or later, and until then disable iframeSandboxAllowSameOrigin and restrict who can post in shared channels.
Is CVE-2026-109300 actively exploited?
No confirmed active exploitation of CVE-2026-109300 has been reported, but organizations should still patch proactively.
How to fix CVE-2026-109300?
1) Upgrade open-webui (pip) to 0.11.4 or later. 2) Until patched, disable iframeSandboxAllowSameOrigin in the Open WebUI settings so injected iframes cannot access the application origin. 3) Restrict channel posting and account creation, disable open signup, and review accounts with write access to shared channels. 4) Add or tighten a Content-Security-Policy (frame-src, script-src) at the reverse proxy. 5) Search stored chats, channel messages, and citation content for details blocks of type tool_calls containing an embeds attribute or unexpected iframe/script payloads. 6) Rotate API keys and invalidate sessions for any user who may have viewed suspicious content. 7) Track the vendor advisory GHSA-9wj4-mcm3-ppj6 for follow-up guidance.
What systems are affected by CVE-2026-109300?
This vulnerability affects the following AI/ML architecture patterns: LLM chat front ends, Self-hosted LLM gateways, RAG pipelines, Multi-user AI collaboration platforms.
What is the CVSS score for CVE-2026-109300?
CVE-2026-109300 has a CVSS v3.1 base score of 4.6 (MEDIUM). The EPSS exploitation probability is 0.21%.
What is the AI security impact?
Affected AI Architectures
MITRE ATLAS Techniques
AML.T0011.003Malicious LinkAML.T0049Exploit Public-Facing ApplicationAML.T0052PhishingAML.T0091.000Application Access TokenCompliance Controls Affected
What are the technical details?
Original Advisory
Open WebUI from 0.6.31 before 0.11.4 contains a stored cross-site scripting vulnerability in its Markdown renderer, which treats user-authored tool-call details blocks as tool output and mounts their embeds attribute in script-enabled iframes. Authenticated users can post crafted channel messages, chat messages, or citation content that runs JavaScript in viewers' browsers, enabling in-app phishing, or session hijacking where iframeSandboxAllowSameOrigin is enabled.
Exploitation Scenario
An attacker with a low-privilege account on a shared Open WebUI instance posts a channel message containing a crafted tool-call details block whose embeds attribute points to attacker-controlled HTML with JavaScript. When an administrator or colleague opens the channel, the renderer mounts the embed in a script-enabled iframe and the code runs. It displays a fake re-authentication prompt to harvest credentials. If iframeSandboxAllowSameOrigin is enabled, the script instead reads the victim's session token and API keys and uses them to access private chats, uploaded knowledge bases, and connected model backends.
Weaknesses (CWE)
CWE-79 — Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting'): The product does not neutralize or incorrectly neutralizes user-controllable input before it is placed in output that is used as a web page that is served to other users.
- [Architecture and Design] Use a vetted library or framework that does not allow this weakness to occur or provides constructs that make this weakness easier to avoid [REF-1482]. Examples of libraries and frameworks that make it easier to generate properly encoded output include Microsoft's Anti-XSS library, the OWASP ESAPI Encoding module, and Apache Wicket.
- [Implementation, Architecture and Design] Understand the context in which your data will be used and the encoding that will be expected. This is especially important when transmitting data between different components, or when generating outputs that can contain multiple encodings at the same time, such as web pages or multi-part mail messages. Study all expected communication protocols and data representations to determine the required encoding strategies. For any data that will be output to another web page, especially any data that was received from external inputs, use the appropriate encoding on all non-alphanumeric characters. Parts of the same output document may require different encodings, which will vary depending on whether the output is in the: etc. Note that HTML Entity Encoding is only appropriate for the HTML body. Consult the XSS Prevention Cheat Sheet [REF-724] for more details on the types of encoding and escaping that are needed. HTML body Element attributes (such as src="XYZ") URIs JavaScript sections Casca
Source: MITRE CWE corpus.
CVSS Vector
CVSS:3.1/AV:N/AC:L/PR:L/UI:R/S:U/C:L/I:L/A:NReferences
Timeline
Related Vulnerabilities
CVE-2026-445519.1open-webui: LDAP auth bypass — full account takeover
Same package: open-webuiCVE-2026-456728.8open-webui: code exec gate bypass via API endpoint
Same package: open-webuiCVE-2025-644958.7Open WebUI: XSS-to-RCE via malicious prompt injection
Same package: open-webuiCVE-2026-445528.7open-webui: Redis cache poisoning enables cross-instance tool hijack
Same package: open-webuiCVE-2026-453158.7open-webui: stored XSS → JWT theft and admin takeover
Same package: open-webui