Open WebUI 安全策略深度解读：漏洞报告规则、CVE 协调机制与默认安全权限设计

2026-09-04 10:55:17作者：劳婵绚Shirley

Open WebUI 的安全策略（docs/SECURITY.md）定义了一套完整、公开、可执行的安全流程：哪些版本受支持、什么算有效漏洞、报告必须包含哪些要素、CVE 如何协调、以及违规披露会面临什么后果。本文以该策略文档为骨架，逐条解读其 13 项报告规则与处置机制，并结合仓库源码印证策略背后的实际实现（如 ENABLE_PLUGINS 开关、workspace.tools 权限、插件 exec() 加载链），帮助安全研究者写出一次就能被受理的报告，也帮助运维者理解默认部署下的真实安全边界。

政策目标与受支持版本

Open WebUI 安全策略的核心理念是透明：

目标是保护用户及其数据，并以清晰、一致、公开文档化的流程处理安全报告；
所有被接受的漏洞都会作为公开 advisory 发布，任何人可以看到发现了什么、如何修复、哪个版本包含补丁；
官方立场是：可见的 advisory 历史是"主动审查与有效披露流程"的证据，而不是软件脆弱的度量。

受支持版本表

版本（分支）	是否受支持
`main`	支持
`dev`	不支持
其他分支	不支持

"已修复即不予受理"规则（重要）

如果你在提交报告时，该问题已经被修复、或正在被公开修复，报告将不被接受——因为它没有对发现问题或修复问题做出 contribution，官方也不会为它发布 advisory。

这条规则有几个容易误解的细节，策略原文逐条界定：

修复落在哪个分支都算"已存在"——包括 dev 分支，也包括在更早版本中被静默修复的情况；
分支支持状态决定的是漏洞必须在哪个分支上"可复现"，而不是修复是否存在。一个在受支持分支上仍然活跃、但已在 dev 修复的 bug，按此规则属于"已修复问题"；
官方明确列出两种被拒绝的具体模式：
- 报告一个旧版本中发现的 bug，而该 bug 在当前受支持版本中已解决；
- 监控公开 commits 或 pull requests，然后报告其中已经涵盖的问题。官方表示已观察到自动化工具监控其公开 commits/PRs 并针对他人已编写的修复提交报告，此规则正是为拒绝这种模式而设。
无需（也无法）判断你是否独立发现：可证明的事实是报告与已公开且已修复/修复中的工作重复、且提交时间严格更晚。"该问题的 credit 归属于发现或修复它的人——而此人通过公开披露（而非先保密报告给维护者）放弃了自己的主张。因此公开披露的修复不产生 advisory，也不给任何人 credit。"

策略原文给出的操作建议（TIP）：

提交报告前，先确认你的发现是否仍在 dev 分支（及其他活跃开发分支）上可复现。 项目在公开方式下开发，修复可能已先行提交。先确认这一点，可以避免你费力撰写一份必然以"已修复"被关闭的报告。

报告渠道：GitHub Security Advisories 是唯一权威通道

策略将报告渠道收敛为唯一入口：GitHub Security Advisories（仓库的 security advisories 新建入口）。

通过任何其他平台提交的报告——包括但不限于第三方漏洞报告平台、漏洞经纪人（broker）、社交媒体、邮件、Discord、Reddit——都不会被处理；
官方强调这不是流程偏好：整个安全流程围绕与项目其他部分相同的透明度构建，GitHub Security Advisories 是该流程所在的唯一权威通道。官方无法也不监控外部报告平台，经由这些渠道到达的报告将不经过审查直接关闭；
在其他平台提交的报告在此策略下没有任何地位：不带来优先权、不确立提交日期、不产生任何分诊/发布/考量义务。只有 GitHub Security Advisory 记录本身在本策略下存在——包括用于判定"谁先提交"。

善意报告：不是漏洞也可以保密上报

针对一类特殊发现——你明知它在政策下不算严格意义的漏洞，但公开披露仍然不负责任（例如因为下游依赖漏洞而需要紧急 bump 依赖版本，或类似情况）——策略给出了明确出路：

你仍然可以通过 GitHub Security Advisories 保密报告，官方会负责任地处理；
遵循 CVE 规则，官方不会为此类报告发布 advisory 或申请 CVE 编号，但会采取行动（例如实际发出依赖 bump），并在处理完成前保密；
若基于你的报告落地了修复且你希望获得署名，官方会尽量致谢（例如作为该变更的 co-author）。

有效报告能获得什么

如果你的报告描述了一个政策下的真实漏洞，可以预期：

