CVE-2026-0766
| 评估指标 | 官方评估与明细 |
|---|---|
| CVE 编号 | CVE-2026-0766 |
| 官方处理声明 (Vendor Disposition) | 已驳回 (Rejected) —— 非系统安全漏洞 (Not a Vulnerability) |
| 披露日期 | 2026-01-23 |
| 下发机构 (CNA) | Zero Day Initiative (ZDI-26-032) |
| 宣称的严重等级 | 高危 (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-94（代码注入） |
CVE 指控的具体内容
该 CVE 指控称，Open WebUI 位于 backend/open_webui/utils/plugin.py 代码文件中的 load_tool_module_by_id 核心加载函数，允许低权限已登录用户通过提交包含任意 Python 源码的恶意外置 Tools（工具）插件，并由该函数直接将其传递给内置的 exec() 函数运行，从而引发 Python 代码注入漏洞。
为什么这不属于系统漏洞
load_tool_module_by_id 是 Open WebUI 白纸黑字写在官方文档中的核心设计机制，系统正是通过此函数来装载并实例化用户编写的 Tools 插件。Tools 插件在本质上就是由用户亲自编写并在服务器底层执行的 Python 模块 —— 这正是该特性的全部业务功能和存在意义。该函数会从数据库中读取 Tools 插件的代码字符、解析注释头声明，随后直接调用 Python 内置的 exec() 编译运行该源码以将其实例化装载进内存中。此处根本没有什么需要额外增设的输入“安全校验”；输入的数据本身就是用户特意编写并指明要求服务器去执行的 Python 脚本。
这完全是现代所有具备高扩展性设计的软件平台的标准运行模型：Jupyter 能够直接编译运行 notebook 的代码块、n8n 可以无阻运行 Code 代码节点、Home Assistant 系统也完全依靠相同的机制去加载和跑通 python_script 脚本扩展。对提交的代码调用 exec() 编译执行，正是该功能的根本支柱，绝非系统缺陷。
权限控制与访问限制
在系统底层的路由中，所有会触发并调用 load_tool_module_by_id 的 API 入口均受到超级管理员权限的严密拦截保护（即要求发起账号的角色满足 user.role == 'admin' 校验），或者必须具备 workspace.tools 权限。而 workspace.tools 权限参数对于非 admin 的普通用户在默认情况下是强制关闭的。我们在官方文档中已经明确阐明：授予某个用户 workspace.tools 权限，在安全风险上等同于直接给该用户发放了宿主机服务器的 Shell 命令行控制权。因此，非授权的普通用户根本没有物理路径能触碰到此函数。
CVSS 评分严重失实
该 CVE 发布的 CVSS 评分将特权要求强行评定为“低特权（PR:L）”。这在安全评级的方法论上是完全错误的 —— 该函数只有管理员账号（PR:H）或者被特意配置了 root 级别特权的特可信账号才能调用。
适用的安全策略条款
- 安全策略第 10 条：Tools 特性的根本设计目的就是为了在服务器上编译并执行用户上传的 Python 代码。任何涉及 Tools 或 Functions 插件的报告一律作为“符合设计预期/非漏洞”进行关闭。
- 安全策略第 9 条：在 Functions/Tools 插件编辑器中“粘贴不可信的任意代码”被官方明确归类为超出漏洞审查范畴的非漏洞行为。
- 安全策略第 1 条：系统常规的预期设计业务行为不属于安全漏洞。
对部署用户的实际影响
部署人员无需采取任何操作。 该 CVE 指控的其实是系统的核心设计特性。由管理员上传并部署的 Tools 插件在服务器端直接编译运行 Python 是系统的基本功。如果您在此前曾经将 workspace.tools 权限滥发给过不可信的普通用户，请立刻仔细参考 插件安全性指南 规范您的企业管理配置。