📋 安全政策

权威性

该政策的权威版本位于 GitHub 安全政策。本页面是其关键原则的快速参考摘要。如有任何不一致，GitHub 版本优先。

Open WebUI 认真对待用户数据的安全和保密。我们的技术架构和开发流程旨在最小化漏洞并维持利益相关者对我们的信任。定期评估、代码库审查和系统采用最佳实践方法有助于保持安全作为项目生命周期的中心部分。

我们采用自动化和手动技术的混合方法来跟上演变的威胁，并不断改进我们的方法，包括计划集成先进的静态和依赖分析工具。我们的重点是主动风险管理和负责任地处理任何报告的漏洞。

支持的版本

版本	支持
main	✅
dev	❌
其他	❌

安全漏洞的报告位置和方式

信息

Open WebUI 的社区之所以蓬勃发展，是因为像您这样的人，他们深切关心为每个人制造更安全的软件。

为确保您的发现确实有助于保护用户并迅速解决，请仅通过我们的官方 GitHub 安全页面提交所有安全漏洞报告。任何其他网站、服务或所谓的"赏金"平台都不与我们有关联，您的重要工作根本无法到达能做出改变的人。

我们知道信任做出大承诺的平台可能很诱人，但只有 GitHub 能直接将您连接到保护 Open WebUI 的人。让我们确保您的警惕确实使社区受益，在这里报告，这才是真正重要的地方。

Open WebUI 的所有安全漏洞必须仅通过我们的官方 GitHub 存储库报告：https://github.com/open-webui/open-webui/security。

所有安全漏洞报告仅通过我们的官方 GitHub 平台管理。在 GitHub 上集中处理披露允许每份报告由项目维护者透明、高效和保密地处理。这种方法为贡献者和用户提供可见性、问责和保证，即安全相关的通信和解决方案被彻底记录和可靠地管理。通过 GitHub 之外的任何平台、频道或第三方服务提交的报告无法纳入我们的官方安全工作流程，因此可能无法对 Open WebUI 的安全做出贡献。

为什么只有 GitHub？

我们使用单一集中报告机制的方法植根于技术严谨性和道德管理：

• 完整性和可追溯性： 仅通过 GitHub 管理报告将每个问题保留在开源生态系统内，社区可以验证贡献者的流程、结果和问责。
• 用户安全： 声称促进漏洞披露、提供奖励或赏金计划的其他网站与 Open WebUI 无关。向此类平台提交漏洞不仅无法使项目更安全，还可能无意中将敏感细节置于误用或未授权披露的风险中。
• 保护社区： 当信息绕过我们的集中安全工作流程时，项目不仅容易受到未修复的漏洞利用，而且容易受到误导或剥削实践的传播。尽管外部网站声称充当中介或支付赏金，这些实体对用户没有保证，可能在激励的幌子下鼓励可疑或不安全的行为。通过我们的 GitHub 进行的披露是您的专业知识可靠地使整个生态系统受益的唯一方式。

对外部平台的零容忍

我们拒绝与任何 GitHub 外部的平台进行交互、加入或监控以进行漏洞报告。来自我们指定 GitHub 存储库以外的任何来源的报告或请求将被不加考虑地驳回。此政策是不可谈判的，不允许例外。

外国 CNA 和供应商处置

当报告通过 GitHub 安全公告提交且维护者按照本政策将其关闭为超出范围时，该关闭是该问题的供应商处置。CVE 编号机构 (CNA) 为此类问题铸造 CVE 而未在结果记录中反映该供应商处置的行为违反了供应商处置。

我们通过以下方式回应此类记录：

1. 向 CVE 计划提交 REJECT 请求（以 DISPUTED 作为后备）
2. 在我们的供应商处置中公开编目记录，命名发行 CNA
3. 拒绝提供供应商声明、版本映射、修复参考或任何其他将赋予记录权限的协调
4. 将来自单个 CNA 的重复模式上报至 CVE 计划根

频道合规不赋予 CNA 覆盖供应商处置的权利。 在发行供应商处置后将已关闭的超出范围报告上报至第三方 CNA 的报告者将永久被禁止进行将来的提交。

报告指南

您可以在此处找到最新版本的安全指南。

为确保建设性、可行的报告，真正改进安全，所有提交必须满足以下要求：

1. 报告必须是漏洞：安全漏洞是一个可利用的弱点，其中系统行为不符合预期，允许攻击者绕过安全控制、获得未授权访问、执行任意代码或升级权限。配置选项、缺失功能和预期协议行为不是漏洞。漏洞必须跨越至少一个安全边界（机密性、完整性、可用性、真实性、不可否认性）。这些边界被广泛解释；其他安全框架中的等效概念属于它们。