承诺项	说明
advisory 署名（Credit）	你在发布的 advisory 上被命名为报告者；多名报告者各自演示了不同利用向量时，每个人都会被署名（见"重复报告处理"一节）
协调披露（Coordinated disclosure）	在你与我们共同处理问题期间，不会"从你脚下"抢先发布。advisory 本身上的状态变化（包括 CVE 申请）可见，GitHub 会向你推送更新，你可以跟踪到发布
负责任的真实修复	对具有广泛或严重现实影响的发现，可能在补丁版本发布后延迟最多约 2 周才公开细节，以便管理员先行更新

策略同时明确不承诺的东西：没有赏金（bounty），没有保证的响应时限。你能得到的是严肃的修复、诚实的 credit，以及一个把你的工作当作 contribution 对待的流程。

与 CVE 计划的对齐

CVE 计划规则（含 CNA 操作规则）是所有 CVE 处理的基础（baseline），本策略在它们框架内运行。要点：

按那些规则，判断某报告是否构成 Open WebUI 安全漏洞的决定权在 vendor（本项目）；本策略文档化的是官方行使该决定权的标准；
规则未提及之处依然适用；本策略规定如何把规则应用于 Open WebUI 的部分，是以 vendor 公开处置标准（published disposition criteria）的身份，而非替代或豁免计划规则。

外部 CNA 与 vendor 处置（Vendor Disposition）

策略记载：基于多次"外部 CNA 在未与项目沟通的情况下就报告铸造 CVE，或铸造经不起任何审查的 CVE"的先例（官方在文档站点维护了 vendor-dispositions 目录），建立了如下规则：

当报告通过 GitHub Security Advisories 提交、维护者按本策略以 out-of-scope 关闭时，该关闭即为该问题的 vendor 处置（vendor's disposition）；
CNA 若无视该 vendor 处置而为问题铸造 CVE，即构成"对抗 vendor 处置"的行为。

官方对这类记录的应对是四步：

向 CVE Program 提交 REJECT 请求（以 DISPUTED 作为备选）；
公开编目该记录，并点名铸造该 CVE 的 CNA；
拒绝提供 vendor statement、版本映射、修复引用或任何其他会给该记录背书的协调；
将同一 CNA 的反复模式升级至 CVE Program Root。

策略原文还有一条针对报告者个人的约束（加粗为原文强调）：

渠道合规并不赋予 CNA 推翻 vendor 处置的权利。 在 vendor 处置已作出后，把已按 out-of-scope/not-a-vulnerability 关闭的 GHSA 报告升级给第三方 CNA 的报告者，同样被视为对抗 vendor 处置，可能被禁止未来向 GHSA 提交报告。

漏洞报告规则：13 条有效报告标准

策略明确声明不再接受低质量（low-effort）漏洞报告，提交必须"建设性、可操作、可复现、文档完备"，并满足以下 13 条规则。不合规的提交可能被关闭，重复或极端违规者可能被禁止提交报告。

先理解一个贯穿全文的定义——安全边界（security boundaries）：

本政策中"安全边界"指官方认可的五个：机密性（Confidentiality）、完整性（Integrity）、可用性（Availability）、真实性（Authenticity）、不可否认性（Non-repudiation）。官方对这些做广义解读——其他安全框架中的等价概念均落在其范围内。有效漏洞必须至少跨越其中一条边界，且受害方是报告者以外的主体。

规则 1：报告必须是漏洞

安全漏洞是可被利用的弱点，使系统以非预期方式运行，允许攻击者绕过安全控制、获取未授权访问、执行任意代码或提升权限。配置选项、缺失功能、预期的协议行为都不是漏洞。 漏洞必须跨越至少一条安全边界。

规则 2：不接受模糊报告

诸如"我发现了一个漏洞"而没有任何细节的提交会被当作垃圾信息（spam）处理，不予受理。

规则 3：必须展现对代码库的深入理解

报告必须反映对代码库、Open WebUI 使用方式的清晰理解，并提供关于漏洞的具体细节，包括受影响组件和潜在影响。

规则 4：PoC（概念验证）是强制的

每份提交必须包含文档完备的 PoC。如果担心机密性，报告者被鼓励创建仓库的私有 fork 并与维护者共享访问权限。缺少有效证据的报告可能被忽略。策略明确了 PoC 必须展示的四点：

恰好跨越了哪条安全边界；
漏洞如何被触发/滥用（输入、端点、UI 操作等）；
攻击者因此现在能执行什么操作；
精确的复现步骤和命令（尽可能可直接复制粘贴运行）、预期结果与实际结果。

规则 5：必须附带修复方案（Remediation）

