AI Threat Alert
Open WebUI, a widely self-hosted interface for LLM chat, lets any authenticated user manually edit their own chat history via an intercepted save request to inject an html:true flag into a document citation's metadata, which causes the frontend to render that document inside a sandboxed iframe using allow-scripts and allow-same-origin — sandbox flags that provide essentially no isolation — and execute arbitrary JavaScript. Because the poisoned chat can be shared, the payload also fires against any other user who opens the link, including administrators, letting an attacker steal session tokens from local storage or, per the companion advisory GHSA-w7xj-8fx7-wfch, escalate to full server RCE if the victim is an admin. The CVSS 7.3 score and required user interaction (a victim must expand sources and click the specific document) keep EPSS low at 0.19%, and there is no public exploit code, Nuclei template, or CISA KEV listing yet, but open-webui already carries 113 other CVEs and a package risk score of 38/100, underscoring a pattern of security debt in a tool many teams expose as their primary LLM/RAG front-end. Teams running open-webui below 0.7.0 should patch immediately and, until patched, disable or restrict the shared-chat feature and closely monitor admin session activity, since the admin-to-RCE path is the highest-consequence outcome. Detection should focus on chat history records containing unexpected html metadata flags on document/citation objects, which is a reliable indicator of exploitation attempts.
What is the risk?
Rated high (CVSS 7.3) rather than critical because exploitation requires an authenticated (even low-privilege) attacker and mandatory victim interaction (expanding sources and clicking the poisoned document). However, real-world risk is elevated by three factors: the sandbox attributes advertised as a mitigation (allow-scripts + allow-same-origin) are misconfigured and provide no meaningful containment; the payload propagates through the shared-chat feature, turning any single compromised or malicious account into a distribution vector against other users and admins; and a documented chain to full RCE exists for admin victims via GHSA-w7xj-8fx7-wfch. EPSS (0.19%, though flagged in the top 91st percentile for likelihood) and absence from CISA KEV suggest no current mass exploitation, and no public PoC or Nuclei template exists yet — but the low barrier to crafting the payload (a Burp/Caido intercept and a JSON edit) means a working exploit could appear quickly. The package's history of 113 other CVEs and a 38/100 risk score indicate open-webui deployments should be treated as higher-scrutiny AI infrastructure.
How does the attack unfold?
What systems are affected?
| Package | Ecosystem | Vulnerable Range | Patched |
|---|---|---|---|
| Open WebUI | pip | < 0.7.0 | 0.7.0 |
Do you use Open WebUI? You're affected.
How severe is it?
What is the attack surface?
What should I do?
1 step-
1) Upgrade open-webui to version 0.7.0 or later, where this issue is patched. 2) Until patched, disable or heavily restrict the 'share chat' feature, since propagation to other users depends on it. 3) Review the CitationModal iframe sandbox configuration and remove allow-same-origin from any custom builds. 4) Audit stored chat history for document metadata containing an unexpected 'html' key/flag, and quarantine any chats found with it. 5) Rotate session tokens and review admin account activity logs for anomalous behavior following any suspected exposure, since local-storage token theft is the primary near-term impact. 6) Treat this in the context of GHSA-w7xj-8fx7-wfch — if that RCE chain applies to your version, prioritize remediation for admin accounts first.
How is it classified?
Which compliance frameworks are affected?
This CVE is relevant to:
Frequently Asked Questions
What is CVE-2026-26192?
Open WebUI, a widely self-hosted interface for LLM chat, lets any authenticated user manually edit their own chat history via an intercepted save request to inject an html:true flag into a document citation's metadata, which causes the frontend to render that document inside a sandboxed iframe using allow-scripts and allow-same-origin — sandbox flags that provide essentially no isolation — and execute arbitrary JavaScript. Because the poisoned chat can be shared, the payload also fires against any other user who opens the link, including administrators, letting an attacker steal session tokens from local storage or, per the companion advisory GHSA-w7xj-8fx7-wfch, escalate to full server RCE if the victim is an admin. The CVSS 7.3 score and required user interaction (a victim must expand sources and click the specific document) keep EPSS low at 0.19%, and there is no public exploit code, Nuclei template, or CISA KEV listing yet, but open-webui already carries 113 other CVEs and a package risk score of 38/100, underscoring a pattern of security debt in a tool many teams expose as their primary LLM/RAG front-end. Teams running open-webui below 0.7.0 should patch immediately and, until patched, disable or restrict the shared-chat feature and closely monitor admin session activity, since the admin-to-RCE path is the highest-consequence outcome. Detection should focus on chat history records containing unexpected html metadata flags on document/citation objects, which is a reliable indicator of exploitation attempts.
Is CVE-2026-26192 actively exploited?
No confirmed active exploitation of CVE-2026-26192 has been reported, but organizations should still patch proactively.
How to fix CVE-2026-26192?
1) Upgrade open-webui to version 0.7.0 or later, where this issue is patched. 2) Until patched, disable or heavily restrict the 'share chat' feature, since propagation to other users depends on it. 3) Review the CitationModal iframe sandbox configuration and remove allow-same-origin from any custom builds. 4) Audit stored chat history for document metadata containing an unexpected 'html' key/flag, and quarantine any chats found with it. 5) Rotate session tokens and review admin account activity logs for anomalous behavior following any suspected exposure, since local-storage token theft is the primary near-term impact. 6) Treat this in the context of GHSA-w7xj-8fx7-wfch — if that RCE chain applies to your version, prioritize remediation for admin accounts first.
What systems are affected by CVE-2026-26192?
This vulnerability affects the following AI/ML architecture patterns: RAG pipelines (document citation/preview), LLM chat front-ends / ml_ui, shared/collaborative chat features.
What is the CVSS score for CVE-2026-26192?
CVE-2026-26192 has a CVSS v3.1 base score of 7.3 (HIGH). The EPSS exploitation probability is 0.19%.
What is the AI security impact?
Affected AI Architectures
MITRE ATLAS Techniques
AML.T0011 User Execution AML.T0049 Exploit Public-Facing Application AML.T0067.000 Citations AML.T0092 Manipulate User LLM Chat History Compliance Controls Affected
What are the technical details?
Original Advisory
### Summary Manually modifying chat history allows setting the `html` property within document metadata. This causes the frontend to enter a code path that treats document contents as HTML, and render them in an iFrame when the citation is previewed. This allows stored XSS via a weaponised document payload in a chat. The payload also executes when the citation is viewed on a shared chat. ### Details The vulnerability stems from how iFrame are implemented here: https://github.com/open-webui/open-webui/blob/6f1486ffd0cb288d0e21f41845361924e0d742b3/src/lib/components/chat/Messages/Citations/CitationModal.svelte#L163-L170 The `html` attribute can be controlled by a user who manually edits the chat history. Since `allow-scripts` and `allow-same-origin` are harcoded here the sandboxing offers essentially no protection. ### PoC Create an arbitrary chat with a file upload attached: <img width="2462" height="1148" alt="image" src="https://github.com/user-attachments/assets/fad83c74-036d-41b8-bc44-87bf2a538b21" /> Edit the response <img width="768" height="206" alt="image" src="https://github.com/user-attachments/assets/41a7342a-cc41-433e-8820-0bc6ed08ddd7" /> <img width="2142" height="796" alt="image" src="https://github.com/user-attachments/assets/fb731111-e082-4172-80d1-34cff6b2a511" /> Before saving, configure the browser to use an HTTP proxy tool (Burp/Caido/ZAP) and intercept the save request. Find the object within the `history` and then `messages` objects (not the `messages` array) that contains the document source. <img width="2122" height="1388" alt="image" src="https://github.com/user-attachments/assets/1b4fbced-a6de-414d-b063-9cae44e3f449" /> Add `html: true` to metadata, update the document to an XSS payload, and forward the request. <img width="2240" height="1358" alt="image" src="https://github.com/user-attachments/assets/fd27971b-f707-458f-a14d-254f9f3ad1fa" /> Observe the payload is rendered in the iFrame and the javascript executes. <img width="2698" height="1696" alt="image" src="https://github.com/user-attachments/assets/b4e31cb4-d4cc-41a9-be42-802e9b1a798d" /> The payload also executes when viewed from a shared version of the chat. <img width="2742" height="1258" alt="image" src="https://github.com/user-attachments/assets/92ee501d-8f14-4c32-8f3c-f4d3ca304ee5" /> ### Impact Any user can create a weaponised chat that can be shared and subsequently used to target other users. Low privilege users are at risk of having their session taken over by a payload that reads their token from local storage and exfiltrates it to an attacker controlled server. Admins are at risk of exposing the server to RCE via same chain described in https://github.com/advisories/GHSA-w7xj-8fx7-wfch. ### Caveats The victim must expand the sources and click the document containing the payload to trigger this issue.
Exploitation Scenario
A low-privilege but authenticated open-webui user starts a chat and uploads a file, generating a document citation. Before saving the edited response, the attacker configures an HTTP intercepting proxy (Burp/Caido/ZAP), locates the message object holding the document source inside the chat history payload, and adds html: true to its metadata along with an XSS payload as the document's contents, then forwards the modified save request. The attacker then shares the weaponized chat link with a target — a teammate or, ideally, an administrator. When the victim opens the shared chat, expands the sources panel, and clicks the poisoned document, the frontend renders it inside an iframe with allow-scripts and allow-same-origin, executing the attacker's JavaScript in the victim's authenticated session. The script reads the victim's session token from local storage and exfiltrates it to an attacker-controlled server, giving the attacker session takeover; if the victim is an administrator, the same execution primitive can be chained per GHSA-w7xj-8fx7-wfch to achieve remote code execution on the server.
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:H/I:H/A:N 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-2025-64495 8.7 Open WebUI: XSS-to-RCE via malicious prompt injection
Same package: open-webui CVE-2026-44552 8.7 open-webui: Redis cache poisoning enables cross-instance tool hijack
Same package: open-webui CVE-2026-45315 8.7 open-webui: stored XSS → JWT theft and admin takeover
Same package: open-webui