GHSA-3r7g-q6cg-q2vx is a medium-severity (CVSS 6.5) Information Exposure vulnerability in open-webui. A fix is available for open-webui — see the affected versions and patch details below.
Open WebUI: Tool source code disclosed to read-only users via the tool list and get endpoints
Exploitation Status
Proof-of-concept exploit code exists
- CISA’s SSVC triage found public proof-of-concept exploit code for this CVE, though no confirmed active exploitation.
Exploitation and automatability from CISA’s SSVC triage for GHSA-3r7g-q6cg-q2vx.
EPSS Exploitation Probability
EPSS (Exploit Prediction Scoring System) is a daily probability model maintained by FIRST.org. It estimates the likelihood a CVE will be exploited in production environments within the next 30 days, derived from real-world threat intelligence signals.
How urgent is this, really
GHSA-3r7g-q6cg-q2vx plotted by exploitation likelihood (EPSS) against impact (CVSS). The shaded corner — EPSS 50%+ and CVSS 7.0+ — is where this CVE doesn't sit, though severity or exploitability alone can still warrant action.
Where this sits among everything scored
Of 376,715 CVEs with a current EPSS score, this one falls in the < 10% band (highlighted). Real counts from FIRST.org, not a sample — log-scaled since the landscape is heavily right-skewed.
Real-World Exposure
open-webuiReal-time download stats are indexed for npm and PyPI packages. This vulnerability affects PyPI packages — download data is not available via public APIs for these ecosystems.
Description
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.toolspermission 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:
- 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"}]}
- 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.
Affected Packages
| Ecosystem | Package | Vulnerable range | Fix |
|---|---|---|---|
| 🐍PyPI | open-webui | all versions | 0.11.0pip install --upgrade 'open-webui==0.11.0' |
Detection & mitigation playbook
Open-source dependencyDetect
Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for open-webui, including transitive dependencies — a direct dependency you never call can still pull in a vulnerable version.
Fix
Update open-webui to 0.11.0 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms GHSA-3r7g-q6cg-q2vx is resolved across your whole dependency graph.
Workarounds
If you can't upgrade right away: gate or disable the affected feature, validate untrusted input at the boundary, and avoid passing attacker-controlled data into the vulnerable path. O3's runtime protection blocks exploitation in production as an interim safeguard until the upgrade lands.
How O3 protects you
O3 Security's impact-aware SCA analyses which vulnerable code paths your application actually calls, so a match like GHSA-3r7g-q6cg-q2vx can be triaged on real exposure rather than presence alone.
Tailored to GHSA-3r7g-q6cg-q2vx. Runtime protection reduces exposure until a permanent patch is applied and verified — it complements patching, it doesn't replace it.
Frequently Asked Questions
Is GHSA-3r7g-q6cg-q2vx in your dependencies?
O3 Security finds GHSA-3r7g-q6cg-q2vx across PyPI dependencies, including transitive ones, and its impact-aware SCA ranks findings by whether your code actually calls the vulnerable path.