CVE-2026-0765
| 评估指标 | 官方评估与明细 |
|---|---|
| CVE 编号 | CVE-2026-0765 |
| 官方处理声明 (Vendor Disposition) | 已驳回 (Rejected) —— 非系统安全漏洞 (Not a Vulnerability) |
| 披露日期 | 2026-01-23 |
| 下发机构 (CNA) | Zero Day Initiative (ZDI-26-031) |
| 宣称的严重等级 | 高危 (High) —— CVSS 8.8 (CVSS:3.0/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H) |
| CWE 归类 | CWE-78（OS 命令注入） |
CVE 指控的具体内容
该 CVE 指控称，Open WebUI 位于 backend/open_webui/utils/plugin.py 代码文件中的 install_frontmatter_requirements 函数，存在允许低权限已登录用户在 Tools（工具）或 Functions（函数）的 YAML frontmatter 属性区的 requirements 依赖字段中注入恶意的 pip 包名，从而通过底层运行的 subprocess.check_call 将其直接传递给 pip install 指令执行，引发 OS 命令注入漏洞导致任意代码执行。
为什么这不属于系统漏洞
install_frontmatter_requirements 是 Open WebUI 白纸黑字写在官方文档中的系统既定业务设计，系统通过此函数来解析并下载安装用户自主上传的 Tools/Functions 插件在 YAML 注释块（frontmatter）中声明的第三方 Python 依赖包。本系统中的 Tools 与 Functions 插件本质上就是由用户自主编写、由服务器直接装载、常驻内存并运行的 Python 代码。开发者通过 frontmatter 声明其依赖的第三方 pip 包，由服务器在首次装载时自动联网解析并补齐。这与全球主流的其他同类高扩展性系统（如 Jupyter Notebook 运行 %pip install 命令、n8n 工作流中的 Code 代码节点、Home Assistant 系统的 python_script 脚本扩展等）在处理三方依赖时的逻辑完全一致。
此处根本不存在任何“注入”攻击。 用户根本没有把命令恶意插进别人的固定处理流中 —— 他们是在合规提交自己编写的、声明了包依赖的 Python 源码，而服务器去下载这些依赖并运行该代码是完全符合系统最初的设计逻辑的。在此场景下，所谓的“攻击者”仅仅是在行使他们本就被系统显式授予的代码执行特权。
权限控制与访问限制
被指控的函数仅在受到超级管理员权限拦截的路由中才可被调用（如 POST /api/v1/tools/create、POST /api/v1/tools/id/{id}/update 以及配对的 Functions 插件管理接口）。调用这些特权路由要么要求发起账号的角色满足 user.role == 'admin' 校验，要么必须具备 workspace.tools 权限。而 workspace.tools 权限参数对于非 admin 的普通用户在默认情况下是强制关闭的。我们在官方文档中已经明确阐明：授予某个用户 workspace.tools 权限，在安全风险上等同于直接给该用户发放了宿主机服务器的 Shell 命令行控制权。因此，非授权的普通用户根本没有物理路径能触碰到此函数。
CVSS 评分严重失实
该 CVE 发布的 CVSS 评分将特权要求强行评定为“低特权（PR:L）”。这在安全评级的方法论上是完全错误的 —— 该函数只有管理员账号（PR:H）或者被特意配置了 root 级别特权的特可信账号才能调用。
适用的安全策略条款
- 安全策略第 10 条：任何涉及 Tools 或 Functions 插件 —— 包含直接执行 Python 代码以及解析 frontmatter 块执行 pip 安装 —— 的攻击链路报告一律作为“符合设计预期/非漏洞”进行关闭。
- 安全策略第 9 条：在 Functions/Tools 插件编辑器中 “粘贴不可信的任意代码”被官方明确归类为超出漏洞审查范畴的非漏洞行为。
- 安全策略第 1 条：系统常规的预期设计业务行为不属于安全漏洞。
对部署用户的实际影响
部署人员无需采取任何操作。 该 CVE 指控的其实是系统的核心设计特性。如果您在此前曾经将 workspace.tools 权限滥发给过不可信的外部用户，请立刻仔细参考 插件安全性指南 规范您的企业管理配置 —— 但这完全属于主观环境配置问题，绝非系统代码漏洞。