GHSA-CX9V-4QJ2-JRW6

Vulnerability from github – Published: 2026-06-17 14:31 – Updated: 2026-06-17 14:31
VLAI
Summary
Open WebUI BOLA: `search_knowledge_files` Allows Unauthorized Knowledge Base File Enumeration
Details

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:

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:

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:

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:

{
  "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():

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.

Severity
4.3 (Medium)
CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N
Show details on source website
To clipboard 

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 0.9.5"
      },
      "package": {
        "ecosystem": "PyPI",
        "name": "open-webui"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "0.9.6"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-54016"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-862"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-06-17T14:31:16Z",
    "nvd_published_at": null,
    "severity": "MODERATE"
  },
  "details": "## Summary\n\nOpen WebUI has a Broken Object Level Authorization (BOLA) vulnerability in the builtin `search_knowledge_files` tool.\n\nWhen 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.\n\nThis allows unauthorized enumeration of private or restricted knowledge base files.\n\n## Details\n\nThe vulnerable code is in:\n\n`backend/open_webui/tools/builtin.py`\n\nAffected function:\n\n```python\nasync def search_knowledge_files(\n    query: str,\n    knowledge_id: Optional[str] = None,\n    count: int = 5,\n    skip: int = 0,\n    __request__: Request = None,\n    __user__: dict = None,\n    __model_knowledge__: Optional[list[dict]] = None,\n) -\u003e str:\n```\n\nIn the \"No attached knowledge\" branch, when `knowledge_id` is provided, the function directly calls:\n\n```python\nresult = await Knowledges.search_files_by_id(\n    knowledge_id=knowledge_id,\n    user_id=user_id,\n    filter={\"query\": query},\n    skip=skip,\n    limit=count,\n)\n```\n\nThis code path does not verify that the current user is authorized to access the specified knowledge base.\n\nThe 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`:\n\n```python\nif not (\n    user_role == \"admin\"\n    or knowledge.user_id == user_id\n    or await AccessGrants.has_access(\n        user_id=user_id,\n        resource_type=\"knowledge\",\n        resource_id=knowledge.id,\n        permission=\"read\",\n        user_group_ids=set(user_group_ids),\n    )\n):\n    continue\n```\n\nThe sibling function `query_knowledge_files` also performs the same authorization check before using user-supplied knowledge base IDs.\n\nThe 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\u0027s permissions.\n\n## PoC\n\n### Prerequisites\n\n- The attacker has a valid authenticated Open WebUI account.\n- The victim owns a private or restricted knowledge base.\n- The attacker does not own the target knowledge base.\n- The attacker does not have `read` permission for the target knowledge base in `AccessGrants`.\n- The attacker knows the target `knowledge_id`.\n- The selected model has no attached knowledge bases.\n- Builtin tools are enabled.\n- The knowledge builtin tool category is enabled.\n- Native function calling is enabled.\n\n### Reproduction Steps\n\n1. Create a private or restricted knowledge base as the victim user.\n\n2. Upload one or more files to that knowledge base.\n\n3. Confirm that the attacker user does not have access to the knowledge base.\n\n4. As the attacker user, send a chat completion request with native function calling enabled:\n\n```json\n{\n  \"stream\": true,\n  \"model\": \"gpt-4o-mini\",\n  \"params\": {\n    \"function_calling\": \"native\"\n  },\n  \"messages\": [\n    {\n      \"role\": \"user\",\n      \"content\": \"Please use the search_knowledge_files tool with knowledge_id \\\"c0c84752-2e9d-42bf-bc3c-c0f272aa61c1\\\" to search all files\"\n    }\n  ]\n}\n```\n\nReplace `c0c84752-2e9d-42bf-bc3c-c0f272aa61c1` with the victim\u0027s private knowledge base ID.\n\n### Expected Result\n\nThe request should be denied because the attacker does not have access to the target knowledge base.\n\n### Actual Result\n\n`search_knowledge_files` returns metadata for files inside the target knowledge base, including:\n\n- file ID;\n- filename;\n- knowledge base ID;\n- knowledge base name;\n- update timestamp.\n\n## Impact\n\nThis is a Broken Object Level Authorization / Broken Access Control vulnerability.\n\nAn authenticated attacker who knows a valid `knowledge_id` can enumerate files from private or restricted knowledge bases without authorization.\n\nThe leaked metadata may expose sensitive information through filenames, such as:\n\n- financial reports;\n- employee documents;\n- customer contracts;\n- internal roadmap files;\n- confidential project documents.\n\nThe 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.\n\nThis vulnerability bypasses the intended `AccessGrants` permission model and may also allow post-revocation metadata access if a user remembers a previously accessible `knowledge_id`.\n\n## Suggested Fix\n\nAdd the same authorization check used in `query_knowledge_files` before calling `Knowledges.search_files_by_id()`:\n\n```python\nif knowledge_id:\n    knowledge = await Knowledges.get_knowledge_by_id(knowledge_id)\n\n    if not knowledge or not (\n        user_role == \"admin\"\n        or knowledge.user_id == user_id\n        or await AccessGrants.has_access(\n            user_id=user_id,\n            resource_type=\"knowledge\",\n            resource_id=knowledge.id,\n            permission=\"read\",\n            user_group_ids=set(user_group_ids),\n        )\n    ):\n        return json.dumps({\"error\": f\"Access denied to knowledge base {knowledge_id}\"})\n\n    result = await Knowledges.search_files_by_id(\n        knowledge_id=knowledge_id,\n        user_id=user_id,\n        filter={\"query\": query},\n        skip=skip,\n        limit=count,\n    )\n```\n\nAs 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.",
  "id": "GHSA-cx9v-4qj2-jrw6",
  "modified": "2026-06-17T14:31:16Z",
  "published": "2026-06-17T14:31:16Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/open-webui/open-webui/security/advisories/GHSA-cx9v-4qj2-jrw6"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/open-webui/open-webui"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Open WebUI BOLA: `search_knowledge_files` Allows Unauthorized Knowledge Base File Enumeration"
}


Log in or create an account to share your comment.




Tags
Taxonomy of the tags.





Forecast uses a logistic model when the trend is rising, or an exponential decay model when the trend is falling. Fitted via linearized least squares.

Sightings

Author Source Type Date Other

Nomenclature

  • Seen: The vulnerability was mentioned, discussed, or observed by the user.
  • Confirmed: The vulnerability has been validated from an analyst's perspective.
  • Published Proof of Concept: A public proof of concept is available for this vulnerability.
  • Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
  • Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
  • Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
  • Not confirmed: The user expressed doubt about the validity of the vulnerability.
  • Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.


Detection rules are retrieved from Rulezet.