CVE-2026-87017: Open WebUI: Inaccessible knowledge bases are exposed through the built-in knowledge tool on most vector backends

The knowledge search tool works out which knowledge bases the caller may read and passes that set to the vector store as a search filter. That filter is the only access control on the path. Eleven of the fifteen shipped backends accept the filter argument on search and never apply it, so the search returns matches from every knowledge base in the shared collection. Their query method does apply a filter, which hides the gap from the calling code.

The affected backends are both Qdrant clients, Elasticsearch, OpenSearch, both Milvus clients, openGauss, Oracle 23ai, Pinecone, S3 Vectors and Weaviate. Chroma, pgvector, MariaDB and Valkey apply the filter and were never affected. VECTOR_DB defaults to chroma.

Any user whose model can call tools, with the knowledge built-in tools left on (the default) and no knowledge attached to the model, can ask the model to search. The user gets the identifier, name and description of knowledge bases never shared with them, and can enumerate more by varying the query and result count. That matters where names describe a customer, a project or an investigation.

The exposure stops at that metadata. Document text sits in separate per-knowledge-base collections reached by another call, so stored documents are not returned, and no write access is gained. The population at risk is operators who chose an external vector store, which usually means larger deployments.

Affected: open-webui from 0.7.0 through 0.11.0, when VECTOR_DB selects Qdrant (either client), Elasticsearch, OpenSearch, Milvus (either client), openGauss, Oracle 23ai, Pinecone, S3 Vectors or Weaviate. Default Chroma, pgvector, MariaDB and Valkey are not affected. Check the version and the setting:

pip show open-webui

Then look at the VECTOR_DB environment variable in your deployment.

Upgrade to 0.11.1:

pip install --upgrade open-webui==0.11.1

The fix (commit 1d6d4e6) makes every affected backend apply the caller's filter in search, combined with the collection or tenant scoping it already did. Backend filter builders that handled only single-value equality now also handle set membership, since that is what the knowledge tool sends. A filter with any other operator is now rejected instead of dropped. No configuration change is needed. Chroma, pgvector, MariaDB and Valkey deployments need no action. The sources give no workaround.

The leak leaves no distinct log line. Review chat logs and tool-call records for knowledge search calls made by users, and compare the knowledge base names they received with their access rights. If your knowledge base names or descriptions are sensitive, treat names returned to unauthorised users on affected backends as disclosed. To test a deployment, ask a low-privilege user's model to search the knowledge tool for the name of a knowledge base you know they cannot read.

Summary

The built-in knowledge search tool returns knowledge bases the calling user has no access to. The tool works out which knowledge bases the caller may read and hands that set to the vector store as a search filter, and that filter is the only access control on the path. Most of the shipped vector backends accept the filter argument on their search method and never apply it, so the search returns matches from every knowledge base in the shared collection. The sibling query method on those same backends does apply a filter, which is why the omission is invisible from the calling code.

Preconditions

• The deployment must use one of the affected vector backends, selected with VECTOR_DB, which defaults to chroma. Chroma applies the filter, so a default deployment is not affected.
• Eleven of the fifteen shipped backends ignore the filter: both Qdrant clients, Elasticsearch, OpenSearch, both Milvus clients, openGauss, Oracle 23ai, Pinecone, S3 Vectors and Weaviate. Chroma, pgvector, MariaDB and Valkey apply it and were never affected.
• The caller needs a model that can call tools, with the knowledge built-in tools left enabled, which is the default, and with no knowledge attached to the model itself. No elevated role or permission is required.
• At least one knowledge base must exist that the caller cannot otherwise read.

Impact

A user receives the identifier, name and description of knowledge bases that were never shared with them, and chooses how many results to ask for, so the set can be enumerated by varying the query. The affected collection stores one entry per knowledge base whose text is its name and description, so where those values are themselves sensitive, for example when they name a customer, a project or an investigation, that disclosure is the loss.

The exposure is confined to that metadata. Document text lives in separate per-knowledge-base collections reached by a different call that is scoped by collection rather than by this filter, so stored documents are not returned by this path, and no write access is gained. Because the default backend is unaffected, the population at risk is operators who deliberately moved to an external vector store, which in practice means larger deployments.

Fix

Fixed in 0.11.1 by 1d6d4e6e6. Every affected backend now applies the caller-supplied filter in its search method, combined with the collection or tenant scoping that method already performed. Where a backend's filter builder could express only single-value equality it was extended to express set membership, since that is the form the knowledge tool sends, and a filter using any other operator is now rejected rather than dropped. Upgrading is sufficient and no configuration change is required. Deployments on Chroma, pgvector, MariaDB or Valkey were never affected and need no action.

Root cause

• The search method of each affected vector client, which declares a filter parameter and never references it.
• The built-in knowledge search tool, which relies on that filter as its only access check.
• Present from 0.7.0, the release that introduced the tool, through 0.11.0.

Each client exposes a search method and a query method that appear interchangeable from the calling side and differ in whether the caller's filter survives. Search built its request with collection or tenant scoping only, so it was correctly scoped to the collection and entirely unscoped within it. The knowledge tool resolves the caller's readable knowledge bases correctly and passes them down, then reads the results without rechecking them, on the reasonable assumption that a filter handed to a vector store is applied. Because the access decision was delegated wholly to a parameter that most implementations discarded, the caller had no way to observe that it received more than it asked for.

That the same omission repeated across most backends points at the shared interface rather than at any one client: the base class defines the parameter without obliging an implementation to honour it, and each backend was written against the interface independently.

Proof of concept

Run against the shipped client classes taken from the 0.11.0 and 0.11.3 release tags, with a real Qdrant engine behind them. Two entries were inserted into the shared knowledge base collection, one readable and one not, mirroring the payload the application writes. The entries were inserted directly rather than created through the application.

On 0.11.0, search given a filter naming only the readable knowledge base returned both, and the same call with no filter returned an identical result set, confirming the filter had no effect:

search(filter={'knowledge_base_id': {'$in': ['kb-allowed']}})  ->  ['kb-allowed', 'kb-secret']
search(filter=None)                                            ->  ['kb-allowed', 'kb-secret']

On 0.11.3 the same filter returned only the readable entry, while the unfiltered control still returned both, confirming the collection held both and the filter is what excluded the second:

search(filter={'knowledge_base_id': {'$in': ['kb-allowed']}})  ->  ['kb-allowed']
search(filter=None)                                            ->  ['kb-allowed', 'kb-secret']

The Chroma client, run the same way on both tags, returned only the readable entry in every case, which is the default backend being unaffected. The S3 Vectors client was additionally run against a stub that answers every query with the whole index regardless of the filter it is sent: on 0.11.0 it returned both entries, and on 0.11.3 it returned only the readable one.

The remaining backends were checked by driving each patched filter builder with the exact filter the knowledge tool sends and confirming the request it produces restricts to the readable knowledge base.

Credits

Reported by @Classic298.