CVE-2026-28788: Open webui Open WebUI's Process_files_batch() Endpoint Missing Vulnerability

HIGH
Advisory Identifier: GHSA-jjp7-g2jw-wh3j
CVSS 7.1
CWE-639
Published
Advisory Summary

CVE-2026-28788 is a HIGH (CVSS 7.1) open webui's process_files_batch() endpoint missing vulnerability (CWE-639: Authorization Bypass Through User-Controlled Key) affecting Open webui libraries in the PyPI ecosystem. The issue involves open webui's process_files_batch() endpoint missing ownership check, allows unauthorized file overwrite. Remediation is available by upgrading affected packages to version 0.8.6.

CVE-2026-28788 at a Glance

CVE Identifier CVE-2026-28788
GHSA Identifier GHSA-jjp7-g2jw-wh3j
Severity HIGH
CVSS v3.1 Base Score 7.1
CWE Classification CWE-639: Authorization Bypass Through User-Controlled Key
Affected Product Open webui
Package Ecosystem PyPI
Published Date
Last Updated

Security Impact

CVSS: 7.1

The security impact metrics below are parsed directly from the CVSS v3.1 vector string (CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:H/A:L).

Attack Vector Network (AV:N)
Attack Complexity Low (AC:L)
Privileges Required Low (PR:L)
User Interaction None (UI:N)
Scope Unchanged (S:U)
Confidentiality None (C:N)
Integrity High (I:H)
Availability Low (A:L)

How to Fix CVE-2026-28788

To remediate this vulnerability, upgrade all affected Open webui dependencies to a patched release. Both direct and transitive dependencies should be checked, as frameworks or security libraries may pull in vulnerable versions transitively.

open-webui fixed: 0.8.6
pip install open-webui>=0.8.6
Verify Direct and Transitive Dependencies

Run the following command in your project directory to verify that all resolved dependencies use the patched release:

pip show open-webui

How to Check if You Are Affected

To determine whether your Python environment is affected by CVE-2026-28788, inspect your installed packages using pip:

pip show open-webui

Analyze the terminal output to locate any version of Open webui in your dependency tree. If any resolved version matches the vulnerable ranges listed in the table below (for example, versions earlier than 0.8.6), your application is affected.

Note: The pip show open-webui command checks currently installed packages in your active Python environment.

Technical Details

Vulnerability Mechanism & Technical Analysis

This vulnerability is classified under CWE-639: Authorization Bypass Through User-Controlled Key, where the system's authorization functionality does not prevent one user from gaining access to another user's data or record by modifying the key value identifying the data. In Open webui, software state validation or input boundaries are circumvented during processing. Review the official source advisory statement below for specific affected components, classes, and reproduction details.

Source Advisory Statement

### Summary Any authenticated user can overwrite any file's content by ID through the `POST /api/v1/retrieval/process/files/batch` endpoint. The endpoint performs no ownership check, so a regular user with read access to a shared knowledge base can obtain file UUIDs via `GET /api/v1/knowledge/{id}/files` and then overwrite those files, escalating from read to write. The overwritten content is served to the LLM via RAG, meaning the attacker controls what the model tells other users. ### Details The `process_files_batch()` function in `backend/open_webui/routers/retrieval.py` appears to be designed as an internal helper. The knowledge base router (`add_files_to_knowledge_batch()` in `knowledge.py`) imports and calls it directly after performing its own ownership and access control checks. The frontend never calls the retrieval route directly; all legitimate UI flows go through the knowledge base wrapper. However, the function is also exposed as a standalone HTTP endpoint via `@router.post(...)`. This direct route only requires `get_verified_user` (any authenticated user) and performs no ownership check of its own: ```python for file in form_data.files: text_content = file.data.get("content", "") # attacker-controlled file_updates.append(FileUpdateForm( hash=calculate_sha256_string(text_content), data={"content": text_content}, # written to DB )) for file_update, file_result in zip(file_updates, file_results): Files.update_file_by_id(id=file_result.file_id, form_data=file_update) # ^^^ no ownership check ``` There is no verification that `file.user_id == user.id` before the write. Any authenticated user who knows a file UUID can overwrite that file. **How an attacker obtains file UUIDs:** Same as with read access, any user who can see a knowledge base can retrieve file IDs for every document in it via `GET /api/v1/knowledge/{id}/files`. In deployments where knowledge bases are shared across teams, this gives any regular user a list of valid targets. **Suggested fix:** Add an ownership check before writing: ```python for file in form_data.files: db_file = Files.get_file_by_id(file.id) if not db_file or (db_file.user_id != user.id and user.role != "admin"): file_errors.append(BatchProcessFilesResult( file_id=file.id, status="failed", error="Permission denied: not file owner", )) continue ``` **Classification:** - CWE-639: Authorization Bypass Through User-Controlled Key - OWASP API1:2023: Broken Object Level Authorization Tested on Open WebUI **0.8.3** using a default Docker configuration. ### PoC **Prerequisites:** - Default Open WebUI installation (Docker: `ghcr.io/open-webui/open-webui:main`) - An admin or user creates a knowledge base with shared read access and uploads a file - A regular user account exists (the attacker) **Obtaining the file UUID (attacker):** ``` GET /api/v1/knowledge/{kb_id}/files ``` This returns metadata for all files in the KB, including their UUIDs. **Exploit (attacker):** ```bash python3 poc_exploit.py --url http://<host>:3000 --file-id <target-file-uuid> -t <attacker-jwt> ``` The PoC script: [poc_exploit.py](https://github.com/user-attachments/files/25470374/poc_exploit.py) 1. Authenticates as the attacker 2. Overwrites the target file via `POST /api/v1/retrieval/process/files/batch` with a canary payload containing a unique marker string 3. Reads the file back and confirms the attacker's content replaced the original **Verifying RAG poisoning:** After the overwrite, log in as any other user, start a chat with the poisoned knowledge base attached, and ask about the document. The model's response will include the attacker's canary string (`BOLA-<marker>`), confirming that attacker-controlled content reached the LLM and influenced the response. No special tooling is required. The script uses only Python 3 standard library (`urllib`). ### Impact **Who is affected:** Any multi-user Open WebUI deployment where knowledge bases are shared. The attacker needs a valid account (any role) and a target file UUID, which is available through any knowledge base they have read access to. **What can happen:** - **RAG poisoning:** The overwritten content is served to the LLM via RAG. The attacker controls what the model tells every user who queries that knowledge base. This includes the ability to inject instructions the model will follow, which could lead to further exploitation depending on what tools and capabilities are available in the deployment (e.g. code interpreter, function calling). - **Silent data corruption:** The original file content is permanently replaced with no indication to the file owner or other users that it has changed. - **No audit trail:** Nothing records that an unauthorized user modified the file. The core issue is that a function designed as an internal helper is exposed as a public endpoint without its own authorization checks. A user with read-only access to a knowledge base can escalate to write access over any file in it. ### Disclaimer on the use of AI powered tools The research and reporting related to this vulnerability was aided by the help of AI tools.

