Open WebUI
cpe:2.3:a:openwebui:open_webui:*:*:*:*:*:*:*
- < 0.6.19
A vulnerability exists in Open WebUI versions prior to 0.6.19, where inconsistent authorization controls in the memories API allow standard users to delete, restore, and access the contents of other users' memories. A non-admin user can exploit this by querying memories through the POST /api/v1/memories/query endpoint, even without having any memories of their own. Additionally, while non-admin users cannot directly modify another user's memory via the POST /api/v1/memories/{memory_id}/update endpoint, the response from this endpoint improperly discloses the content of the memory if the memory_id is known. Furthermore, the DELETE /api/v1/memories/{memory_id} endpoint can be used by any user to delete a memory, which can then be restored by using the POST /api/v1/memories/{memory_id}/update endpoint.
Exploitation of this vulnerability could lead to unauthorized access and modification of memory data, allowing users to view, delete, and restore memories that do not belong to them.
To reproduce this vulnerability, create a new non-admin user with no existing memories. First, verify that the user cannot access any memories by calling the GET /api/v1/memories/ endpoint, which should return an empty array. Then, use the POST /api/v1/memories/query endpoint to query memories, which will return memories created by other users, demonstrating unauthorized access. Next, attempt to modify a memory belonging to another user using the POST /api/v1/memories/{memory_id}/update endpoint. The response will leak the content of the memory, showing that the memory data can be accessed without permission. Finally, delete a memory using the DELETE /api/v1/memories/{memory_id} endpoint. After deletion, the memory can be restored by calling the POST /api/v1/memories/{memory_id}/update endpoint again, illustrating the ability to manipulate memory data across different users.
Users are advised to update Open WebUI to version 0.6.19 or later, where this vulnerability has been fixed.
Our algorithm analyzes dozens of metrics to generate these 8 key vulnerability categories, which are then combined to calculate the overall risk score.