CVE-2026-87015: Open WebUI: A user's session cookies are sent to tool servers configured for bearer authentication

The tool loading routine in backend/open_webui/utils/tools.py builds one callable per tool across all attached connections. Headers were passed into the callable factory as an argument, so they were fixed per connection. The cookie jar was left as a variable in the enclosing scope and read only when the tool ran. By then both loops had finished and the variable held the cookies of the last connection processed.

If a session or system OAuth connection is processed last, a call to a bearer-authenticated server goes out with its own API key plus the calling user's token and oauth_session_id cookies. The operator of that server receives a session credential just by logging ordinary request data.

That token authenticates as the user against all of Open WebUI, so the receiving operator can take over the account for the token's lifetime. If the user is an admin, the operator gets admin access. The party is a server the administrator registered on purpose, so this is a disclosure to a partly trusted third party, not to an anonymous attacker. The CVSS vector reflects high attack complexity and user interaction, since a user's call must reach that server.

It needs at least two tool servers on one request, with one using session or system OAuth authentication. Setups with no tool servers or only one are not affected. The advisory reproduced it against a running instance.

Affected: open-webui from 0.6.27 up to but not including 0.11.1, when at least two external tool servers are attached to the same request and at least one uses session or system OAuth authentication. Tool servers are not configured by default. Check the version:

pip show open-webui

Then review the tool server connections in the admin settings and note which authentication mode each uses.

Upgrade to 0.11.1:

pip install --upgrade open-webui==0.11.1

Pull request 28630 makes the tool callable take its own connection's cookie jar as a parameter, as it already did for headers. Each request now carries only what its connection was configured to send. No configuration change is needed. The sources give no workaround. Because tokens may already have reached tool servers, sign users out to invalidate sessions, and treat servers run by third parties as having seen those tokens.

Check the request logs of each bearer-authenticated tool server for incoming Cookie headers carrying token or oauth_session_id. A bearer-only server should never see them. On the Open WebUI side, review account activity from unfamiliar IPs for users whose tool calls went to third-party tool servers. The advisory gives no other indicators.

Summary

When more than one external tool server is reachable in the same request, a tool call to a server configured for bearer authentication can arrive carrying the calling user's Open WebUI session cookies alongside that server's own key. The cookie jar is built per connection, but the callable that performs the request reads it late instead of per connection, so every tool callable built in the same pass sends the cookies belonging to whichever connection was processed last. An administrator who configures a server with its own API key has not chosen to send that server anything else, and the operator of that server receives a live session credential for the user who triggered the call.

Preconditions

At least two external tool servers must be attached to the same request, and at least one of them must be set to session or system OAuth authentication, since no cookie jar is assembled otherwise. The connection using that authentication mode must be the one processed last, which follows the order of the tool servers attached to the request rather than anything the receiving party controls.

A deployment with no tool servers, with only one tool server, or where no attached server uses session or system OAuth authentication, is not affected. Tool servers are not configured by default.

Impact

The operator of a tool server that was configured with only its own API key receives the session token of every user whose tool call reaches it. That token authenticates as the user against the whole application, so the receiving party can act as that user for the lifetime of the token, which is a full account takeover of anyone whose request lands on that server. Where the affected user is an administrator, the receiving party gains administrative access.

The receiving party is the operator of a server the administrator deliberately registered, so this is a disclosure of user credentials to a partially trusted third party rather than to an arbitrary attacker. It nonetheless crosses a boundary the administrator set, because selecting bearer authentication for a connection states that the connection is authenticated by its own key alone. The leak does not depend on the tool server behaving maliciously to obtain the token, only on it receiving and retaining ordinary request data.

Fix

Fixed in 0.11.1 by https://github.com/open-webui/open-webui/pull/28630. The tool callable now takes its own connection's cookie jar as a parameter, in the same way it already took that connection's headers, so each request carries only what its own connection was configured to send. Upgrading resolves the issue with no configuration change.

Root cause

Affected component: the tool loading routine in backend/open_webui/utils/tools.py, which builds one callable per tool across all attached connections; the header and cookie builder in the same module, which populates a cookie jar only for session and system OAuth connections; and the tool server request function, which places the supplied jar on the outgoing request.

Headers were passed into the callable factory as an argument and were therefore fixed per connection, while the cookie jar was left as a variable in the enclosing scope and was read only when the tool was finally invoked. By then both loops had completed and the variable held the last value assigned to it. The two values are produced together by the same builder and were plainly intended to travel together, so this is an oversight in how one of them was captured rather than a forwarding decision. The equivalent code path for terminal tool servers in the same module binds both values per connection and does not carry the defect.

Proof of concept

Two tool servers were registered: one using bearer authentication with its own key, and one using session authentication, with the session connection processed last. A tool call was driven to an operation belonging to the bearer server, and that server recorded the incoming request.

The bearer server received its own key in the authorization header, together with the calling user's token and oauth_session_id cookies. The received token matched the calling user's session token.

Control: with the session connection removed and only the bearer server registered, the same tool call arrived with no cookies at all, confirming that the leak depends on a session connection being present and processed last.

Reproduced against a running instance built from the affected snapshot, with the receiving tool servers replaced by recording servers.

Credits

Classic298, who reported the issue and demonstrated the cross-connection cookie leak against a running instance.