2. 无模糊报告：诸如"我发现了漏洞"之类的提交，不包含任何细节，将被视为垃圾邮件且不被接受。

3. 需要深入了解：报告必须反映对代码库的清晰理解，并提供关于漏洞的具体细节，包括受影响的组件和潜在影响。

4. 概念验证 (PoC) 是强制性的：每个提交必须包括一个记录完善的概念验证，演示漏洞。PoC 必须显示跨越了哪个安全边界（机密性、完整性、可用性、真实性、不可否认性）、如何滥用该漏洞以及攻击者现在可以执行哪些操作。有效的 PoC 包括具有确切命令的分步重现说明、具有详细执行说明的完整漏洞利用代码，或演示漏洞的屏幕截图/视频（作为书面步骤的补充）。如果保密是一个问题，我们鼓励报告者创建存储库的私人分叉并与维护者共享访问。缺少有效证据的报告可能被忽视。如果我们努力使用您的 PoC 重现漏洞，我们会通知您，但如果我们反复无法重现它，报告可能会关闭。

5. 需要修复：除了 PoC 外，您必须提供patch/PR 或修复计划（可行的步骤），维护者可以应用而无需猜测。您的修复指导可以包括，例如：可能的根本原因（什么问题和在哪里）、要更改的位置（文件/模块/函数名称，如已知）、推荐的修复方法（验证/清理规则、身份验证检查、安全默认值等）和任何安全权衡或要观看的潜在回归。

6. 默认配置测试：所有漏洞报告必须使用 Open WebUI 的开箱即用默认配置进行测试和重现。仅使用明确削弱的安全设置出现的漏洞声明可能被丢弃。但是，如果您认为您已发现影响默认配置的安全问题，代表真正的绕过预期安全控制，或仅适用于非默认配置但所讨论的配置可能被生产部署使用，那么我们绝对想听到它。此政策旨在过滤配置问题和部署问题，而不是劝阻合法的安全研究。

7. 需要威胁模型理解：报告必须演示对 Open WebUI 的自托管、经过身份验证、可扩展、基于角色的访问控制架构的理解。在不承认架构差异的情况下将 Open WebUI 与具有根本不同安全模型的服务进行比较可能导致报告拒绝。

8. CVSS 评分准确性：如果您在报告中包含 CVSS 评分，它必须根据 CVSS 方法准确反映漏洞。常见错误包括在需要身份验证时评分 PR:N（无）、评分假设攻击链而不是实际漏洞，或在无证据的情况下夸大严重性。我们将调整不准确的 CVSS 评分。故意夸大的分数可能导致报告拒绝。如果您引用其他 CVE 来支持您的报告，确保它们在漏洞类型、威胁模型和攻击向量上确实可比较。引用来自不同产品类别、不同漏洞类别或不同部署模型的 CVE 将导致我们怀疑在您的报告中使用了 AI。

9. 管理员操作不在范围内：需要管理员主动执行不安全操作的漏洞不被视为有效漏洞。管理员拥有完全的系统控制权，应该理解其操作和配置的安全含义。这包括但不限于添加恶意外部服务器（模型、工具、webhook、函数）、将不受信任的代码粘贴到函数/工具中，或故意削弱安全设置。需要管理员疏忽或对管理员进行社会工程的报告可能被拒绝。但是，如果您认为您已发现影响管理员的漏洞且不由管理员疏忽或故意恶意操作引起，那么我们绝对想听到它。此政策旨在过滤对管理员的社会工程攻击和类似的恶意操作，而不是劝阻合法的安全研究。

10. 工具和函数代码执行是预期行为：Open WebUI 的工具和函数功能被设计执行用户提供的 Python 代码在服务器上。这是核心的、有意的功能 — 而不是漏洞。函数创建仅限于管理员。工具创建由 workspace.tools 权限控制，该权限默认为非管理员用户禁用，只应授予完全信任的用户，他们在信任方面等同于系统管理员。给予用户创建工具的能力相当于给他们对服务器的 shell 访问权限。 更一般地说，描述涉及工具或函数的任何攻击链的报告 — 包括但不限于代码执行、文件访问、网络请求或环境变量访问 — 将作为不是漏洞/预期行为关闭。 这适用于直接代码执行和前置基础包安装（pip install）。

11. 遗留代码路径不在范围内：Open WebUI 维护一些在官方文档中明确标记为遗留的代码路径。遗留路径保持可用 — 有时仍然是默认值 — 纯粹出于向后兼容性原因，而不是因为它们是支持或维护的表面。安全和功能工作发生在支持的替代品上，而不是遗留路径。描述仅在遗留代码路径上且在支持的替代品上也不重现的安全边界问题的报告在该规则下超出范围。如果问题在遗留路径和支持的现代替代品上都重现，或遗留路径是实现给定功能的唯一记录的方式（尚无迁移目标存在），我们仍然想听到它。

