CVE-2026-87997: Open WebUI: Any authenticated user can inject chats into another user's folder via chat completions

The chat-creation branch of the completions handler in backend/open_webui/main.py copies a client-supplied folder id into the chat it saves. It never checks that the caller may write to that folder. The dedicated POST /api/v1/chats/new and chat-move routes do check, and reject the same request with a 404. The ownership and shared-write check was duplicated inline in those two routers, so the third path that sets a folder id inherited none of it.

An attacker posts to POST /api/chat/completions with parent_id null, no chat id and the victim's folder id in the body. The chat lands in the victim's folder. Since 0.10.0, folder listings return chats across all owners so shared folders work, so the owner and every member see an entry under the attacker's display name. The attacker can rename the chat at any time and members can open it and read its messages.

The damage is to integrity: planting misleading or phishing content in a folder a team trusts. The attacker gains no read access to the folder's other chats and cannot change or delete existing ones.

The attacker needs the folder id. A member of a shared folder gets it from the shared-folder listing. A folder that was never shared has an id the attacker cannot obtain through any endpoint, so those folders are not practically reachable. Folders must be enabled, which is the default.

Affected: open-webui from 0.10.0 up to but not including 0.11.1, with folders enabled (ENABLE_FOLDERS and USER_PERMISSIONS_FEATURES_FOLDERS, both default true). Earlier releases contain the same missing check, but the advisory says the injected chat was never visible to anyone there. Check the version:

pip show open-webui

For Docker installs, check the image tag or the version in the Open WebUI About page.

Upgrade to 0.11.1:

pip install --upgrade open-webui==0.11.1

Pull request 28366 moves chat creation, chat moves and the chat-completions creation path onto one has_folder_write_access helper. A folder id the caller cannot write to is now rejected with a 404 everywhere. Members with write access can still create chats in the folder. No configuration change is needed. The sources give no workaround. After upgrading, check shared folders for chats you do not recognise and delete them.

Open each shared folder and look for chats owned by users who should not write there, or with odd titles. Search access logs for POST /api/chat/completions calls whose body carries a folder_id and no chat id, from accounts that are not the folder's owner or a write-enabled member. The advisory lists no other indicators.

Summary

The chat-completions endpoint reads a folder id out of the request body and saves the newly created chat into that folder without checking that the caller is allowed to write there. Any authenticated user who knows a folder's id can put a chat of their own into another user's folder, including a shared folder where they hold read-only access and a folder they have no access to at all. The chat then shows up in that folder for everyone who can read it, under a title and with content the attacker controls. The dedicated chat-creation and chat-move endpoints already enforced this check, the chat-completions path did not.

Preconditions

• An authenticated account of any role. No elevated permission, no admin involvement.
• Folders enabled, which is the default (ENABLE_FOLDERS=true, USER_PERMISSIONS_FEATURES_FOLDERS=true).
• The attacker needs the target folder's id. A member of a shared folder gets it from the shared-folder listing. Sharing a folder with named users is available to ordinary users by default; only wildcard public sharing is gated. A folder that was never shared has an id the attacker cannot obtain through any endpoint available to them, so those folders are not practically reachable.
• Releases before 0.10.0 contain the same missing check but have no read path that lists a folder's chats across owners, so the injected row was never visible to anyone.

Impact

The integrity of folder contents. An attacker who cannot write to a folder can place chats into it, and every member with read access, the owner included, sees the entry with the attacker's display name and a title the attacker can change to arbitrary text at any time. Members can also open the injected chat and read its messages. In a workspace where a shared folder is treated as trusted, that is a usable surface for planting misleading or phishing content under another team's nose.

Nothing is disclosed to the attacker and nothing existing is altered. Writing into a folder grants no read access to it, so the attacker still cannot list or open the folder's other chats, and no data belonging to other users can be modified or deleted through this path. Availability is unaffected.

Fix

Fixed in 0.11.1 by https://github.com/open-webui/open-webui/pull/28366. Chat creation, chat moves and the chat-completions creation path now share a single folder write-access check, so a folder id the caller cannot write to is rejected everywhere a chat's folder can be set. Upgrading to 0.11.1 resolves it completely, with no configuration change required.

Root cause

Affected component: the chat-completions handler in backend/open_webui/main.py, reached through POST /api/chat/completions and POST /api/v1/chat/completions. Affected setup: every deployment on 0.10.0 through 0.11.0 with folders enabled.

The completions handler gained its own chat-creation branch, which copied the client-supplied folder id into the chat it saved. The ownership and shared-write check lived as duplicated inline code inside the two chat routers rather than in one shared helper, so a third place that learned to set a folder id inherited none of it. Separately, folder listings had been changed to return a folder's chats across all owners so that shared folders work at all, which turned a write that used to be invisible to everyone into one the whole folder can see.

Proof of concept

Reproduced on a running instance at 0.11.0 with three accounts: one administrator and two ordinary users, one acting as victim and one as attacker.

1. The victim creates a folder. The attacker is given no access to it: reading the folder returns 404 and listing its chats returns 403.
2. The attacker sends POST /api/v1/chats/new with the victim's folder id. Rejected with 404, which is the pre-existing guard working.
3. The attacker sends POST /api/chat/completions with parent_id: null, no chat id, and the victim's folder id in the body. Accepted.
4. The victim lists their own folder and sees a chat owned by "Attacker". The victim can open it and read its messages. The attacker then renames their own chat and the new title appears verbatim in the victim's folder listing.

Repeating step 3 with the attacker granted read-only access to a shared folder also succeeds on 0.11.0. On 0.11.1 both variants are rejected with 404 and the folder stays empty, while a member holding write access can still create chats there as intended.

The three accounts and the folder were created through the normal API. Nothing was written directly to the database.

Credits

whyiug, for reporting the missing folder write-access check on the chat-completions creation path.