Open WebUI: Tool source code disclosed to read-only users via the tool list and get endpoints

Summary

A workspace tool shared with a read grant returned its full Python source to the recipient. Any authenticated non-admin who could use a shared tool could also read its source, including any user on the instance when a tool was shared publicly. Source is meant to be a writer-only tier: the list response schema deliberately omits it and source export sits behind its own permission. The read endpoints delivered it anyway.

Preconditions

• Authentication enabled (WEBUI_AUTH=true, default) and plugins enabled (ENABLE_PLUGINS=true, default).
• The attacker is an authenticated non-admin without the workspace.tools permission and without a write grant on the tool.
• A tool is shared with a read grant to the attacker, to one of their groups, or to all users (user:*).

Deployments that share no tools, or share them only with users who already hold write access, are not affected.

Impact

A non-admin obtains another user's server-side tool source. Tool source commonly embeds hard-coded API keys, credentials and internal service URLs, so the practical loss frequently extends past the code itself. The attack needs no special permission beyond an ordinary account that a tool was shared with, and no user interaction. Confidentiality only: it grants no ability to create, modify or execute tools, and no integrity or availability impact.

Fix

Fixed in 0.11.0 by commit c05de13b4 (#27005) together with 310ae9130. The per-id endpoint now drops the source for callers without write access, and the two list endpoints no longer load source at all. Function specs stay visible to read users, since the chat tool listing renders a tool's functions from them. Tool execution loads source server-side, so shared tools keep working. Upgrading to 0.11.0 fully resolves the issue with no configuration change.

Root cause

Affected components: , and in , and the response models in . Every build carrying the plugin routes is affected.