CVE-2024-7040
| CVE ID | CVE-2024-7040 |
| Vendor Disposition | Rejected — out of scope |
| Published | 2025-10-15 |
| Issuing CNA | huntr.dev |
| Claimed Severity | Medium (CVSS 4.9 — CVSS:3.0/AV:N/AC:L/PR:H/UI:N/S:U/C:H/I:N/A:N) |
| CWE | CWE-639 (Authorization Bypass Through User-Controlled Key) |
What the CVE Claims
In Open WebUI v0.3.8, an administrator can access the chat history of another administrator by manipulating the user_id parameter on an admin-gated chat-listing endpoint (/api/v1/chats/list/user/{user_id}). The frontend UI ordinarily exposes the listing only for non-admin accounts, but the back-end does not enforce a target-role check, so an admin who substitutes another admin's user_id can read that other admin's chats.
Why This Is Out of Scope
Both the requesting party and the targeted party in this report are administrators of the same Open WebUI instance. The cited endpoint is gated by Depends(get_admin_user) — only administrators can call it. The only documented authorization boundary on this endpoint holds: it requires admin privileges, and both parties have them.
Administrators Share a Trust Boundary
Administrators can install any Tool or Function — which execute arbitrary Python on the server and can read or modify the database directly — and can modify any other user, including other administrators (e.g. resetting passwords). They typically also have direct server and database access at the deployment layer.
Even if this specific listing endpoint were restricted, an administrator could still access another administrator's chats through any of these equivalent paths:
- Resetting the other administrator's password and logging in as them
- Installing a Tool or Function with a few lines of code that reads the chat table directly
- Accessing the SQLite/PostgreSQL database file at the server level
- Using the backup/export functionality
- Reading the
WEBUI_SECRET_KEYand forging a JWT for the other administrator
Fixing the listing endpoint alone would close the most convenient path while leaving half a dozen equivalent ones open. Hard-enforcing inter-admin data boundaries makes little sense when administrators can still reset each other's passwords — a legitimate and necessary feature for account recovery and operational continuity — and have multiple other paths to the same data. The result would be a false sense of security, not actual isolation. Shared access between administrators is expected and intended behavior in Open WebUI's RBAC architecture, not a gap to be patched.
Frontend Behavior Is UX, Not a Security Boundary
The report interprets the frontend's decision to hide the chat listing for admin accounts as evidence of a privacy boundary. This is a misreading. The frontend hides other administrators' chats for the same reason any multi-user UI hides irrelevant content: to avoid cluttering the interface. In an instance with multiple administrators, showing every other admin's chats by default would be noise. This is a UX convenience decision, not a security assertion — the backend has never enforced or documented an inter-admin access boundary on this endpoint.
CWE Mismatch
The published CWE-639 (Authorization Bypass Through User-Controlled Key) does not apply. There is no authorization being bypassed — the endpoint's only access control is Depends(get_admin_user), and that check passes for both the requesting and the targeted party. What the report describes is not a bypass of an existing control, but an expectation that a control should exist that never did. Expectation mismatch is not CWE-639.
Applicable Security Policy Rules
- Rule 9: Admins have full system control and are expected to understand the security implications of their actions and configurations. Administrators within the same instance share a single trust boundary.
- Rule 7: The report does not acknowledge the project's self-hosted, multi-administrator architecture in which administrators share trust at the infrastructure level.
- Rule 12: The issue crosses no security boundary against a party other than the reporter's own peer administrators within the same trust boundary.
Impact to Users
No action required. If your deployment has multiple administrators, be aware that administrators share a trust boundary and can access each other's data — this is inherent to the administrator role, consistent with how comparable self-hosted applications (Linux root, Kubernetes cluster-admins, PostgreSQL superusers) handle shared administrative access.
Recommended Practice
We recommend treating admin accounts as configuration-only accounts — similar to service accounts. Create your admin account with a dedicated email address or username, and use it exclusively for administrative tasks (managing settings, users, Tools, Functions, etc.). For day-to-day usage (chatting, creating knowledge bases, etc.), create a separate regular user account.
This separation keeps your personal conversations out of admin-gated UI endpoints like the one cited in this CVE. Note that this is an organizational best practice, not a hard security boundary — administrators with server or database access, or the ability to install Tools and Functions, can still reach any data on the instance if they choose to.
That said, this is only a recommendation — usage patterns differ. If you prefer to work within your admin account, that is perfectly fine. Just be aware that other administrators can, as they should be able to, reset accounts, install and execute code via Tools and Functions, and therefore also access your chats. This is inherent to the shared trust boundary of the administrator role.