与 PoC 一起，必须提供以下二者之一：

修复计划（维护者可应用的"可操作步骤"），或
补丁 / PR。

修复指引可包括（示例）：

可能的根因（哪里、出了什么问题）；
需要修改的位置（若知道，给出文件/模块/函数名）；
推荐的修复方式（校验/清洗规则、认证检查、安全默认值等）；
需要注意的任何安全权衡或潜在回归。

规则 6：默认配置测试

漏洞报告必须基于 Open WebUI 开箱即用的默认配置进行测试并可复现。仅因显式削弱安全设置才出现的漏洞主张可能被丢弃，除非符合以下例外：

如果你发现的.security 问题满足以下任一条件：

影响默认配置；或

构成对预期安全控制的真实绕过；或

仅在非默认配置下工作，但该配置很可能被生产部署使用—— 官方"绝对希望"听到它。此政策的目的是过滤配置问题和部署问题，而非 discouraging 正当安全研究。

规则 7：必须理解威胁模型

报告必须展现对 Open WebUI 架构的理解：自托管（self-hosted）、单租户（single-tenant）、需认证（authenticated）、可扩展（extensible）、基于角色的访问控制（RBAC）。在不承认架构差异的前提下，把 Open WebUI 与具有根本不同安全模型的服务对比，可能导致报告被拒。

规则 8：CVSS 评分准确性

CVSS 分数不必包含在报告中；留空则官方在发布前代为填写；
若自行填写，必须按 CVSS 方法论准确反映漏洞，不准确的 CVSS 会被官方调整；
若引用其他 CVE 佐证报告，必须确保它们在漏洞类型、威胁模型、攻击向量上真正可比。

规则 9：管理员主动操作不在范围内

需要管理员主动执行不安全操作的"漏洞"不被视为有效漏洞。 管理员拥有完整系统控制权，被预期理解其操作与配置的安全含义。包括但不限于：添加恶意外部服务器（模型、工具、webhook、functions）、向 Functions/Tools 粘贴不可信代码、故意削弱安全设置。依赖管理员疏忽或对管理员社会工程的报告可能被拒。

与规则 6 类似的例外：如果你发现的漏洞影响管理员但并非由管理员疏忽或故意恶意操作导致，官方"绝对希望"听到它。此规则过滤的是针对管理员的社会工程攻击、管理员部署恶意插件等情形，而非正当安全研究。

规则 10：Tools & Functions 代码执行是预期行为

这是与安全策略关系最紧密、也最能从仓库源码得到印证的一条规则：

Open WebUI 的 Tools 和 Functions 功能"设计上"就是在服务器上执行用户提供的 Python 代码。这是核心、刻意的功能，不是漏洞（另见规则 7 的威胁模型）；
Function 创建仅管理员可用；
Tool 创建由 workspace.tools 权限控制，该权限对非管理员用户默认关闭，只应授予与系统管理员同级信任、完全可信的用户。把创建 Tools 的能力授予某用户，等同于授予其对服务器的 shell 访问权限。
管理员把该权限授予不受信任的用户，构成故意错误配置，并被规则 9"管理员操作不在范围内"进一步覆盖；
不需要 workspace.tools 或 Functions 插件执行的部署可以设置 ENABLE_PLUGINS=false；
更一般地，任何涉及 Tools 或 Functions 的攻击链——包括但不限于代码执行、文件访问、网络请求、环境变量访问——的报告都会以"不是漏洞/预期行为"关闭。这同时适用于直接代码执行和基于 frontmatter 的包安装（pip install）。

策略原文给管理员的警示（原文为 IMPORTANT 级提示）：

把 workspace.tools 权限当作 root 等价权限对待。 只授予你会给直接服务器访问权限的用户。若为不受信任用户启用它，你在接受宿主机上任意代码执行的风险。

源码印证：这条规则在代码里如何落实

仓库中的实现与策略描述完全一致：

