--- id: "CVE-2026-109285" page: "https://infrastack.ai/live/CVE-2026-109285" kind: "vulnerability" aliases: ["CVE-2026-109285", "GHSA-9cxp-636w-4997"] title: "Knowledge base collaborators keep read and delete access to removed files via stale file metadata" severity: "medium" cvss: 5.0 epss: null exploited: false status: "open" category: "ai-tooling" products: [{"name": "open-webui", "fixed": ["0.11.4"], "affected": ">= 0.6.0, < 0.11.4", "ecosystem": "pypi"}] ecosystems: ["pypi"] tags: ["ai-tooling", "cwe-863", "open-webui", "python", "self-hosted"] not_affected_if: ["auth-required", "no-shared-knowledge-bases", "version-outside-range"] published_at: "2026-09-27T19:25:50+00:00" first_seen_at: "2026-11-09T22:53:28+00:00" updated_at: "2026-11-09T23:01:13+00:00" sources: [{"source": "ghsa-repo", "url": "https://github.com/open-webui/open-webui/security/advisories/GHSA-9cxp-636w-4997", "first_seen_at": "2026-11-09T22:53:28+00:00"}, {"source": "nvd", "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-109285", "first_seen_at": "2026-11-09T23:10:12+00:00"}] exploit_sources: [] --- # Knowledge base collaborators keep read and delete access to removed files via stale file metadata Link for people: https://infrastack.ai/live/CVE-2026-109285 (this .md is for agents) Open WebUI keeps a stale knowledge base reference on a file after it is removed from a shared knowledge base, so former collaborators can still download the file. A collaborator with a write grant can also delete it, including from the owner's private knowledge bases. _Summary, check and fix written by a model from the sources; labelled as such._ ## Affected - pypi:open-webui affected >= 0.6.0, < 0.11.4 fixed 0.11.4 ## How to check - Check the installed version with `pip show open-webui` or the image tag; affected builds are `0.6.0` up to but not including `0.11.4`. - Review which users hold read or write grants on shared knowledge bases, since only former collaborators can exploit this. ## Fix - `open-webui` `0.11.4` ## Timeline - 2026-11-09T22:53:28+00:00 ghsa-repo https://github.com/open-webui/open-webui/security/advisories/GHSA-9cxp-636w-4997 - 2026-11-09T23:10:12+00:00 nvd https://nvd.nist.gov/vuln/detail/CVE-2026-109285 ## Documents - [advisory] Maintainer's advisory: github.com https://github.com/open-webui/open-webui/security/advisories/GHSA-9cxp-636w-4997 - [advisory] Third-party advisory: www.vulncheck.com https://www.vulncheck.com/advisories/open-webui-0.6.0-before-0.11.4-improper-access-control-via-stale-file-metadata ## From the sources # Knowledge base collaborators keep read and delete access to removed files via stale file metadata ## Summary A user who has been granted access to a shared knowledge base keeps access to a file after the owner removes that file from the knowledge base. With a read grant they can still download the file, and with a write grant they can delete it for everyone, including from other private knowledge bases of the owner that they cannot open. The file access check trusted a knowledge base reference cached on the file record and never confirmed that the file is still attached to that knowledge base. ## Preconditions - Default configuration. No setting needs to be changed. - The attacker is an ordinary user who holds a read grant (to read) or a write grant (to delete) on a knowledge base owned by the victim. - The file was last processed into that shared knowledge base. If it was processed into another knowledge base afterwards, the cached reference points elsewhere and the issue does not occur. - The owner removes the file from the shared knowledge base in a way that keeps the file on the instance: the knowledge base sync cleanup when the file is still attached to another knowledge base, or, up to 0.11.0, resetting the knowledge base. - The attacker knows the file id, which they could see while the file was still shared with them. ## Impact After the file has been removed from the shared knowledge base, the former collaborator can still download its content and, with a write grant, delete it. Deletion removes the file from every knowledge base that still references it, including the owner's private ones that the attacker never had access to. Exploitation depends on the owner's own actions (processing order and how the file was removed), so an attacker cannot force it. Files that were never shared through a knowledge base, and knowledge bases the attacker was never granted, are not affected. ## Fix Fixed in PR #29937. Knowledge base access to a file is now derived only from the file's current knowledge base associations, and the cached reference on the file record is no longer consulted. Upgrading is sufficient. ## Root cause - Component: `has_access_to_file` in `backend/open_webui/utils/access_control/files.py` (in `backend/open_webui/routers/files.py` before 0.8.6), used by the file content, update, rename and delete endpoints. - Affected setup: every build from 0.6.0 to 0.11.3. When a file is processed into a knowledge base, the id of that knowledge base is stored in the file's metadata. The access check granted access to anyone with the matching permission on the knowledge base named there, but it never checked that the file was still attached to it. Removing a file from a knowledge base does not clear that value, so the old knowledge base's grants kept applying to the file after it had been removed. ## Proof of concept 1. As the owner, create private knowledge bases B and A and upload a text file containing a unique marker. 2. Add the file to B and let it process, then add it to A and let it process. 3. Grant the attacker read and write on A with `POST /api/v1/knowledge/{A}/access/update`. 4. As the owner, remove the file from A with `POST /api/v1/knowledge/{A}/sync/cleanup` and `{"file_ids":["FILE_ID"],"dir_ids":[]}`. The file remains in B, and the attacker cannot open B. 5. As the attacker, `GET /api/v1/files/FILE_ID/content` returns 200 with the marker. 6. As the attacker, `DELETE /api/v1/files/FILE_ID` returns 200, and the file is removed from B. 7. Control: with processing order A then B, both requests return 404. The reporter reproduced this over HTTP on a running instance. It was independently reproduced on 0.11.3 (sync cleanup) and on 0.6.0 and 0.11.0 (knowledge base reset) against the real routers, with the users, knowledge bases, grants and the cached processing reference seeded directly into the database. On 0.11.4 both requests return 404. ## Credits @torjan0 reported the issue and the proof of concept. --- _Free to read, with fair use of about 60 pages a minute. For higher limits or API access: sales@infrastack.ai_