12. AI 报告透明度：由于 AI 辅助漏洞报告的极端激增，您必须披露是否以任何方式使用了 AI — 无论是编写报告、生成 PoC 还是识别漏洞。AI 辅助的漏洞报告默认不会被拒绝。但是，如果我们怀疑您使用了 AI 但未向我们披露，我们将提出严厉的后续问题来验证您对报告的漏洞和 Open WebUI 本身的理解。如果我们怀疑您使用了 AI 但您未披露它，您的报告最终无效、不是漏洞或不可重现，那么您可能被禁止从事将来的漏洞报告。由于明显由 AI 编写的漏洞报告的极端增加，此措施是必要的，其中绝大多数不是漏洞，是错误的配置而不是真实漏洞，未提供 PoC，违反了此处列出的规则，清楚地缺乏对 Open WebUI 的理解，用冲突的信息写注释，或使用了不合逻辑的论证。

13. 自我影响问题不是漏洞：漏洞需要跨越影响除报告者以外的一方的安全边界。仅针对报告者自己的数据、账户、会话或环境跨越五个公认的安全边界之一不是漏洞 — 这是一个错误，属于问题跟踪器，而不是安全报告。如果相同的操作也影响另一用户、操作者、主机系统或共享资源，在 PoC 中清楚地标识该第二方。

不符合要求的提交将被关闭，重复极端违反者可能被禁止。我们的目标是培养一个建设性的报告环境，其中质量提交提高所有用户的安全性。不仅识别漏洞而且呈现稳健、可合并的修复的贡献者有助于加速我们的响应并加强社区。

如果您觉得由于特定于漏洞的原因无法遵循所有列出的要求，仍然要报告它 — 我们将以任何方式检查每份报告。

预期的时间框架

Open WebUI 收到大量漏洞报告、问题、讨论和拉取请求 — 最近因不可思议的大量 AI 生成的报告而加剧（请参阅 AI 报告透明度）。该项目由一个小团队维护，安全报告与所有其他项目责任一起处理。

请预期数周来对您的报告进行分类、调查、修复和发布。持续数周的沉默期是正常的，不意味着您的报告被忽略 — 只是我们还没有能力解决它。一旦您的报告经过审查，您将收到确认，然后在调查进行时获得更新。如果您的报告已开放而未收到回应，并且您想要状态更新，欢迎在公告上留下评论。

对于我们判断具有广泛或严重实际影响的发现 — 无论 CVSS 评分如何 — 我们可能会在修补版本发布后推迟发布 1-2 周，以便管理员有时间更新他们的实例。

报告处理

如果您报告有人之前已报告过的有效漏洞，我们将关闭您的报告作为重复。给定漏洞的最早提交是我们将继续处理的。我们不会为同一漏洞发布多个公告。

当多个独立报告者描述同一漏洞类别但每个演示不同且独立的利用向量时 — 例如，通过不同端点到达的相同缺失授权检查 — 我们将它们合并到最早的提交中，并对每个演示不同路径的报告者表示赞赏。只有一个 CVE 将为合并的公告发行。

为什么重复报告不获得赞誉

我们仅赞誉给定漏洞的最早申报人：

1. 第一份报告做了工作。 当后期报告到达时，分类和修复已在进行中。后期报告不改变结果或时间表；赞誉他们会歪曲什么推动了修复。
2. 为重复信用奖励淹没。 如果相似但后期申报获得信用，理性的做法是浏览开放公告并提出变化。我们已经看到这种压力 — 首先申报规则是限制它的原因。
3. 共同发现不同于重复。 多个报告者在一份公告上获得赞誉当每个贡献不同的_独特_发现时 — 不同向量、不同受影响组件、不同子路径早期申报不覆盖。这是上面的合并规则。提交现有报告的重复不是共同发现。

保密披露

通过 GitHub 安全公告提交的漏洞报告是私密和保密的。在公告完全发布之前，公开披露与已提交漏洞报告相关的任何细节是严格禁止的 — 不仅仅是分配了 CVE ID 时，而是公告本身公开可见时。

此禁止适用于所有频道，包括但不限于：

• 拉取请求、问题或讨论上的评论（在 GitHub 或其他地方）
• 社交媒体、博客、论坛或任何其他网站
• Discord、Reddit 或任何其他平台、网站或服务

早期披露破坏了所有 Open WebUI 用户的安全并违反了负责任披露流程中固有的信任。在官方发布前早期公开披露漏洞细节的报告者将被永久禁止进行将来的报告。

