Description

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.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "6.8",
  "pubDate": "2026-09-09T21:17:06.463Z",
  "pubdate": "2026-09-09T21:17:06.463Z",
  "executiveSummary": "This vulnerability profile details a critical session leakage flaw in Open WebUI, an extensible, self-hosted AI platform, affecting versions from 0.6.27 up to 0.11.0. The vulnerability stems from improper state management within the backend routing utility, specifically located in backend/open_webui/utils/tools.py. Due to a failure to properly isolate connection contexts, the application erroneously shares a single cookie jar reference across multiple external tool server calls instead of binding distinct cookie jars to each callable.\nThe primary risk associated with this vulnerability is unauthorized account takeover. When an affected Open WebUI instance is configured with multiple tool servers, and a session or system OAuth connection is processed last in the connection loop, subsequent requests to other servers will inherit the active session cookies. If a target external tool server is configured for bearer authentication, the user's highly sensitive session cookies are transmitted directly to it. This allows any malicious or compromised tool server operator to capture the active session identifiers, replay them against the Open WebUI platform, and completely compromise the affected user's account without requiring valid credentials. This issue is fixed in version 0.11.1.",
  "technicalDetails": "The root cause of this vulnerability lies in the scope resolution and variable binding behavior within backend/open_webui/utils/tools.py. Specifically, the implementation captured a cookie jar reference from an enclosing connection loop instead of explicitly binding a distinct, isolated cookie jar instance to each individual external tool callable. In Python, when a closure binds to a loop variable, it references the variable's final state in the loop rather than its value at the time the closure was defined, unless default argument binding or explicit context separation is used.\nBecause of this shared scope, when multiple tool servers were attached to the Open WebUI instance, the state of the cookie jar persisted across iterations. If a session or system OAuth connection was processed last in the execution loop, the active connection context—including the sensitive session cookies of the calling user—remained bound to the shared cookie jar reference. Subsequently, when a request was dispatched to a different, unrelated external tool server configured for bearer authentication, the backend utilized the contaminated cookie jar. As a result, the outgoing HTTP request transmitted to this secondary tool server included the calling user's private Open WebUI session cookies alongside or instead of the expected authorization headers.\nThe vulnerability is characterized as an information exposure through shared state across security boundaries. During normal operations, Open WebUI allows administrators to configure multiple external tool servers to extend the platform's capabilities. Each tool server interaction must occur within a strictly isolated context to prevent cross-tenant or cross-service data leakage. However, the implementation failed to enforce this isolation. By capturing the cookie jar from the outer execution loop, the application created a shared reference. In scenarios where multiple tools are registered, the loop iterates through each configuration. If the final iteration processes a session-authenticated or OAuth-authenticated connection, the shared cookie jar retains the credentials of that session.\nConsequently, the external tool server receives a request containing the user's session cookies. This represents a severe breakdown of the principle of least privilege, as third-party services receive highly sensitive authentication material. The receiving server's operator can extract these cookies from the HTTP request headers and use them to hijack the active session. This allows the attacker to perform any action the victim is authorized to execute, including accessing private datasets, modifying configurations, or compromising other integrations, depending on the victim's privilege level. This issue affects versions from 0.6.27 until 0.11.1, and is fixed in version 0.11.1."
}