Cato CTRL™ Threat Research: Vulnerability Discovered in Open WebUI Enables Account Takeover and Remote Code Execution (CVE-2025-64496)

Executive Summary

Cato CTRL’s Vitaly Simonovich (senior security researcher) has discovered a vulnerability (CVE-2025-64496 with a “High” severity rating of 7.3 out of 10) in Open WebUI in versions 0.6.34 and older. This flaw affects the Direct Connections feature, which lets users connect to external AI model servers (ex: OpenAI’s API).

If a threat actor tricks a user into connecting to a malicious server, it can lead to an account takeover attack. If the user also has workspace.tools permission enabled, it can lead to remote code execution (RCE). Which means that a threat actor can control the system running Open WebUI.

2025 Cato CTRL Threat Report | Download the report

• Impact
  • Account Takeover:
    • JavaScript code execution in the victim’s browser session.
    • JSON web token (JWT) theft from localStorage.
    • Full account compromise (access to all chats, documents, and API keys).
    • Data exfiltration of chat history, uploaded documents, and sensitive conversations.
  • RCE:
    • If the compromised account belongs to a user with workspace.tools permission, the threat actor can use the stolen token to execute arbitrary Python code on the backend server through unsandboxed Tools APIs, resulting in complete server compromise.
• Scope
  • Impacted: Open WebUI v0.6.34 and older when Direct Connections are enabled for users
  • Patched: Open WebUI v0.6.35 and newer (middleware blocks execute events from Direct Connections)
  • Vector: Malicious SSE execute event → JavaScript runs via new Function() → token exfiltration → optional RCE via Tools API
  • Risk:
    • All users: Loss of chat history, uploaded documents, and API keys/SSO tokens.
    • Users with workspace.tools permission: Backend server compromise and RCE.
• Cato Protections
  • Cato detects and blocks exploitation behaviors and abnormal JavaScript/token exfiltration patterns of the CVE with ATP, IPS, and ZTNA protections within the Cato SASE Cloud Platform. Cato MDR can also triage for customers.

Timeline & Disclosure:

• October 8, 2025: Issue discovered and reported to maintainers of Open WebUI.
• October 10, 2025: Initial triage and CVSS discussion.
• October 19, 2025: First patch attempt (incomplete).
• November 3, 2025: Patch verification and additional tests.
• November 5, 2025: Admin-token exploitability confirmed; final validation of patch.
• November 7, 2025: Public disclosure from Open WebUI and CVE assigned (CVE-2025-64496) by GitHub.

Technical Overview

How We Got Here: Self-Hosted AI Meets Untrusted “Model Servers”

Organizations adopt Open WebUI to keep sensitive AI workflows on-premises. The Direct Connections feature allows users to connect to “any OpenAI-compatible API,” such as local model servers, lab endpoints, or alternative providers. The security assumption was that responses are inert text. Reality: A hostile server can stream executable events.

Explosive Growth and Enterprise Adoption

The numbers tell a compelling story. At time of writing, Open WebUI’s adoption curve has been nothing short of meteoric:

• 115,000+ GitHub stars (up from ~20,000 in early 2024)
• 16,000+ forks: Signaling massive developer engagement
• Proven at scale: Deployments serving tens or even hundreds of thousands of seats worldwide
• Trusted by: Major organizations globally

In under two years, Open WebUI evolved from a niche project to one of the most popular open-source AI platforms on GitHub. Its privacy-first, vendor-neutral model appeals to organizations that demand AI autonomy and data sovereignty.

When a platform of this size becomes vulnerable, the impact isn’t just theoretical. It affects production environments managing research data, internal codebases, and regulated information.

Impact Analysis: What Can Threat Actors Actually Do?

Every attack follows the same initial path. What happens next depends on the victim’s permissions.

Scenario 1 (Account Takeover): Regular User Victim

A user added what seemed to be a local Llama model endpoint shared by a colleague on Slack. After sending a simple test prompt (“Summarize my latest project notes”), the JWT was silently exfiltrated to a threat actor-controlled server within five seconds.

Attack Steps:

1. User adds a malicious Direct Connection URL
2. User sends any message to the malicious “model”
3. Malicious server responds with SSE execute event
4. Vulnerability #1 (Frontend Code Injection) triggers:
   • JavaScript executes in the browser via new Function()
   • Code reads localStorage.token
   • Token sent to threat actor’s server
