CVE-2024-7040
| 评估指标 | 官方评估与明细 |
|---|---|
| CVE 编号 | CVE-2024-7040 |
| 官方处理声明 (Vendor Disposition) | 已驳回 (Rejected) —— 超出规范范畴 (Out of Scope) |
| 披露日期 | 2025-10-15 |
| 下发机构 (CNA) | huntr.dev |
| 宣称的严重等级 | 中危 (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（越权绕过：通过操纵用户控制的 Key 绕过授权） |
CVE 指控的具体内容
在 Open WebUI v0.3.8 版本中，系统管理员可以通过在受管理员权限保护的聊天列表接口（/api/v1/chats/list/user/{user_id}）上篡改 user_id 参数，进而查看另一个管理员的聊天历史记录。指控人声称，虽然前端界面通常只公开展示普通用户的聊天列表给管理员，但后端并没有在接口上执行针对目标账户角色的防越权校验，因而只要将参数替换为另一个管理员的 user_id，就能实现对其他管理员聊天历史的读取。
为什么此项报告超出安全规范范畴
在此份漏洞报告中，无论是漏洞的发起方（发起接口请求的用户）还是受害方（被读取数据的用户），其账户类型都是同一个 Open WebUI 部署实例中的“管理员（Administrator）”。被指控的 API 接口是由 Depends(get_admin_user) 进行拦截保护的 —— 仅且只有管理员身份的账号才有权发起请求。对于该接口，系统设计并记录在案的唯一授权防线为：它要求发起人必须具备管理员权限，而在该指控场景下，双方都持有该项特权。
多个管理员共享相同的信任边界
同一个 Open WebUI 实例中的管理员共享同一个最高信任边界。管理员可以安装任何 Tools（工具）或 Functions（函数）插件 —— 这些插件会在服务器底层直接执行未经验证的任意 Python 代码，并能直接读取或改写底层的数据库文件；同时管理员还可以任意编辑任何其他用户账号，包含直接强制重置其他管理员的登录密码。并且，管理员通常在部署环境层面上也直接掌握着宿主机服务器和数据库的读写控制权。
即使我们在此接口上强行设卡，禁止管理员互相读取列表，任何管理员依然可以通过以下等效途径极其轻松地获取另一个管理员的聊天记录：
- 直接重置另 一名管理员的账号密码，随后以该管理员的身份进行登录。
- 在后台上传并部署一段几行代码的 Tools 或 Functions 插件，从代码层面上直接读取数据库的聊天历史数据表。
- 在宿主机物理层面上直接读取并打开 SQLite/PostgreSQL 数据库文件。
- 直接调用系统内置的“备份与导出（Backup & Export）”功能。
- 直接读取系统配置文件中的
WEBUI_SECRET_KEY变量，为另一名管理员凭空伪造一个合法的 JWT 鉴权鉴权 Token。
如果仅仅修改这个列表接口，就相当于在关闭最显眼的阳关道的同时，把另外半打性质完全等同的独木桥敞开在那里，这毫无安全逻辑。在多名管理员随时有权互相重置彼此密码（此为保障账号找回以及日常运维所必需的核心合法功能）、且拥有诸多其他手段读取底层数据的情况下，在接口层面上强行划定所谓的“管理员间的隐私防线”只会制造虚假的安全防范幻觉，并不带来任何实际的物理隔离。多名管理员之间的相互访问特权是 Open WebUI 系统 RBAC 角色权限模型中完全符合设计预期的正常行为，而非系统安全漏洞。
前端隐藏行为属于 UX 体验设计，而非安全屏障
该漏洞报告误将前端界面“对管理员账号隐藏其他管理员聊天列表”的设计决定，判定为系统存在“隐私隔离防线”的佐证。这是一种明显的误读。前端之所以默认对其他管理员的聊天记录进行隐藏，与任何多用 户系统隐藏非必要信息的初衷完全一致：为了避免界面信息过载。在一个存在多名管理员的系统实例中，如果默认在屏幕上展示所有管理员的个人对话历史，会制造巨大的视觉噪音。这纯粹是为了提升用户交互体验（UX）的易用性决定，而不是安全声明 —— 后端在设计该接口之初，从未宣称或在文档中承诺过要在多名管理员账号间确立任何越权防线。
滥用的 CWE 漏洞类型不匹配
下发的 CWE-639（越权绕过：通过操纵用户控制的 Key 绕过授权）与事实完全不符。该系统接口上根本不存在任何被绕过的授权防线 —— 接口设定的唯一防线是 Depends(get_admin_user)，而请求的发起方和受害方均已成功通过了这一管理员身份校验。该报告描述的情况，并不是对既有防御机制的突破，而纯粹是提报人主观上臆想出了一套系统从未设计过的防线。主观臆想防线与真实设计不符，绝不属于 CWE-639 的范畴。
适用的安全策略条款
- 安全策略第 9 条：管理员在系统中拥有最高掌控权，应当理解并对其发起的每一项配置与操作的安全后果负责。同一个实例内的多名管理员共享同一个最高信任边界。
- 安全策略第 7 条：该漏洞报告完全无视了本系统作为“自托管、多管理员协同”的软件架构，在这种架构下，管理员在底层的技术基础设施层面上共享全部信任。
- 安全策略第 12 条：该事件并未突破任何安全屏障去侵害提报人及其管理员同僚之外的任何第三方。
对部署用户的实际影响
部署人员无需采取任何操作。 如果您的实例中分配了多名管理员账号，请知悉，所有的管理员均共享最高信任边界并能调取彼此的数据 —— 这完全符合系统对管理员角色的职能定位，也与全球通行的其他同类自托管系统（如 Linux 系统的 root 权限、Kubernetes 的 cluster-admin 集群管理员、PostgreSQL 数据库的 superuser 超级用户）在处理共享管理员权限时的逻辑完全一致。
官方推荐的最佳实践
我们强烈建议您将管理员（Admin）账户视作仅用于配置的系统特权账号 —— 类似于运维服务账号。请使用一个专属的邮箱或用户名创建您的管理员账号，并仅在需要执行系统级维护任务（如调整系统变量、管理普通用户、上传部署 Tools 与 Functions 等）时才登录该账号。而在您日常使用系统（如与大模型对话、上传自己的知识库 文件等）时，请另外注册并登录一个普通用户账号。
这一主备账号分离的日常使用模式，可以让您的个人私密对话完美避开类似于本 CVE 中提到的各类管理员专属接口。需要说明的是，这属于企业组织管理上的推荐操作规范，并非技术层面的强行安全物理隔离 —— 因为任何管理员如果掌握了宿主机服务器和数据库读写权、或具备上传部署 Tools 与 Functions 的能力，只要他们执意调取，依然可以穿透拿到系统中的任何聊天数据。这完全是由管理员特权这一职能的物理边界所决定的。
尽管如此，这仅仅是对于生产环境的推荐习惯 —— 具体的业务使用因人而异。如果您依然倾向于在管理员账号内直接进行日常对话，这也是完全可行且安全的。您只需知悉并信任您的其他管理员同僚同样拥有重置账号、通过 Tools/Functions 上传并运行代码，以及间接调取您聊天历史的固有合法维护权限。这属于管理员特权边界内的应有之义。