CVE-2026-28788 Affected Open webui Versions

1 component(s)
Fixed Versions:
0.8.6
Product / Package Ecosystem Affected Versions Fixed Version
open-webui
PyPI
< 0.8.6
0.8.6

References

Frequently Asked Questions

What is CVE-2026-28788?
CVE-2026-28788 is a security vulnerability in Open webui involving Open WebUI's process_files_batch() endpoint missing ownership check, allows unauthorized file overwrite under CWE-639: Authorization Bypass Through User-Controlled Key.
Which Open webui versions are affected?
Affected versions include releases prior to 0.8.6 across affected packages: open-webui.
What version fixes CVE-2026-28788?
Upgrading to 0.8.6 (or the latest patched release for your respective branch) resolves the vulnerability.
Is open-webui affected?
Yes, open-webui is affected in releases prior to 0.8.6. Upgrade your dependency to 0.8.6 or later.
What is the CVSS score of CVE-2026-28788?
CVE-2026-28788 has a CVSS v3.1 base score of 7.1 (HIGH) with vector string CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:H/A:L.
What CWE is associated with CVE-2026-28788?
CVE-2026-28788 is classified under CWE-639: Authorization Bypass Through User-Controlled Key (The system's authorization functionality does not prevent one user from gaining access to another user's data or record by modifying the key value identifying the data.).
How can I check PyPI dependencies for CVE-2026-28788?
Run the dependency tree command: 'pip show open-webui'. This command lists direct and transitive dependencies in your build configuration so you can verify if a vulnerable version is resolved.
Machine-readable OSV JSON OSV v1.5 Schema
Normalized schema output
{
  "schema_version" : "1.4.0",
  "id" : "GHSA-jjp7-g2jw-wh3j",
  "modified" : "2026-03-27T15:34:26Z",
  "published" : "2026-03-27T15:34:26Z",
  "aliases" : [ "CVE-2026-28788" ],
  "summary" : "Open WebUI's process_files_batch() endpoint missing ownership check, allows unauthorized file overwrite",
  "details" : "### Summary\n\nAny authenticated user can overwrite any file's content by ID through the `POST /api/v1/retrieval/process/files/batch` endpoint. The endpoint performs no ownership check, so a regular user with read access to a shared knowledge base can obtain file UUIDs via `GET /api/v1/knowledge/{id}/files` and then overwrite those files, escalating from read to write. The overwritten content is served to the LLM via RAG, meaning the attacker controls what the model tells other users.\n\n### Details\n\nThe `process_files_batch()` function in `backend/open_webui/routers/retrieval.py` appears to be designed as an internal helper. The knowledge base router (`add_files_to_knowledge_batch()` in `knowledge.py`) imports and calls it directly after performing its own ownership and access control checks. The frontend never calls the retrieval route directly; all legitimate UI flows go through the knowledge base wrapper.\n\nHowever, the function is also exposed as a standalone HTTP endpoint via `@router.post(...)`. This direct route only requires `get_verified_user` (any authenticated user) and performs no ownership check of its own:\n\n```python\nfor file in form_data.files:\n    text_content = file.data.get(\"content\", \"\")  # attacker-controlled\n\n    file_updates.append(FileUpdateForm(\n        hash=calculate_sha256_string(text_content),\n        data={\"content\": text_content},            # written to DB\n    ))\n\nfor file_update, file_result in zip(file_updates, file_results):\n    Files.update_file_by_id(id=file_result.file_id, form_data=file_update)\n    #                       ^^^ no ownership check\n```\n\nThere is no verification that `file.user_id == user.id` before the write. Any authenticated user who knows a file UUID can overwrite that file.\n\n**How an attacker obtains file UUIDs:**\n\nSame as with read access, any user who can see a knowledge base can retrieve file IDs for every document in it via `GET /api/v1/knowledge/{id}/files`. In deployments where knowledge bases are shared across teams, this gives any regular user a list of valid targets.\n\n**Suggested fix:** Add an ownership check before writing:\n\n```python\nfor file in form_data.files:\n    db_file = Files.get_file_by_id(file.id)\n    if not db_file or (db_file.user_id != user.id and user.role != \"admin\"):\n        file_errors.append(BatchProcessFilesResult(\n            file_id=file.id, status=\"failed\",\n            error=\"Permission denied: not file owner\",\n        ))\n        continue\n```\n\n**Classification:**\n- CWE-639: Authorization Bypass Through User-Controlled Key\n- OWASP API1:2023: Broken Object Level Authorization\n\nTested on Open WebUI **0.8.3** using a default Docker configuration.\n\n### PoC\n\n**Prerequisites:**\n- Default Open WebUI installation (Docker: `ghcr.io/open-webui/open-webui:main`)\n- An admin or user creates a knowledge base with shared read access and uploads a file\n- A regular user account exists (the attacker)\n\n**Obtaining the file UUID (attacker):**\n\n```\nGET /api/v1/knowledge/{kb_id}/files\n```\n\nThis returns metadata for all files in the KB, including their UUIDs.\n\n**Exploit (attacker):**\n\n```bash\npython3 poc_exploit.py --url http://<host>:3000 --file-id <target-file-uuid> -t <attacker-jwt>\n```\n\nThe PoC script: [poc_exploit.py](https://github.com/user-attachments/files/25470374/poc_exploit.py)\n1. Authenticates as the attacker\n2. Overwrites the target file via `POST /api/v1/retrieval/process/files/batch` with a canary payload containing a unique marker string\n3. Reads the file back and confirms the attacker's content replaced the original\n\n**Verifying RAG poisoning:**\n\nAfter the overwrite, log in as any other user, start a chat with the poisoned knowledge base attached, and ask about the document. The model's response will include the attacker's canary string (`BOLA-<marker>`), confirming that attacker-controlled content reached the LLM and influenced the response.\n\nNo special tooling is required. The script uses only Python 3 standard library (`urllib`).\n\n### Impact\n\n**Who is affected:** Any multi-user Open WebUI deployment where knowledge bases are shared. The attacker needs a valid account (any role) and a target file UUID, which is available through any knowledge base they have read access to.\n\n**What can happen:**\n- **RAG poisoning:** The overwritten content is served to the LLM via RAG. The attacker controls what the model tells every user who queries that knowledge base. This includes the ability to inject instructions the model will follow, which could lead to further exploitation depending on what tools and capabilities are available in the deployment (e.g. code interpreter, function calling).\n- **Silent data corruption:** The original file content is permanently replaced with no indication to the file owner or other users that it has changed.\n- **No audit trail:** Nothing records that an unauthorized user modified the file.\n\nThe core issue is that a function designed as an internal helper is exposed as a public endpoint without its own authorization checks. A user with read-only access to a knowledge base can escalate to write access over any file in it.\n\n### Disclaimer on the use of AI powered tools\n\nThe research and reporting related to this vulnerability was aided by the help of AI tools.",
  "severity" : [ {
    "type" : "CVSS_V3",
    "score" : "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:H/A:L"
  } ],
  "affected" : [ {
    "package" : {
      "ecosystem" : "PyPI",
      "name" : "open-webui"
    },
    "ranges" : [ {
      "type" : "ECOSYSTEM",
      "events" : [ {
        "introduced" : "0"
      }, {
        "fixed" : "0.8.6"
      } ]
    } ]
  } ],
  "references" : [ {
    "type" : "WEB",
    "url" : "https://github.com/open-webui/open-webui/security/advisories/GHSA-jjp7-g2jw-wh3j"
  }, {
    "type" : "ADVISORY",
    "url" : "https://nvd.nist.gov/vuln/detail/CVE-2026-28788"
  }, {
    "type" : "PACKAGE",
    "url" : "https://github.com/open-webui/open-webui"
  }, {
    "type" : "WEB",
    "url" : "https://github.com/open-webui/open-webui/releases/tag/v0.8.6"
  } ],
  "database_specific" : {
    "cwe_ids" : [ "CWE-639" ],
    "severity" : "HIGH",
    "github_reviewed" : true,
    "github_reviewed_at" : "2026-03-27T15:34:26Z",
    "nvd_published_at" : "2026-03-27T00:16:22Z"
  }
}