5. Result: Account Takeover

What the threat actor has now:

• Full access to six months of chat history
• Database connection strings pasted in chats
• Internal API keys and credentials
• All uploaded documents and files
• Ability to impersonate the victim indefinitely

Server Status: Open WebUI server remains secure because the threat actor has no way to execute code on the backend, as the user had no elevated permissions.

Scenario 2 (RCE): Server Compromise (Only If User Has workspace.tools Permission Enabled)

A data analyst discovered a “free GPT-4 alternative” shared in a professional AI community and incorporated it to evaluate test response quality. After sending one test message, their authentication token was stolen. The threat actor realized the analyst had been granted extended tool creation permissions for legitimate data processing workflows.

Attack steps continue:

1. Threat actor validates stolen token via API
2. Threat actor discovers workspace.tools permission
3. Vulnerability #2 (Tools API RCE) exploited:
   • Threat actor uses stolen token to create malicious Tool
   • Backend executes arbitrary Python via exec()
   • No sandboxing or validation
4. Result: Remote Code Execution

What the threat actor has now:

• Everything from Stage 1, PLUS:
• Backend code execution on the server
• Access to the entire chat database
• Ability to pivot to the internal network
• Persistence mechanisms
• Full server compromise

Vulnerability #1: Frontend Code Injection (CVE Scope)

Component: src/lib/components/chat/Chat.svelte

Issue: The SSE handler trusts an event.type === “execute” and evaluates data.code with new Function() – effectively eval in the page’s full origin context. No allowlist, no gating, and no content security policy (CSP) hardening.

Impact:

• Arbitrary JS runs in the victim’s session
• JWT tokens stored in localStorage are trivially exfiltrated
• Threat actor takes over the account and exfiltrates sensitive data

Why it’s exploitable by “low-privilege” users: Regular users can add Direct Connections when the admin enables the feature flag—no admin token is required to trigger the bug once it’s enabled.

Token Handling Weakness – Why localStorage Causes Issues

Open WebUI stores the JWT token in localStorage. Any script running on the page can access it. Tokens are long-lived by default, lack HttpOnly, and are cross-tab. When combined with the execute event, this creates a window for account takeover.

Best practice: Move auth to short-lived and HttpOnly cookies with rotation; pair with a strict CSP and ban dynamic code evaluation.

Vulnerability #2: Backend RCE via Tools API (Conditional Impact)

Component: POST /api/v1/tools/create (requires workspace.tools permission)

Issue: The Tools API executes untrusted Python code via exec() without sandboxing or validation, thereby granting attackers full access to execute system commands (via’ subprocess’), read/write files, establish network connections, and perform any operation available to the application process.

Impact (When a user with workspace.tools permission is compromised):

• The stolen token can be used to create malicious Tools
• This leads to immediate backend code execution
• Full server compromise becomes possible. Both APIs execute untrusted Python code via exec() without sandboxing or validation, granting threat actors full access to execute system commands (subprocess), read/write files, establish network connections, and perform any operation available to the application process.

Conclusion

This is a typical trust boundary failure between untrusted model servers and a trusted browser context. In Open WebUI v0.6.34 or older versions, a single SSE frame could breach that boundary, steal tokens quickly, and (if the victim had the right settings) pivot to backend RCE. Open WebUI’s patch is effective for v0.6.35 or newer versions, which closes the user-facing Direct Connections vulnerability. However, organizations still need to strengthen authentication, sandbox extensibility, and restrict access to specific resources.

Protections

Treat “OpenAI-compatible” endpoints like third-party code. If you didn’t build it and don’t control it, it’s untrusted. Patch, limit your Direct Connections, and closely monitor tool and function creation logs.

For Open WebUI users:

• Update Open WebUI to the latest version (v0.6.35 or newer).
• Don’t add LLM models that you don’t trust.
• Review workspace.tools permission grants. Only assign to essential users.
• Monitor for suspicious Tool creation activity.
• Implement token rotation policies.

For Cato customers:

• Cato detects and blocks exploitation behaviors and abnormal JavaScript/token exfiltration patterns of the CVE with IPS, ATP and ZTNA protections within the Cato SASE Cloud Platform. Cato MDR can also triage for customers.

The post Cato CTRL™ Threat Research: Vulnerability Discovered in Open WebUI Enables Account Takeover and Remote Code Execution (CVE-2025-64496) appeared first on Cato Networks.