CVE-2026-87017: Broken Object-Level Authorization (BOLA) in Open WebUI Knowledge Search

Open WebUI is an extensible self-hosted artificial intelligence platform. The platform implements a built-in knowledge search tool to retrieve document context and ground language model interactions. Users can define private or shared knowledge bases containing documents, which are subsequently indexed in a vector database backend.

The platform provides integration with fifteen distinct vector database backends. When a user queries the system, the application is designed to identify the knowledge bases that the specific user is authorized to read. It then generates a metadata filter specifying those authorized identifiers, passing the filter constraint to the active vector database wrapper to isolate the search space.

In versions 0.7.0 through 0.11.0, eleven of the fifteen supported vector backends received the authorization filter parameter but failed to apply it during database query generation. This design inconsistency resulted in a broken object-level authorization (BOLA) vulnerability. Consequently, search queries executed by authenticated low-privilege users could match against and expose records from unshared or restricted collections.

The root cause of this vulnerability lies in an architectural misalignment within the vector client adapters. The abstract base class VectorDBBase specifies filter: Optional[dict] = None in its standard search method signature. However, the concrete class implementations for eleven vector database clients failed to implement translation or passing of this parameter to their respective backend search engines.

When a query is dispatched, the database wrapper is responsible for converting the generic dictionary filter structure into the native query syntax of the target vector store. Because the wrapper implementations silently dropped the filter parameter, the resulting database query did not contain any metadata constraints. The database engine executed a global search across the index, returning matched vectors regardless of their original knowledge base ownership.

The exposure is primarily limited to metadata associated with the matched vector points. This metadata typically includes the unique identifiers, names, and descriptions of the knowledge bases. Although the primary text contents of the documents are stored in separate collections, the leaked metadata exposes sensitive organizational taxonomies, file structures, and descriptive summaries to unauthorized authenticated users.

An examination of the vulnerable and patched code reveals the omission of the filter parsing logic. In the Elasticsearch backend (elasticsearch.py) before the patch, the search method hardcoded the query to filter solely on the static collection name. The incoming filter argument was completely unused during query construction.

# Vulnerable Elasticsearch Query Construction
query = {
    'size': limit,
    '_source': ['text', 'metadata'],
    'query': {
        'script_score': {
            'query': {'bool': {'filter': [{'term': {'collection': collection_name}}]}},
            'script': {
                'source': "cosineSimilarity(params.vector, 'vector') + 1.0",
                ...
            }
        }
    }
}

The remediation introduces a helper function _metadata_filter to map operations such as $in into Elasticsearch terms queries, and dynamically appends these conditions to the filter array.

# Patched Elasticsearch Query Construction
def _metadata_filter(key: str, op: str, value: Any) -> dict:
    if op == '$in':
        return {'terms': {f'metadata.{key}': value}}
    return {'term': {f'metadata.{key}': value}}
 
# Inside the patched search() method
filters = [{'term': {'collection': collection_name}}]
if filter:
    filters.extend(_metadata_filter(key, op, value) for key, op, value in iter_filter_conditions(filter))
 
query = {
    'size': limit,
    '_source': ['text', 'metadata'],
    'query': {
        'script_score': {
            'query': {'bool': {'filter': filters}},
            ...
        }
    }
}

Similarly, the Qdrant backend implementation was updated to translate generic metadata constraints into formal Qdrant FieldCondition models. The patch maps standard filtering operators to either MatchAny or MatchValue conditions, ensuring the query includes a defined query_filter attribute.

# Patched Qdrant Filter Construction
def _metadata_filter(key: str, op: str, value: Any) -> models.FieldCondition:
    match = models.MatchAny(any=value) if op == '$in' else models.MatchValue(value=value)
    return models.FieldCondition(key=f'metadata.{key}', match=match)
 
# Applying filter in search()
conditions = [_metadata_filter(key, op, value) for key, op, value in iter_filter_conditions(filter)]
query_filter = models.Filter(must=conditions) if conditions else None

The exploitation of this vulnerability does not require complex payloads or high privileges. An attacker must first authenticate to the target Open WebUI instance with a standard user account. The vulnerability is triggered when the attacker submits a query that forces the platform to execute a knowledge search, or when they interact directly with backend API endpoints responsible for knowledge retrieval.

When the query is initiated, the platform backend correctly calculates the attacker's authorization scope, producing a metadata filter containing only the knowledge bases they are allowed to read. However, because the active vector client wrapper (such as Milvus or Qdrant) silently discards the filter parameter, the query executes globally.

The vector database processes the semantic similarity of the query against all stored vectors, including those belonging to other users' private knowledge bases. The database returns the closest matches along with their metadata. The application then propagates these results back, presenting the attacker with the titles, descriptions, and IDs of unauthorized knowledge bases.

A representation of this flow is shown in the sequence below:

The primary security impact of CVE-2026-87017 is the unauthorized exposure of sensitive metadata. This includes knowledge base identifiers, names, and descriptions belonging to other users or administrators. In many enterprise settings, knowledge base names and descriptions contain confidential information such as project names, internal server names, or proprietary product details.

The vulnerability has been assigned a CVSS score of 4.3 (Medium) with the vector CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N. The impact is restricted to confidentiality, with no integrity or availability implications. The exploitability is low because the attack requires authenticated access, but the execution complexity is low since the application logic bypasses the security boundary automatically.

While the document body text itself is typically stored in separate collections, the exposure of metadata acts as a valuable reconnaissance tool. An attacker can map the structure of an organization's knowledge store, identifying target repositories or project frameworks for subsequent attacks or social engineering campaigns.

The primary and most effective remediation step is upgrading the Open WebUI installation to version 0.11.1 or higher. The developers have successfully refactored the vector database adapters to properly map, validate, and apply metadata filters to prevent global index queries.

If an immediate upgrade is not feasible, several defensive mitigation strategies can be applied. Administrators can disable the built-in knowledge search tool globally or restrict its use to trusted roles via the admin configuration panel. This restricts the vector database query path from being triggered by arbitrary users.

Alternatively, administrators can switch the active vector database backend to Chroma. The Chroma backend adapter correctly implemented and applied metadata filters in older versions and was not affected by this vulnerability. Another alternative is physical segmentation, where sensitive knowledge bases are deployed to separate, isolated vector store instances.