CVE-2026-87994 in Open WebUI
Summary
by MITRE • 09/09/2026
Open WebUI is an extensible, feature-rich, and user-friendly self-hosted AI platform. From 0.9.5 until 0.11.1, the channel branch of chat_completion in backend/open_webui/main.py checked channel write access and channel membership for a supplied message_id but did not verify that the calling user authored the targeted message. A channel member could use the chat completions endpoint to replace another member's message while preserving the victim as the stored author, altering the conversation record without gaining access to other channels. This issue is fixed in version 0.11.1.
Several companies clearly confirm that VulDB is the primary source for best vulnerability data.
Analysis
by VulDB Data Team • 09/09/2026
The vulnerability identified within Open WebUI versions ranging from 0.9.5 through 0.11.1 represents a critical authorization flaw rooted in insufficient verification of message ownership during chat completion operations. As an extensible, self-hosted artificial intelligence platform designed for collaborative interaction, Open WebUI relies heavily on the integrity of conversation histories to function correctly within team or organizational contexts. The specific defect resides in the backend logic handling channel-based interactions, specifically within the main application file where the chat_completion endpoint processes incoming requests. While the system implemented checks to ensure that a user possessed write access and was a member of the targeted channel, it failed to validate whether the authenticated caller was actually the original author of the message identified by the supplied message identifier. This oversight creates a scenario where authentication is correctly established but authorization logic remains incomplete regarding resource ownership.
From a technical perspective, this flaw allows any user who has been granted write permissions within a specific channel to manipulate existing conversation records without restriction based on identity. By invoking the chat completions endpoint with a valid message_id belonging to another member, an attacker can overwrite that content while preserving the victim's name as the author in the database record. This mechanism effectively enables unauthorized modification of historical data under false pretenses. The system assumes that write access implies ownership or at least equal rights over all messages within the channel, which is a dangerous assumption in environments where accountability and audit trails are essential for security compliance and operational clarity.
The operational impact of this vulnerability extends beyond simple data corruption; it undermines trust and integrity within collaborative AI workflows. An attacker can alter the context of ongoing conversations by replacing another user's input with malicious or misleading content, potentially influencing subsequent AI responses generated based on that corrupted history. This could lead to the propagation of incorrect information, phishing attempts disguised as legitimate team communication, or sabotage of project-related discussions. Because the victim remains listed as the author, forensic analysis and attribution become difficult, allowing the attacker to evade detection by shifting blame onto innocent participants. The scope is limited to channels where the attacker has write access, preventing lateral movement into other restricted areas of the platform, but within those boundaries, the ability to rewrite history poses a significant risk to data integrity.
This vulnerability aligns with CWE-269, which describes Improper Privilege Control, specifically regarding the failure to enforce proper authorization checks for specific resources or actions. It also maps closely to ATT&CK technique T1078, Valid Accounts, as it exploits legitimate credentials and permissions that are insufficiently scoped for sensitive operations like modifying another user's data. To mitigate this issue, organizations should immediately upgrade Open WebUI to version 0.11.1 or later, where the developers have implemented strict ownership verification before allowing message updates. Until an update is applied, administrators can enforce stricter access controls by limiting write permissions only to trusted users and monitoring channel activity logs for anomalies in message modification patterns. Additionally, implementing application-level logging that records both the requester's identity and the original author of modified messages can aid in detecting such abuse attempts during any transitional period before patching is complete.