--- id: "CVE-2026-109284" page: "https://infrastack.ai/live/CVE-2026-109284" kind: "vulnerability" aliases: ["CVE-2026-109284", "GHSA-6fjc-5cg3-mgvh"] title: "Read-only shared folder members can still add chats to the folder by forking" severity: "medium" cvss: 5.3 epss: null exploited: false status: "open" category: "ai-tooling" products: [{"name": "open-webui", "fixed": ["0.11.4"], "affected": ">= 0.11.0, < 0.11.4", "ecosystem": "pypi"}] ecosystems: ["pypi"] tags: ["ai-tooling", "cwe-862", "open-webui", "python", "self-hosted"] not_affected_if: ["folders-disabled", "no-shared-write-folders", "version-0.11.4-or-later"] published_at: "2026-09-27T16:42:03+00:00" first_seen_at: "2026-11-09T22:53:28+00:00" updated_at: "2026-11-09T23:10:12+00:00" sources: [{"source": "ghsa-repo", "url": "https://github.com/open-webui/open-webui/security/advisories/GHSA-6fjc-5cg3-mgvh", "first_seen_at": "2026-11-09T22:53:28+00:00"}, {"source": "nvd", "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-109284", "first_seen_at": "2026-11-09T23:10:12+00:00"}] exploit_sources: [] --- # Read-only shared folder members can still add chats to the folder by forking Link for people: https://infrastack.ai/live/CVE-2026-109284 (this .md is for agents) Open WebUI lets a shared-folder member keep adding chats after their write access was revoked, by forking a chat they created earlier. The forked chat lands in the shared folder where the owner and other members see it, with content the attacker controls. _Summary, check and fix written by a model from the sources; labelled as such._ ## Affected - pypi:open-webui affected >= 0.11.0, < 0.11.4 fixed 0.11.4 ## How to check - Check the installed version: `pip show open-webui` or the image tag; affected versions are `0.11.0` through `0.11.3`. - Check whether folders are enabled: `ENABLE_FOLDERS` is `true` (the default). - Check whether shared folders exist where a member was downgraded from write to read access. ## Fix - Open WebUI (pypi `open-webui`): upgrade to `0.11.4`. ## Timeline - 2026-11-09T22:53:28+00:00 ghsa-repo https://github.com/open-webui/open-webui/security/advisories/GHSA-6fjc-5cg3-mgvh - 2026-11-09T23:10:12+00:00 nvd https://nvd.nist.gov/vuln/detail/CVE-2026-109284 ## Documents - [advisory] Maintainer's advisory: github.com https://github.com/open-webui/open-webui/security/advisories/GHSA-6fjc-5cg3-mgvh - [advisory] Third-party advisory: www.vulncheck.com https://www.vulncheck.com/advisories/open-webui-0.11.0-before-0.11.4-improper-authorization-via-chat-fork-endpoint ## From the sources # Read-only shared folder members can still add chats to the folder by forking ## Summary A member of a shared folder who once had write access and was later downgraded to read-only could keep adding new chats to that folder. Forking a chat they had created in the folder while they could still write produced a new chat inside the same folder, without checking whether they could still write there. The new chat then appears to everyone who can read the folder. Direct chat creation, chat moves and chat completions already enforced folder write access; the fork action did not. ## Preconditions - An authenticated account of any role that was given write access to a shared folder and later downgraded to read-only by the folder owner. - The member created at least one chat in that folder while they still had write access. - Folders enabled, which is the default (`ENABLE_FOLDERS=true`, `USER_PERMISSIONS_FEATURES_FOLDERS=true`), and the chat import permission, which forking requires and which ordinary users hold by default (`USER_PERMISSIONS_CHAT_IMPORT=true`). - Folders that were never shared with write access, and members who never had write access, are not affected. ## Impact The integrity of shared folder contents. Revoking a member's write access did not stop them from adding entries: using the chat they created earlier, they could fork it any number of times, and each fork shows up in the shared folder for the owner and every other member, under a title and with content the attacker controls. The owner has no signal that the downgrade was ineffective. Nothing is disclosed to the attacker and nothing belonging to other users is changed or deleted. Availability is unaffected. ## Fix Fixed in 0.11.4 by https://github.com/open-webui/open-webui/pull/30069. A fork now keeps the source chat's folder only when the caller still has write access to it and is otherwise created outside any folder, matching chat creation and chat moves. Upgrading to 0.11.4 resolves it completely, with no configuration change required. ## Root cause Affected component: the chat fork handler in `backend/open_webui/routers/chats.py`, reached through `POST /api/v1/chats/{id}/fork`. Affected setup: every deployment on 0.11.0 through 0.11.3 with folders enabled. The fork action was added in 0.11.0 and built the new chat by copying the folder of the source chat. Because the source chat belongs to the caller, the handler treated its folder as already authorized, but write access to a shared folder can be revoked after the chat was placed there. When the folder write check was consolidated into one shared helper for the other chat creation paths in 0.11.1, the fork path was not routed through it. ## Proof of concept Reproduced on running 0.11.3 and 0.11.4 instances with two accounts: an administrator acting as folder owner and an ordinary user acting as attacker. 1. The owner creates a folder and grants the attacker write access through `POST /api/v1/folders/{id}/access/update`. 2. The attacker creates a chat in that folder with `POST /api/v1/chats/new`. 3. The owner downgrades the attacker to read access. A direct `POST /api/v1/chats/new` into the folder is now rejected. 4. The attacker calls `POST /api/v1/chats/{chat_id}/fork` on the chat from step 2. 5. On 0.11.3 the fork is created with the shared folder's id and is listed by `GET /api/v1/folders/{id}/shared/chats` for both the attacker (`folder_permission: read`) and the owner. On 0.11.4 the fork is created outside any folder and does not appear in the listing. ## Credits - @avrlab233 (reporter) --- _Free to read, with fair use of about 60 pages a minute. For higher limits or API access: sales@infrastack.ai_