Open WebUI EUVD-2026-97586

Exploitation requires an authenticated Open WebUI account that is (or was) a member of a shared folder, a non-default collaborative/multi-member folder configuration, and the specific stateful precondition that the attacker created one or more chats in that folder while holding write access and was subsequently downgraded to read-only. The attacker then issues POST /api/v1/chats/{id}/fork against one of those self-created chats. Limiting factors: valid authentication is mandatory (PR:L), the shared-folder collaboration feature must be in use, the attacker must own eligible forkable chats in the target folder, and impact is confined to inserting visible chat content (integrity) - no data disclosure or service disruption. This affects Open WebUI versions 0.11.0 up to but not including 0.11.4.

This is a genuine but modest-severity authorization flaw, not a high-priority emergency. The CVSS 4.0 base score of 5.3 (AV:N/AC:L/AT:N/PR:L/UI:N) reflects network-reachable, low-complexity exploitation, but PR:L confirms an authenticated account is required and the impact is limited to integrity (VI:L) with no confidentiality (VC:N) or availability (VA:N) effect - the attacker can only inject attacker-controlled chats into a shared folder, not read others' data or disrupt service. No EPSS score, SSVC decision, or KEV entry was provided, and no POC was referenced, so exploitation status is 'no public exploit identified at time of analysis.' The exploitation path is also narrow and stateful: the attacker must be a prior write-capable member of a shared folder who was later downgraded to read-only. The input tag 'Authentication Bypass' overstates the issue - CWE-862 (Missing Authorization) and the description describe a missing folder write-access check, i.e. improper authorization within an authenticated session, not an authentication bypass; treat the risk as a collaboration-integrity/trust issue rather than a system compromise.

A user who was granted write access to a shared Open WebUI folder creates several chats there, then is downgraded to read-only by the folder owner. Because the chat fork handler never re-checks folder write permission, the downgraded user calls POST /api/v1/chats/{id}/fork on one of their chats and silently inserts an attacker-controlled forked chat into the folder, where it appears to the owner and other members. No public exploit code is referenced, but the attack is a single authenticated API call.