workspace.tools 默认关闭：前端默认权限表中 workspace.tools 初始值为 false，见 src/lib/constants/permissions.ts 的 DEFAULT_PERMISSIONS.workspace 块；
后端创建 Tool 时的双重校验：在 backend/open_webui/routers/tools.py 处，非管理员用户必须通过 workspace.tools 权限检查（has_permission(user.id, 'workspace.tools', ...)）才能创建，与策略"Tool 创建由 workspace.tools 权限控制、默认关闭"的描述一致；
代码执行确实存在，且是显式设计：插件加载器 backend/open_webui/utils/plugin.py 中，Tool 内容写入临时文件后通过 exec(content, module.__dict__) 在独立模块命名空间执行；Function 加载走同一模式（backend/open_webui/utils/plugin.py），并识别 Pipe/Filter/Action/Event 四类入口；frontmatter 中的 requirements 会在执行前经 install_frontmatter_requirements 触发 pip install（backend/open_webui/utils/plugin.py）——这正是策略"同样适用于 frontmatter-based package installation"一句所指；
ENABLE_PLUGINS=false 是一等公民开关：定义于 backend/open_webui/env.py（ENABLE_PLUGINS = os.getenv('ENABLE_PLUGINS', 'True').lower() == 'true'，注意默认值是开启的）；后端在各处设防——Functions/Tools 路由（backend/open_webui/routers/functions.py、backend/open_webui/routers/tools.py）、事件系统（backend/open_webui/events.py）、动作执行（backend/open_webui/utils/actions.py 会直接抛出 Plugins are disabled by ENABLE_PLUGINS=false）、插件加载器入口（backend/open_webui/utils/plugin.py 抛出 RuntimeError），并在公开配置中回显该状态（backend/open_webui/main.py）。
相关环境变量还包括 backend/open_webui/env.py 中的 ENABLE_PIP_INSTALL_FRONTMATTER_REQUIREMENTS（默认 True，控制 frontmatter 依赖安装）、PIP_OPTIONS 与 PIP_PACKAGE_INDEX_OPTIONS（可注入 pip 参数，如指向内部镜像源），这些是策略"预期行为"框架下管理员可进一步收窄攻击面的旋钮。

也就是说，策略规则 10 并不是文字声明，而是与 permissions.ts 默认值、后端路由鉴权和插件加载实现三者互相咬合的实际设计。

规则 11：遗留（Legacy）代码路径不在范围内

Open WebUI 保留了一些在官方文档中明确标记为 legacy 的代码路径（官方文档对"什么是 legacy"具有权威解释权）；
遗留路径保留——有时甚至仍是默认——纯粹是向后兼容原因，不代表受支持或受维护的表面；受支持的替代物是迁移目标，安全与功能工作发生在替代物上，而不是遗留路径上；
描述仅在遗留路径（且不在受支持的替代物上复现）上的安全边界问题的报告，通常按此规则 out of scope。

例外（官方仍然希望听到）：

问题同时存在于遗留路径和受支持的现代替代物上；或
问题存在于遗留路径，且该遗留路径是实现某功能的唯一文档化方式（尚不存在迁移目标）。

规则 12：AI 报告透明度

由于漏洞报告数量激增（原文强调），必须披露是否在任何环节使用了 AI——无论用于撰写报告、生成 PoC 还是识别漏洞。注意：

AI 辅助的漏洞报告默认不会被拒绝；
但未声明 AI 使用、却看起来是 AI 辅助的报告，将面临严重得多的审查。

规则 13：只影响自己的问题不是漏洞

漏洞要求跨越的安全边界影响的是报告者以外的主体。仅针对报告者自己的数据、账户、会话或环境跨越边界，不是漏洞——是 bug，应提交到 Issue Tracker 而非安全报告。

这条规则关注的是谁受到损害，而非严重程度。用户修改/删除自己的数据、破坏自己的会话、观察自己的配置、或在自己的账户上禁用安全控制，无论影响多大都属此规则 out of scope。

如果同一操作同时影响其他用户、运营方、宿主系统或共享资源，请在 PoC 中明确指明这个"第二主体"，官方希望听到。

处理时效：请预期数周

策略对时效的声明非常直接，运营者应据此管理预期：

官方目标是尽快完成分诊、修复与发布，但由于极高的报告量（近期叠加大量 AI 生成的报告）、issues、discussions、PRs 与日常维护，加上项目由小型核心团队维护、安全报告与其他职责并行处理——请预期数周（several weeks） 才能完成分诊、调查、修复与发布；
数周量级的沉默是正常现象，不代表报告被忽略，而是尚未被拾起。若担心报告被遗漏，可以在 advisory 下追加跟进评论以提升可见性；
不接受报告者自设的发布期限（reporter-imposed publishing deadlines）。官方按自己的节奏协调披露；外部强加的硬性时间表不会加快处理，反而会把维护者时间从修复问题转移到看表上，以队列中其他报告（甚至更严重的）和整个项目为代价。附在报告上的期限不会改变它何时、多快被处理；
对官方判定为具有广泛或严重现实影响的发现（不论 CVSS 分数），可能在补丁版本发布后最多约 2 周延迟发布，给管理员留出更新实例的时间。

报告处理：同一漏洞多报告者如何定责

不同向量：合并 + 全部署名

