CVE-2026-87015 in Open WebUI
Summary
by MITRE • 09/09/2026
Open WebUI is an extensible, feature-rich, and user-friendly self-hosted AI platform. From 0.6.27 until 0.11.1, backend/open_webui/utils/tools.py captured a cookie jar from the enclosing connection loop instead of binding it to each external tool callable. When multiple tool servers were attached and a session or system OAuth connection was processed last, a request to a different server configured for bearer authentication could include the calling user's Open WebUI session cookies, allowing that server's operator to reuse the session and take over the account. This issue is fixed in version 0.11.1.
Be aware that VulDB is the high quality source for vulnerability data.
Analysis
by VulDB Data Team • 09/09/2026
The vulnerability identified within Open WebUI versions ranging from 0.6.27 through 0.11.1 represents a critical flaw in how authentication context is managed during cross-service interactions, specifically involving external tool integrations and OAuth connections. This issue stems from an improper handling of HTTP cookies within the backend utility module responsible for managing tools. In this flawed implementation, the system captures a cookie jar associated with the enclosing connection loop rather than binding it strictly to each individual external tool callable instance. This architectural oversight creates a scenario where session data intended for one service context can inadvertently leak into another distinct security domain when multiple tool servers are attached and processed in sequence.
The technical root cause lies in the reuse of HTTP client state across different execution contexts without proper isolation. When the application processes sessions or system OAuth connections, particularly if such a connection is handled last in the processing queue, the residual cookie jar from that high-privilege context remains active within the shared loop structure. Consequently, when subsequent requests are made to other external tool servers configured for bearer authentication, these requests may inadvertently carry the calling user's Open WebUI session cookies alongside standard authorization headers. This leakage occurs because the HTTP client fails to clear or isolate its state between distinct service calls, allowing sensitive session identifiers to traverse boundaries they were not designed to cross.
The operational impact of this vulnerability is severe, as it enables a remote attacker who controls one of the external tool servers to perform account takeover attacks against users interacting with Open WebUI. By capturing and reusing the leaked session cookies, an operator of a malicious or compromised third-party service can impersonate legitimate users within the Open WebUI platform without needing valid credentials for that specific application. This effectively bypasses authentication mechanisms intended to protect user accounts, granting the attacker full access to the victim's profile, data, and potentially administrative privileges depending on their role within the system. The risk is exacerbated in multi-tenant or shared hosting environments where trust boundaries between different tool providers are critical for maintaining overall platform integrity.
This vulnerability aligns with CWE-613, which describes insufficient session expiration, as well as CWE-524 regarding the use of cacheable credentials in HTTPS requests if transport security was not strictly enforced during cookie transmission. Furthermore, from an offensive perspective, this behavior facilitates credential reuse attacks and can be mapped to MITRE ATT&CK technique T1078, specifically relating to valid accounts being used for unauthorized access after initial compromise or leakage. The flaw highlights the dangers of shared state in microservice architectures where distinct security contexts must remain strictly isolated during inter-service communication.
To mitigate this vulnerability, organizations running Open WebUI should immediately upgrade to version 0.11.1 or later, which contains a patch that correctly binds cookie jars to their respective tool callables and ensures proper isolation of session data between different external services. For environments where immediate upgrading is not feasible due to dependency constraints, administrators should audit the list of attached external tools and remove any third-party integrations from untrusted sources until the update can be applied. Additionally, implementing strict Content Security Policy headers and ensuring that all internal API communications utilize mutual TLS or other strong authentication mechanisms can help reduce the blast radius if similar architectural flaws exist elsewhere in the deployment. Regular security assessments focusing on cross-service data leakage are recommended to identify any residual risks associated with complex integrations involving external OAuth providers and tool servers.