“Open WebUI stores the JWT token in localStorage,” Cato researchers said in a blog post. “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.”
The attack requires the victim to enable Direct Connections (disabled by default) and add the attacker’s malicious model URL, according to an NVD description.
Escalating to Remote Code Execution
The risk doesn’t stop at account takeover. If the compromised account has workspace.tools permissions, attackers can leverage that session token to push authenticated Python code through Open WebUI’s Tools API, which executes without sandboxing or validation.
This turns a browser-level compromise into full remote code execution on the backend server. Once an attacker gets Python execution, they can install persistence mechanisms, pivot into internal networks, access sensitive data stores, or run lateral attacks.
The flaw received a high severity rating at 8/10 base score by NVD, and a 7.3/10 base score by GitHub. The flaw was rated high rather than critical, reflecting the fact that exploitation requires the Direct Connections feature to be enabled and hinges on a user first being lured into connecting to a malicious external model server. Patch mitigation in Open WebUI v0.6.35 involves blocking “execute” SSE events from Direct Connections entirely, but any organization still on older builds remains exposed. Additionally, the researchers advised moving authentication to short-lived and HttpOnly cookies with rotation. “Pair with a strict CSP and ban dynamic code evaluation”, they added.