当多名独立报告者描述同一漏洞类别，但各自演示了不同且独立的利用向量时（例如同一个缺失授权检查经由不同端点到达）：

官方将其合并到最早的提交，并在合并后的 advisory 上为每个演示了不同路径的报告者署名；
合并后的 advisory 只签发一个 CVE。

相同向量：后到者按重复关闭

如果你报告的有效漏洞与更早的报告完全相同（相同漏洞、相同利用向量）：你的报告将作为重复项（duplicate）关闭。最早的提交是官方继续处理的那一份，不会为同一漏洞发布多个 advisory。

为什么重复报告不给 credit

第一份报告做了实际工作：后续报告到达时，分诊与修复已在推进。后来的报告不改变结果或时间线；给它 credit 会歪曲"是什么推动了修复"；
"重复给 credit"会激励灌水：若"类似但更晚"的提交也能拿 credit，理性策略就是扫一遍开放 advisory 然后提交变体。官方已观察到这种压力——first-filer（先提交者优先）规则正是限制手段；
共同发现（co-discovery）不同于重复：多名报告者在一则 advisory 上都会被署名，当每人贡献的是不同发现——不同向量、不同受影响组件、更早报告未覆盖的不同子路径（即上面的合并规则）。提交已有报告的重复不是共同发现。

负责任披露：保密义务与违规后果

通过 GitHub Security Advisories 提交的漏洞报告是私密且保密的；
在漏洞的 advisory 完全发布之前（注意：不是 CVE 编号被分配之时，而是 advisory 本身公开可见之时），严禁在任何渠道公开披露任何细节。禁令适用于所有渠道，包括但不限于：PR/issue/discussion 评论（GitHub 或别处）、社交媒体（Discord、Reddit 或其他）、博客、论坛或任何网站服务；
该保密、负责任披露流程存在的目的，是为修复、发布修复、并在修复就绪时提醒用户留出时间。其全部前提是保护用户免受漏洞之害。过早披露损害所有 Open WebUI 用户的安全，并违背负责任披露流程内固有的信任；
在官方发布前过早公开披露漏洞细节的报告者，将被永久禁止未来报告（PERMANENTLY BANNED）。

非漏洞类安全问题的反馈渠道

对于不属漏洞的安全关切或其他问题，策略列出了对应渠道（文中不附外部链接，以入口名称指代）：

类别	渠道
文档问题/改进建议	官方 Documentation 仓库的 Issue
功能请求	GitHub Discussions 的 Ideas 区（与社区讨论是否有多人需要该功能）
配置求助	Discord 服务器或 Reddit 社区
一般问题 / Bug	GitHub Issue Tracker
最佳实践指导	参与扩充官方 Documentation

策略还披露了官方的主动安全工作：定期使用自动化与手工测试相结合的技术，对内部流程与系统架构进行漏洞审计；并计划在项目中引入 SAST（静态应用安全测试）与 SCA（软件成分分析）扫描。

落地清单：策略对研究者和管理员分别意味着什么

综合上述条款，可以整理出一份对照检查表：

安全研究者提交报告前：

在 dev 分支（及其他活跃分支）上确认问题仍复现，并确认不是对公开 commits/PR 的"后手"；
确认受害方是报告者以外的主体（规则 13），且跨越了五条安全边界之一（规则 1）；
按默认配置验证复现（规则 6）；若仅在非默认配置下成立，说明为何该配置很可能出现在生产部署；
备齐四要素 PoC + 修复计划或 PR（规则 4、5）；
若使用了 AI，明确披露（规则 12）；
确认攻击链不涉及 Tools/Functions 代码执行（规则 10）、不依赖管理员失误（规则 9）、不只存在于有现代替代物的 legacy 路径（规则 11）；
只走 GitHub Security Advisories 单一渠道，并预期数周处理周期，不自设期限。

管理员部署时：

workspace.tools 权限保持默认关闭（src/lib/constants/permissions.ts），如需开启，按 root 等价权限对待；
不需要插件执行能力的部署显式设置 ENABLE_PLUGINS=false（backend/open_webui/env.py），从加载器入口到路由、事件、动作全链路禁用 Functions/Tools 执行；
如启用插件执行且需收窄依赖安装，了解 ENABLE_PIP_INSTALL_FRONTMATTER_REQUIREMENTS、PIP_OPTIONS、PIP_PACKAGE_INDEX_OPTIONS 三个环境变量（backend/open_webui/env.py）的作用；
理解"管理员操作 out of scope"的边界：添加外部服务器、粘贴代码进 Functions/Tools、削弱安全设置等都属于管理员自担风险的行为，官方不会为此类事故发布 advisory。