CVE-2024-7040
| CVE ID | CVE-2024-7040 |
| 厂商处理 | 已拒绝 — 超出范围 |
| 发布时间 | 2025-10-15 |
| 发布 CNA | huntr.dev |
| 声称严重性 | 中（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（通过用户控制的密钥进行授权绕过） |
CVE 声称内容
在 Open WebUI v0.3.8 中，管理员可以通过操纵 admin 门禁聊天列表端点（/api/v1/chats/list/user/{user_id}）上的 user_id 参数来访问另一个管理员的聊天历史。前端 UI 通常仅向非管理员账户公开列表，但后端不执行目标角色检查，因此替换另一个管理员的 user_id 的管理员可以读取该其他管理员的聊天。
为什么这超出了范围
报告中的请求方和目标方都是同一个 Open WebUI 实例的管理员。引用的端点由 Depends(get_admin_user) 进行门禁 — 仅管理员可以调用它。该端点上唯一有文档的授权边界是成立的：它需要管理员权限，双方都有。
管理员共享信任边界
管理员可以安装任何工具或函数 — 它们在服务器上执行任意 Python 并可以直接读取或修改数据库 — 并可以修改任何其他用户，包括其他管理员（例如重置密码）。他们通常还可以在部署层上直接访问服务器和数据库。
即使该特定列表端点受到限制，管理员仍然可以通过以下任何等效路径访问另一个管理员的聊天：
- 重置其他管理员的密码并以他们身份登录
- 安装具有几行代码的工具或函数，直接读取聊天表
- 在服务器级别访问 SQLite/PostgreSQL 数据库文件
- 使用备份/导出功能
- 读取
WEBUI_SECRET_KEY并为其他管理员伪造 JWT
仅修复列表端点将关闭最方便的路径，同时留下半打等效的开放。硬性实施管理员之间的数据边界没有意义，因为管理员仍然可以重置彼此的密码 — 一个合法且必要的功能用于账户恢复和运营连续性 — 并有多个其他路径到相同数据。结果将是虚假的安全感，而不是实际隔离。管理员之间的共享访问是 Open WebUI 的基于角色的访问控制架构中的预期和意图行为，而不是要修补的差距。
前端行为是用户体验，而不是安全边界
报告将前端隐藏管理员账户的聊天列表的决定解释为隐私边界的证据。这是误读。前端为相同的原 因隐藏其他管理员的聊天，任何多用户 UI 隐藏无关内容：避免界面混乱。在具有多个管理员的实例中，默认显示每个其他管理员的聊天将是噪声。这是用户体验便利决定，而不是安全声明 — 后端从未在该端点上执行或记录管理员间访问边界。
CWE 不匹配
发布的 CWE-639（通过用户控制的密钥进行授权绕过）不适用。没有授权被绕过 — 端点的唯一访问控制是 Depends(get_admin_user)，且对于请求方和目标方都通过了该检查。报告描述的不是绕过现有控制，而是应该存在但从未存在过的控制的期望。期望不匹配不是 CWE-639。
适用的安全政策规则
- 规则 9： 管理员拥有完整的系统控制权，应理解其操作和配置的安全含义。同一实例内的管理员共享单一信任边界。
- 规则 7： 报告未承认项目自托管、多管理员架构，其中管理员在基础设施级别共享信任。
- 规则 13： 问题不跨越与报告者自身同一信任边界内的对等管理员以外的一方的安全边界。
对用户的影响
无需行动。 如果您的部署有多个管理员，请意识到管理员共享信任边界并可以访问彼此的数据 — 这是管理员角色固有的，与可比的自托管应用程序（Linux root、Kubernetes cluster-admins、PostgreSQL superusers）如何处理共享行政访问一致。
推荐做法
我们建议将管理员账户视为仅配置账户 — 类似于服务账户。使用专用电子邮件地址或用户名创建管理员账户，并将其专用于管理任务（管理设置、用户、工具、函数等）。对于日常使用（聊天、创建知识库等），创建单独的常规用户账户。
这种分离将您的个人对话保持在管理员门禁 UI 端点（如本 CVE 中引用的那个）之外。请注意，这是一个组织最佳实践，而不是硬安全边界 — 具有服务器或数据库访问权限或能够安装工具和函数的管理员仍然可以访问实例上的任何数据，如果他们选择这样做。
也就是说，这只是一项建议 — 使用模式有所不同。如果您更喜欢在管理员账户中工作，那完全没问题。只需意识到其他管理员可以像他们应该能够的那样重置账户、通过工具和函数安装和执行代码，因此也可以访问您的聊天。这是管理员角色的共享信任边界固有的。