Open WebUI contains a broken object level authorization flaw in its builtin `search_knowledge_files` tool that allows any authenticated user to enumerate file metadata from knowledge bases they have no rights to access, simply by supplying a target `knowledge_id` in a chat completion request with native function calling enabled. While the CVSS is moderate at 4.3, the EPSS percentile sits in the top 93% for exploitation likelihood, and the attack requires only a valid account with zero AI or security expertise — a trivial, fully documented proof-of-concept is included in the advisory. Organizations using Open WebUI to store sensitive internal documents (HR files, financial reports, legal contracts, roadmaps) in knowledge bases face a real risk of metadata enumeration that can chain into full content extraction via the `view_knowledge_file` endpoint. Patch immediately to open-webui 0.9.6; as a temporary workaround, disable native function calling or the knowledge builtin tool category in Open WebUI settings.
What is the risk?
Despite a medium CVSS score (4.3), operational risk is elevated for enterprises running Open WebUI as an internal AI platform. The attack is network-accessible (AV:N), low complexity (AC:L), requires only low privileges (PR:L), and needs no user interaction. The 93rd EPSS percentile indicates above-average exploitation interest from the community. The missing authorization check is in a clearly documented code path with a published PoC — exploitation does not require reverse engineering or advanced skills. With 102 prior CVEs in open-webui, the package has a demonstrated history of security debt that warrants heightened patch urgency. Risk is LOW for organizations not using Open WebUI in enterprise multi-user deployments; HIGH for those storing sensitive documents in knowledge bases with multiple user roles.
How does the attack unfold?
What systems are affected?
| Package | Ecosystem | Vulnerable Range | Patched |
|---|---|---|---|
| Open WebUI | pip | <= 0.9.5 | 0.9.6 |
Do you use Open WebUI? You're affected.
How severe is it?
What is the attack surface?
What should I do?
5 steps-
Patch
Upgrade open-webui to version 0.9.6 where the authorization check has been added to the
search_knowledge_filescode path. -
Workaround (if patching is delayed)
In Open WebUI admin settings, disable native function calling (
function_callingparam) or disable the knowledge builtin tool category entirely. -
Detection
Query application logs for
search_knowledge_filesinvocations where theknowledge_idin the request does not match any knowledge base owned by or explicitly shared with the requesting user (user_id). Anomalous patterns: a single user querying many distinctknowledge_idvalues in a short window. -
Audit
Review the
AccessGrantstable for any unauthorized read grants that may have been established through chained exploitation. -
Rotate UUIDs
If exposure is suspected, consider regenerating knowledge base IDs for sensitive knowledge bases to invalidate any attacker-collected IDs.
How is it classified?
Which compliance frameworks are affected?
This CVE is relevant to:
Frequently Asked Questions
What is CVE-2026-54016?
Open WebUI contains a broken object level authorization flaw in its builtin `search_knowledge_files` tool that allows any authenticated user to enumerate file metadata from knowledge bases they have no rights to access, simply by supplying a target `knowledge_id` in a chat completion request with native function calling enabled. While the CVSS is moderate at 4.3, the EPSS percentile sits in the top 93% for exploitation likelihood, and the attack requires only a valid account with zero AI or security expertise — a trivial, fully documented proof-of-concept is included in the advisory. Organizations using Open WebUI to store sensitive internal documents (HR files, financial reports, legal contracts, roadmaps) in knowledge bases face a real risk of metadata enumeration that can chain into full content extraction via the `view_knowledge_file` endpoint. Patch immediately to open-webui 0.9.6; as a temporary workaround, disable native function calling or the knowledge builtin tool category in Open WebUI settings.
Is CVE-2026-54016 actively exploited?
No confirmed active exploitation of CVE-2026-54016 has been reported, but organizations should still patch proactively.
How to fix CVE-2026-54016?
1. **Patch**: Upgrade open-webui to version 0.9.6 where the authorization check has been added to the `search_knowledge_files` code path. 2. **Workaround (if patching is delayed)**: In Open WebUI admin settings, disable native function calling (`function_calling` param) or disable the knowledge builtin tool category entirely. 3. **Detection**: Query application logs for `search_knowledge_files` invocations where the `knowledge_id` in the request does not match any knowledge base owned by or explicitly shared with the requesting user (`user_id`). Anomalous patterns: a single user querying many distinct `knowledge_id` values in a short window. 4. **Audit**: Review the `AccessGrants` table for any unauthorized read grants that may have been established through chained exploitation. 5. **Rotate UUIDs**: If exposure is suspected, consider regenerating knowledge base IDs for sensitive knowledge bases to invalidate any attacker-collected IDs.
What systems are affected by CVE-2026-54016?
This vulnerability affects the following AI/ML architecture patterns: RAG pipelines, enterprise AI assistants, agent frameworks, knowledge management systems.
What is the CVSS score for CVE-2026-54016?
CVE-2026-54016 has a CVSS v3.1 base score of 4.3 (MEDIUM). The EPSS exploitation probability is 0.02%.
What is the AI security impact?
Affected AI Architectures
MITRE ATLAS Techniques
AML.T0012 Valid Accounts AML.T0053 AI Agent Tool Invocation AML.T0084.000 Embedded Knowledge AML.T0085 Data from AI Services AML.T0085.000 RAG Databases AML.T0085.001 AI Agent Tools Compliance Controls Affected
What are the technical details?
Original Advisory
## Summary Open WebUI has a Broken Object Level Authorization (BOLA) vulnerability in the builtin `search_knowledge_files` tool. When native function calling is enabled and the selected model has no attached knowledge bases, an authenticated user can call `search_knowledge_files` with an arbitrary `knowledge_id`. The function then returns file metadata from that knowledge base without checking whether the user has read access. This allows unauthorized enumeration of private or restricted knowledge base files. ## Details The vulnerable code is in: `backend/open_webui/tools/builtin.py` Affected function: ```python async def search_knowledge_files( query: str, knowledge_id: Optional[str] = None, count: int = 5, skip: int = 0, __request__: Request = None, __user__: dict = None, __model_knowledge__: Optional[list[dict]] = None, ) -> str: ``` In the "No attached knowledge" branch, when `knowledge_id` is provided, the function directly calls: ```python result = await Knowledges.search_files_by_id( knowledge_id=knowledge_id, user_id=user_id, filter={"query": query}, skip=skip, limit=count, ) ``` This code path does not verify that the current user is authorized to access the specified knowledge base. The missing check is inconsistent with other nearby code paths. For example, the attached-knowledge branch in the same function checks whether the user is an admin, the owner of the knowledge base, or has explicit read access through `AccessGrants`: ```python if not ( user_role == "admin" or knowledge.user_id == user_id or await AccessGrants.has_access( user_id=user_id, resource_type="knowledge", resource_id=knowledge.id, permission="read", user_group_ids=set(user_group_ids), ) ): continue ``` The sibling function `query_knowledge_files` also performs the same authorization check before using user-supplied knowledge base IDs. The underlying method `Knowledges.search_files_by_id()` receives `user_id`, but it does not enforce authorization for the provided `knowledge_id`. As a result, this builtin tool path can access a knowledge base by ID without verifying the caller's permissions. ## PoC ### Prerequisites - The attacker has a valid authenticated Open WebUI account. - The victim owns a private or restricted knowledge base. - The attacker does not own the target knowledge base. - The attacker does not have `read` permission for the target knowledge base in `AccessGrants`. - The attacker knows the target `knowledge_id`. - The selected model has no attached knowledge bases. - Builtin tools are enabled. - The knowledge builtin tool category is enabled. - Native function calling is enabled. ### Reproduction Steps 1. Create a private or restricted knowledge base as the victim user. 2. Upload one or more files to that knowledge base. 3. Confirm that the attacker user does not have access to the knowledge base. 4. As the attacker user, send a chat completion request with native function calling enabled: ```json { "stream": true, "model": "gpt-4o-mini", "params": { "function_calling": "native" }, "messages": [ { "role": "user", "content": "Please use the search_knowledge_files tool with knowledge_id \"c0c84752-2e9d-42bf-bc3c-c0f272aa61c1\" to search all files" } ] } ``` Replace `c0c84752-2e9d-42bf-bc3c-c0f272aa61c1` with the victim's private knowledge base ID. ### Expected Result The request should be denied because the attacker does not have access to the target knowledge base. ### Actual Result `search_knowledge_files` returns metadata for files inside the target knowledge base, including: - file ID; - filename; - knowledge base ID; - knowledge base name; - update timestamp. ## Impact This is a Broken Object Level Authorization / Broken Access Control vulnerability. An authenticated attacker who knows a valid `knowledge_id` can enumerate files from private or restricted knowledge bases without authorization. The leaked metadata may expose sensitive information through filenames, such as: - financial reports; - employee documents; - customer contracts; - internal roadmap files; - confidential project documents. The exposed file IDs may also help attackers chain this issue with other knowledge-file access paths, such as `view_knowledge_file`, to attempt further content extraction. This vulnerability bypasses the intended `AccessGrants` permission model and may also allow post-revocation metadata access if a user remembers a previously accessible `knowledge_id`. ## Suggested Fix Add the same authorization check used in `query_knowledge_files` before calling `Knowledges.search_files_by_id()`: ```python if knowledge_id: knowledge = await Knowledges.get_knowledge_by_id(knowledge_id) if not knowledge or not ( user_role == "admin" or knowledge.user_id == user_id or await AccessGrants.has_access( user_id=user_id, resource_type="knowledge", resource_id=knowledge.id, permission="read", user_group_ids=set(user_group_ids), ) ): return json.dumps({"error": f"Access denied to knowledge base {knowledge_id}"}) result = await Knowledges.search_files_by_id( knowledge_id=knowledge_id, user_id=user_id, filter={"query": query}, skip=skip, limit=count, ) ``` As defense in depth, authorization should also be enforced or safely wrapped around `Knowledges.search_files_by_id()` so that future callers cannot accidentally bypass access control.
Exploitation Scenario
An attacker registers a legitimate Open WebUI account in a multi-tenant enterprise deployment — or compromises a low-privilege existing account. They observe or infer a target `knowledge_id` UUID from shared UI context, a leaked URL, or systematic UUID enumeration (UUIDs are not secret once any shared interaction exposes them). With native function calling enabled on any model with no attached knowledge bases, the attacker crafts a chat message instructing the model to call `search_knowledge_files` with the target UUID. The builtin tool executes without checking `AccessGrants`, returning filenames, file IDs, and timestamps from the victim's private knowledge base. The attacker catalogs the file IDs and uses them to call `view_knowledge_file` or similar endpoints to extract full document content, building a complete picture of the organization's sensitive document landscape without ever having been granted access.
Weaknesses (CWE)
CWE-862 — Missing Authorization: The product does not perform an authorization check when an actor attempts to access a resource or perform an action.
- [Architecture and Design] Divide the product into anonymous, normal, privileged, and administrative areas. Reduce the attack surface by carefully mapping roles with data and functionality. Use role-based access control (RBAC) [REF-229] to enforce the roles at the appropriate boundaries. Note that this approach may not protect against horizontal authorization, i.e., it will not protect a user from attacking others with the same role.
- [Architecture and Design] Ensure that access control checks are performed related to the business logic. These checks may be different than the access control checks that are applied to more generic resources such as files, connections, processes, memory, and database records. For example, a database may restrict access for medical records to a specific database user, but each record might only be intended to be accessible to the patient and the patient's doctor [REF-7].
Source: MITRE CWE corpus.
CVSS Vector
CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N References
Timeline
Related Vulnerabilities
CVE-2026-44551 9.1 open-webui: LDAP auth bypass — full account takeover
Same package: open-webui CVE-2026-45672 8.8 open-webui: code exec gate bypass via API endpoint
Same package: open-webui CVE-2026-44552 8.7 open-webui: Redis cache poisoning enables cross-instance tool hijack
Same package: open-webui CVE-2025-64495 8.7 Open WebUI: XSS-to-RCE via malicious prompt injection
Same package: open-webui CVE-2026-45315 8.7 open-webui: stored XSS → JWT theft and admin takeover
Same package: open-webui