Today, we’re joined by Dominic Jainy, an IT professional whose work sits at the intersection of AI and security. He’s here to break down a high-severity vulnerability in Open WebUI, a popular enterprise AI interface. We’ll explore how a feature designed for convenience became a backdoor, allowing attackers to hijack AI workloads, steal sensitive data, and even execute code directly on company servers.
The report on CVE-2025-64496 describes a social engineering pretext like a “free GPT-4 alternative.” Can you walk us through the technical attack chain, from a user connecting to a malicious server to how server-sent events (SSE) are exploited to inject code?
It’s a classic case of exploiting user trust. The attack begins with social engineering, like an offer for a “free GPT-4 alternative.” An employee enables the Direct Connections feature—which is disabled by default—and connects to the attacker’s malicious server. Once that connection is made, the attacker’s server streams server-sent events (SSE) back to the Open WebUI frontend. The platform’s SSE handler has a critical flaw: it implicitly trusts these incoming events, especially one type tagged as “execute,” and runs its payload. The attacker sends malicious JavaScript, and the system executes it right in the user’s browser.
The injected code targets JSON Web Tokens in localStorage. Given these tokens are long-lived and lack HttpOnly protection, could you elaborate on how this specific oversight allows for persistent account takeover and grants access to a user’s chats, documents, and API keys?
This is where the poor session management becomes so damaging. Open WebUI stores the user’s JSON Web Token in the browser’s localStorage, making it accessible to any script on the page. These tokens are long-lived by default and crucially lack the HttpOnly flag, which would have prevented scripts from reading them. It’s a perfect storm for theft. Because the token is also valid across browser tabs, once an attacker has it, they have persistent access. They can effectively become the user, gaining control over their AI workspace, reading private chats and documents, and stealing any API keys stored within that environment.
This vulnerability can escalate from browser-level access to full remote code execution. What is the role of the workspace.tools permission in this escalation, and how does an attacker use a stolen session token to execute unsandboxed Python code on the backend server?
The nightmare escalates from there. If the compromised account has the workspace.tools permission, the attacker can pivot from the browser to a full server compromise. Using the stolen session token for authentication, they send malicious Python code to Open WebUI’s Tools API. The most frightening part is that this code is executed without any sandboxing or validation. It runs with full privileges on the backend server. At that point, an attacker can install persistence mechanisms, pivot into internal networks, or launch lateral attacks. This is why the flaw received a high severity score of 8/10 from NVD; it turns a user’s click into a potential enterprise breach.
The patch in v0.6.35 blocks “execute” SSE events from Direct Connections. Beyond patching, researchers recommend moving to HttpOnly cookies and using a strict CSP. How crucial are these additional architectural changes for preventing similar injection attacks in the future?
The immediate patch in v0.6.35 is a necessary first step; it blocks those dangerous “execute” SSE events from Direct Connections. But relying on this patch alone is shortsighted. The researchers’ additional recommendations are crucial for a resilient architecture. Moving authentication tokens into HttpOnly cookies is fundamental—it would have stopped this token theft. Making tokens short-lived with rotation policies further limits an attacker’s window of opportunity. Finally, a strict Content Security Policy (CSP) that bans dynamic code evaluation provides another powerful layer of defense against future injection attacks. It’s about moving from a reactive patch to a proactive, secure-by-design posture.
Do you have any advice for our readers?
My advice is to treat convenience with a healthy dose of skepticism, especially in enterprise environments. Features like Direct Connections expand the attack surface, and it’s vital to educate users on social engineering—a “free” tool is rarely ever free. From a technical standpoint, this is a stark reminder to practice defense-in-depth. Don’t rely on defaults. Enforce the principle of least privilege, use robust session management with HttpOnly cookies, and implement a strict CSP. A single layer of security is never enough, especially as AI becomes more integrated into business operations.