Open WebUI Vulnerability Review: One iframe Setting Was Enough for Account Takeover
Open WebUI has more than 155,000 GitHub stars, which makes CVE-2026-87995 especially fun to examine from a software design perspective. The vulnerability was not buried inside some exotic cryptographic routine or obscure memory allocator. It lived in an iframe sandbox used by the terminal port preview and came down to a combination of browser permissions that looked restrictive while quietly removing the restriction that actually counted. Open WebUI versions 0.8.11 through 0.11.0 were affected, and version 0.11.1 corrected the problem.
The result could be full account takeover under a specific but realistic configuration. An ordinary authenticated user with access to a shared terminal server could cause content from that server to appear inside another user's Open WebUI port preview. If the victim opened the preview, script inside it could execute with Open WebUI's own origin rather than being trapped inside an isolated origin. At that point the browser was no longer treating the preview as foreign content in the way the interface appeared to suggest.
The Beautifully Bad Part Is Two iframe Permissions
Browsers provide iframe sandboxing so an application can display untrusted web content without giving that content normal access to the surrounding application. Open WebUI's terminal preview used a sandbox that permitted scripts, which makes sense because a developer may genuinely want to preview a web application running inside a terminal. The same sandbox also permitted the preview to retain its original origin. Those two decisions became dangerous together because the terminal proxy itself was mounted underneath the Open WebUI origin.
This is the browser security equivalent of installing an excellent lock and then leaving the door attached to the wrong wall. allow-scripts meant the preview could execute JavaScript, while allow-same-origin meant the browser did not force that preview into the opaque origin normally created by a sandbox. Since Open WebUI was proxying the preview through its own origin, the browser saw the previewed application and Open WebUI as belonging to the same security origin. The sandbox remained visibly present in the markup, but the most useful boundary had effectively evaporated.
The Preview Was Supposed to Be the Containment Layer
Open WebUI's terminal feature can expose applications started from a connected terminal server and display them inside the interface. That is genuinely useful when an AI agent or developer starts a local web server and wants to inspect the result without leaving Open WebUI. The preview is also exactly where untrusted content enters the application, which makes its browser isolation unusually consequential. A mistake in an ordinary layout iframe might damage a page, while a mistake here crosses a trust boundary between code running in the terminal and the authenticated Open WebUI session.
The affected component was the terminal port preview reached through the file navigator. Other iframe based previews in Open WebUI had already moved toward an opt in model for same origin access, but this particular component still contained the permission directly in its sandbox configuration. That inconsistency is what makes the bug so satisfying to study. The application had already developed the safer pattern elsewhere, yet one older hardcoded permission survived in precisely the component where hostile content had the clearest route into the browser.
The Session Token Was Sitting on the Other Side of the Boundary
Once previewed content received the Open WebUI origin, browser security rules no longer prevented it from interacting with resources belonging to that origin. The advisory identifies the user's session token in local storage as the critical target. A malicious preview could therefore act with the victim's authenticated session rather than remaining a harmless miniature website inside a frame. The practical consequence was account takeover, not merely the ability to change how the preview looked.
The severity increases when the compromised account has elevated Open WebUI privileges. Taking over an administrator account obviously gives the attacker the capabilities available to that administrator, while accounts holding the relevant workspace Functions privilege can expose server side execution through Open WebUI's function system. That escalation is downstream from the browser bug rather than a separate vulnerability. One confused origin boundary can therefore connect a small frontend mistake to privileges living much deeper in the application.
This Was Not an Internet Wide Open WebUI Takeover
The vulnerability had meaningful prerequisites, and ignoring them would turn a good bug into security theater. Open WebUI needed to have a terminal server configured, which is not the default configuration, and both attacker and victim needed access to that shared terminal connection. The attacker needed an authenticated account rather than arbitrary anonymous internet access. The victim also needed to open the port preview containing the hostile content.
Personal terminal connections using an external URL were not affected in the same way because their content remained cross origin. Deployments without a configured terminal server were not affected either. Operators who had independently deployed a restrictive Content Security Policy could also have blocked the relevant script behavior before the official fix. CVE-2026-87995 is serious because the trust boundary fails cleanly under its prerequisites, not because every Open WebUI server on the internet was automatically compromised.
The Fix Is Almost Comically Small Compared With the Impact
Open WebUI 0.11.1 changed the terminal preview so same origin access is no longer granted automatically. The permission is now controlled by a user setting called Terminal Preview Allow Same Origin and is disabled by default. Without that permission, the browser assigns the preview an opaque origin, which means script can still execute inside the preview while losing the authority to reach into Open WebUI itself. The application can therefore continue displaying interactive terminal applications without giving them the authenticated application's identity.
This is one of those fixes that makes security engineering look suspiciously easy after someone has already done the hard reasoning. The vulnerable behavior was not corrected by introducing an enormous validation system or rewriting the terminal architecture. The fix restores the browser boundary that the sandbox was supposed to provide in the first place. A few characters of policy can represent an enormous amount of authority when those characters sit inside an iframe sandbox attribute.
The Bug Also Shows Why Browser Sandboxes Are Easy to Misread
An iframe marked as sandboxed sounds inherently contained, but sandbox permissions are additive exceptions to that containment. Developers therefore have to reason about the interaction among permissions rather than checking whether the sandbox attribute exists. Allowing scripts can be perfectly reasonable, and allowing same origin behavior can also be reasonable in a controlled environment. Allowing both becomes a very different security decision when the embedded content is delivered through the application's own origin.
The broader lesson is not that allow-same-origin should never exist. Some applications genuinely depend on origin scoped browser features such as cookies, storage, or same origin requests. The lesson is that the permission changes the meaning of the iframe from isolated content into content participating in the application's trust domain. Open WebUI's current interface reflects that reality by making the behavior an explicit user choice rather than quietly enabling it for every terminal preview.
Open WebUI Had Already Solved This Problem Somewhere Else
The most revealing detail in the advisory is that other embedded previews had already been moved to an opt in same origin setting. The terminal port preview simply retained its older static configuration and was missed when equivalent preview behavior was hardened. Security failures often look less like someone failing to understand a concept and more like one implementation drifting away from the rule the rest of the application already follows. This bug is a compact example of that pattern.
Large applications accumulate duplicate implementations of the same conceptual boundary. One iframe is created for files, another for artifacts, another for terminal ports, and eventually one receives a security fix that does not propagate to its cousins. Open WebUI now has more than 155,000 GitHub stars and a rapidly growing feature set, so maintaining consistency across those boundaries becomes increasingly difficult. The vulnerability is therefore interesting not only as XSS, but as evidence of how security invariants decay when the same rule is encoded separately in multiple components.
Is Open WebUI Safe After CVE-2026-87995?
CVE-2026-87995 was fixed in Open WebUI 0.11.1. Users running 0.8.11 through 0.11.0 should update rather than attempting to work around the problem manually. No special migration is required for the fix, and the safer terminal preview behavior becomes the default after upgrading. Users who deliberately enable Terminal Preview Allow Same Origin should understand that they are restoring the trust relationship that the patch removed.
The bug does not make Open WebUI inherently unsafe, and the project disclosed a clear set of prerequisites, affected versions, and remediation behavior. What makes this vulnerability worth studying is how elegantly the failure connects browser policy to application privilege. One iframe looked sandboxed, one permission kept the original origin alive, and suddenly terminal content could stand inside Open WebUI wearing Open WebUI's own security badge. That is the sort of tiny architectural mistake that makes vulnerability research addictive.
Update Open WebUI
CVE-2026-87995 is fixed in Open WebUI 0.11.1 and later releases. Users on affected versions should upgrade through the installation method already used for their deployment.
Comments