对于非漏洞相关的安全问题

如果您的关问题不符合上述漏洞要求、不是漏洞，但仍与安全问题相关，请改用以下频道：

• 文档问题/改进想法：在我们的文档存储库中打开问题
• 功能请求：在GitHub Discussions - Ideas中创建讨论，与社区讨论此功能请求是否由多人需要
• 配置帮助：在我们的Discord 服务器或Reddit上向社区寻求帮助和指导
• 一般问题：使用我们的问题跟踪器

非漏洞但仍与安全相关的问题示例包括对更好默认配置值的建议、安全加固建议、部署最佳实践指导、不清楚的配置说明、需要额外安全文档、可选安全增强功能的功能请求（2FA、审计日志等）和关于生产部署的一般安全问题。请为您的具体问题使用适当的频道。

工具、函数和管道安全

Open WebUI 通过工具、函数（包括管道、过滤器和操作）和管道提供强大的可扩展性。这些功能允许您使用自定义 Python 代码扩展 Open WebUI 的功能。但是，这种力量伴随着安全责任。以下每个文档页面都包含其自己的安全警告 — 查看它们以获得完整的图片：

• 插件安全概览 — 关键安全警告、信任模型和工作区访问限制
• 工具 — 工具创建、导入和 workspace.tools 权限的安全警告
• 函数 — 仅管理员创建、代码执行警告
• 管道 — 管道插件系统的任意代码执行警告

注意

工具、函数和管道在您的服务器上执行任意 Python 代码。 这是有意的 — 这是使它们强大的原因。但是，这意味着它们具有与 Open WebUI 后端流程相同的访问级别。

安全影响

当您安装工具、函数或管道时，您授予它执行以下操作的能力：

• 访问文件系统 — 读取或写入后端流程可以访问的任何文件
• 进行网络请求 — 连接到外部服务，可能泄露数据
• 执行系统命令 — 通过子流程运行 shell 命令
• 访问环境变量 — 读取 API 密钥、秘密和配置
• 修改数据库 — 访问或改变存储的数据
• 消耗计算资源 — 运行 CPU 密集型操作

最佳实践

实践	描述
仅从信任的源安装	仅使用来自官方社区库或您信任的源的工具/函数
安装前检查代码	在导入工具/函数之前阅读并理解其功能
限制工作区访问	仅向信任的管理员授予工作区权限
审计已安装的插件	定期查看已安装的工具（工作区 → 工具）和函数（管理面板 → 函数）
保护您的数据目录	/app/backend/data 目录包含您的数据库和缓存的插件 — 保护它免受未授权访问
监控资源使用	观察可能表示加密货币挖掘或其他滥用的意外 CPU 尖峰
使用官方 Docker 映像	仅从 ghcr.io/open-webui/open-webui 或 openwebui/open-webui（Docker Hub）拉取 — 非官方映像可能被破坏

什么不是漏洞

以下场景不被视为漏洞，因为它们需要管理员操作（另请参阅上面报告指南中的管理员操作不在范围内和威胁模型理解）：

• 管理员安装恶意工具或函数
• 管理员向不受信任的用户授予工作区访问权限
• 管理员从不受信任的源导入代码
• 具有数据卷写入权限的攻击者注入恶意插件

更一般地说，描述涉及工具或函数的任何攻击链的报告 — 包括但不限于代码执行、文件访问、网络请求或环境变量访问 — 将作为不是漏洞/预期行为关闭。 如果管理员向不受信任的用户授予工具权限，这构成故意的错误配置。

这些场景代表 Open WebUI 本身中的管理员疏忽或环境破坏，而不是漏洞。有关详情，请参阅我们的安全政策和插件安全文档。

生产部署安全

Open WebUI 为私密、可信网络设计，附带针对轻松设置优化的默认值。处理敏感数据的生产部署应查看加固指南以获得全面的检查清单。

一个关键考虑：没有 Redis，登出和密码更改不会撤销现有的 JWT 令牌 — 它们保持有效直到过期（默认：4 周）。这意味着被破坏的令牌无法失效，管理员发起的账户停用不会立即阻止访问。对于生产部署，要么配置Redis要么缩短 JWT_EXPIRES_IN 以限制暴露窗口。详情请参阅令牌撤销。

产品安全流程

• 我们的架构和管道的内部和定期外部审查
• 前端和后端的自动化和手动测试
• 作为进行中开发的一部分的主动风险管理和代码审查
• 连续改进和集成用于静态/动态分析的先进工具

如果您有直接且可行的安全问题，请在我们的安全公告门户或问题跟踪器中创建报告。