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

Tool source is meant to be a writer-only tier. GET /api/v1/tools/, GET /api/v1/tools/list and GET /api/v1/tools/id/{id} in backend/open_webui/routers/tools.py returned it anyway. ToolResponse omits source and specs, but its subclass ToolUserResponse permits extra fields, and each handler built the response by spreading a full dump of the tool model. The omitted fields came back as extras. The listing path had a second defect: the flag meant to keep source out of listings never changed the query it guarded.

The attacker is an ordinary non-admin account with no workspace.tools permission and no write grant, to whom a tool was shared with read access, directly, through a group, or to all users (user:*). Authentication and plugins are enabled by default. No user interaction is needed.

The loss is confidentiality. Tool source commonly embeds hard-coded API keys, credentials and internal service URLs, so the exposure can go well beyond the code. The attacker cannot create, modify or run tools. Deployments that share no tools, or share them only with users who already have write access, are not affected.

Open WebUI 0.10.2 and earlier, in default configuration (WEBUI_AUTH=true, ENABLE_PLUGINS=true), whenever a tool is shared with a read grant. Check the version:

pip show open-webui

To test exposure, call GET /api/v1/tools/list as a non-admin user and see whether items carry a content field with source.

Upgrade to 0.11.0:

pip install --upgrade open-webui==0.11.0

Commits c05de13b4 (PR 27005) and 310ae9130: the per-id endpoint drops source for callers without write access, and the list endpoints no longer load it. Function specs stay visible, and shared tools still run because execution loads source server-side. Treat any secret embedded in a tool shared before the upgrade as exposed, and rotate it; moving keys into tool valves or environment settings is the safer pattern, though the sources do not prescribe it.

Review which tools are shared read-only, publicly or with groups, and which of them embed keys or internal URLs. Access logs showing non-admin calls to /api/v1/tools/list, /api/v1/tools/ or /api/v1/tools/id/{id} are normal UI traffic, so they prove exposure but not misuse. Look instead for use of the embedded credentials from unexpected places in the downstream services' logs.

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: GET /api/v1/tools/, GET /api/v1/tools/list and GET /api/v1/tools/id/{id} in backend/open_webui/routers/tools.py, and the response models in backend/open_webui/models/tools.py. Every build carrying the plugin routes is affected.

ToolResponse deliberately omits the source and the specs, but its subclass ToolUserResponse permits extra fields, and each handler built its response by spreading a full dump of the tool model. The omitted fields were re-admitted as extras and serialised back to the caller, so the schema meant to enforce the writer-only tier enforced nothing at all. The listing path carried a second, independent defect: the flag that was supposed to keep source out of listings never changed the query it guarded.

Proof of concept

Against a default instance on 0.10.2, with an admin account and a second account of role user:

1. As the admin, create a tool whose source contains a marker secret and share it read-only with everyone:

POST /api/v1/tools/create
{"id": "poctool",
 "name": "PoC Tool",
 "content": "API_KEY = \"TOOL_SRC_SECRET\"\nclass Tools:\n    def hello(self) -> str: return 'hi'",
 "meta": {"description": "poc"},
 "access_grants": [{"principal_type": "user", "principal_id": "*", "permission": "read"}]}

1. As the non-admin, call any of the three read endpoints:

GET /api/v1/tools/list
-> 200, item "poctool": write_access=false, content="API_KEY = \"TOOL_SRC_SECRET\" ..."

The same source is returned by GET /api/v1/tools/ and GET /api/v1/tools/id/poctool. On 0.11.0 the identical run returns the item with no source for the non-admin, while the owner still receives it.

Credits

• bogdancherniy11-sudo — reported the disclosure across the three tool read endpoints.