CVE-2026-109284 in Open WebUI
Summary
by MITRE • 10/12/2026
Open WebUI from 0.11.0 before 0.11.4 contains an improper authorization vulnerability in the chat fork handler, which places forked chats in the source chat's folder without checking folder write access. Shared folder members downgraded to read-only can call POST /api/v1/chats/{id}/fork on chats they created there while they had write access, inserting attacker-controlled chats visible to the folder owner and members.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 10/12/2026
The vulnerability identified in Open WebUI versions prior to 0.11.4 represents a critical failure in authorization logic within the chat fork handler mechanism. This flaw allows for improper privilege escalation by bypassing standard access control checks that are typically enforced during file system operations or resource management tasks. Specifically, when a user initiates a fork operation on an existing conversation, the application creates a new chat entry and places it into the same directory structure as the source chat. The core technical deficiency lies in the fact that this process does not verify whether the requesting user possesses write permissions for the target folder at the time of execution. This oversight assumes that historical access rights are sufficient or ignores current state changes, leading to a classic authorization bypass scenario where actions permitted under one set of credentials remain executable after those privileges have been revoked or downgraded.
From an operational perspective, this vulnerability enables shared folder members who were previously granted write access but later downgraded to read-only status to execute unauthorized modifications. An attacker can leverage the POST /api/v1/chats/{id}/fork endpoint to inject maliciously crafted chat entries into folders they no longer have permission to modify. These injected chats become visible not only to the original folder owner but also to other members of the shared workspace, effectively breaching the confidentiality and integrity boundaries established by the application's sharing model. This behavior undermines the trust model of collaborative environments where access levels are dynamically adjusted based on user roles or project phases, allowing a restricted user to pollute the data space with content that may contain phishing links, social engineering payloads, or simply disruptive noise intended to degrade service quality for other participants.
In terms of industry standard classifications, this vulnerability aligns closely with CWE-269 Improper Privilege Escalation and CWE-862 Missing Authorization. The specific mechanism of exploiting a state change in user permissions without re-validating access rights is characteristic of authorization logic errors often found in web applications that manage hierarchical resources like folders or directories. Furthermore, the exploitation technique maps to MITRE ATT&CK techniques related to Initial Access and Persistence if the forked chats are used as vectors for further compromise, such as storing malicious scripts or links that other users might interact with upon viewing their chat history. The attack vector is primarily remote via API interaction, requiring only authenticated access at a previous point in time, which lowers the barrier for exploitation significantly compared to vulnerabilities requiring unauthenticated network access.
Mitigation strategies must focus on enforcing strict state-based authorization checks during all write operations involving shared resources. Developers should implement immediate re-validation of folder write permissions every time a fork or similar modification request is processed, ensuring that current privileges match the requirements of the action rather than relying on historical context. Additionally, implementing role-based access control (RBAC) with granular permission auditing can help detect and prevent such anomalies before they result in data integrity issues. For users currently running affected versions, upgrading to version 0.11.4 or later is essential as it addresses this logic flaw by correcting the authorization checks within the chat fork handler. Until an upgrade is performed, administrators should monitor API logs for unusual patterns of fork requests from downgraded accounts and consider restricting direct API access where possible to reduce the attack surface.