Listen to this Post
The built-in knowledge search tool resolves which knowledge bases the caller may read.
It passes that readable set to the vector store as a search filter.
That filter is the only access control on the path.
Most shipped vector backends accept the filter argument on their search method.
Those search methods never apply the filter.
Search returns matches from every knowledge base in the shared collection.
The sibling query method on those same backends does apply a filter.
That is why the omission is invisible from the calling code.
The deployment must use an affected vector backend selected by VECTOR_DB.
VECTOR_DB defaults to chroma.
Chroma applies the filter, so a default deployment is not affected.
Eleven of fifteen shipped backends ignore the filter.
Affected backends include 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.
The caller needs a model that can call tools.
Knowledge built-in tools must be left enabled, which is the default.
No knowledge must be 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.
A user receives the identifier, name and description of knowledge bases never shared with them.
The user 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.
Sensitive metadata can leak customer, project or investigation names.
Document text lives in separate per-knowledge-base collections.
Those are reached by a different call scoped by collection rather than by this filter.
Stored documents are not returned by this path.
No write access is gained.
The population at risk is operators who deliberately moved to an external vector store.
The issue was present from 0.7.0 through 0.11.0.
It was fixed in 0.11.1 by 1d6d4e6e6.
Every affected backend now applies the caller-supplied filter in its search method.
The filter is combined with the collection or tenant scoping already performed.
Filter builders were extended to express set membership.
Filters using any other operator are now rejected rather than dropped.
Upgrading is sufficient and no configuration change is required.
DailyCVE Form:
Platform: Open WebUI
Version: 0.7.0-0.11.0
Vulnerability: Broken access control
Severity: Not stated
date: Not stated
Prediction: Already patched
(end of form)
What Undercode Say:
Analytics:
Check deployment vector backend
env | grep VECTOR_DB
Inspect vulnerable search methods for filter usage
grep -R "def search" -n .
grep -R "filter" -n .
Run the documented Qdrant proof-of-concept shape
python - <<'PY'
search(filter={'knowledge_base_id': {'$in': ['kb-allowed']}})
search(filter=None)
PY
Expected vulnerable 0.11.0 results
search(filter={'knowledge_base_id': {'$in': ['kb-allowed']}}) -> ['kb-allowed', 'kb-secret']
search(filter=None) -> ['kb-allowed', 'kb-secret']
Expected fixed 0.11.3 results
search(filter={'knowledge_base_id': {'$in': ['kb-allowed']}}) -> ['kb-allowed']
search(filter=None) -> ['kb-allowed', 'kb-secret']
Exploit: (Educational Purposes!)
Vulnerable 0.11.0 Qdrant client
search(filter={'knowledge_base_id': {'$in': ['kb-allowed']}})
returns ['kb-allowed', 'kb-secret']
search(filter=None)
returns ['kb-allowed', 'kb-secret']
Fixed 0.11.3 Qdrant client
search(filter={'knowledge_base_id': {'$in': ['kb-allowed']}})
returns ['kb-allowed']
search(filter=None)
returns ['kb-allowed', 'kb-secret']
Unaffected Chroma client on both tags
search(filter={'knowledge_base_id': {'$in': ['kb-allowed']}})
returns ['kb-allowed']
search(filter=None)
returns ['kb-allowed']
S3 Vectors stub: whole index returned regardless of filter
0.11.0 -> ['kb-allowed', 'kb-secret']
0.11.3 -> ['kb-allowed']
Protection: from this CVE Impact:
Upgrade to 0.11.1. Use Chroma, pgvector, MariaDB or Valkey. Ensure affected backend search applies caller filter. Ensure filter combines collection or tenant scoping. Ensure set membership filter is supported. Reject unsupported filter operators. No configuration change required after upgrade. No action needed for unaffected backends.
🎯Let’s Practice Exploiting & Learn Patching For Free:
🎓 Live Courses & Certifications:
Join Undercode Academy for Verified Certifications
🚀 Request a Custom Project:
Secure, high-velocity infrastructure and disruptive technological engineering. Contact our engineering team for high-tier development and proprietary systems:
[email protected]
💎 Smart Architecture | 🛡️ Secure by Design | ⭐ Trusted by Thousands
Sources:
Reported By: github.com
Extra Source Hub:
Undercode
