OPEN-WEBUI · CVE-2026-109285 · AI agents & MCP
FIX → 0.11.4
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.
first public Sep 27, 2026 · 2 sources
Could this affect your app?
Free first check from your website. Connect your repo for the full answer.
Teams that run a self-hosted Open WebUI instance with shared knowledge bases are exposed, because the flaw depends on a file that was once shared and later removed while staying on the instance. Instances that do not share knowledge bases between users, or that run a build outside 0.6.0 to 0.11.3, are not affected. The sources say the bug needs an ordinary user account with a grant, and that the owner's actions trigger it.
Not affected if auth-required, no-shared-knowledge-bases, version-outside-range
Who cares open-webui, python, self-hosted
pip show open-webui or the image tag; affected builds are 0.6.0 up to but not including 0.11.4.Upgrade to 0.11.4
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.
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.
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.
Check it with your coding agent
It reads this page and tells you if your code is affected.
Are you affected?
Ask from here. InfraStack checks the affected versions against your stack and answers in your inbox.
InfraStack checks the affected versions against your stack and answers in Slack, with the evidence and the fix.
open-webui 0.11.4has_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.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.
POST /api/v1/knowledge/{A}/access/update.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.GET /api/v1/files/FILE_ID/content returns 200 with the marker.DELETE /api/v1/files/FILE_ID returns 200, and the file is removed from B.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.
@torjan0 reported the issue and the proof of concept.
This page as .md · .json · CVSS:4.0/AV:N/AC:L/AT:P/PR:L/UI:N/VC:L/VI:L/VA:L/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X
NVD data is provided by NIST and is public domain. Posts quoted belong to their authors.