跳到主要内容

📋 安全策略

最终解释权声明

此策略的权威版本存放于 GitHub 安全策略 (Security Policy)。本页面仅作为核心原则的摘要说明，方便快速参考。如果两处内容存在任何分歧，以 GitHub 上的版本为准。

Open WebUI 始终高度重视用户数据的安全性和隐私机密性。我们的技术架构和软件开发流程旨在将潜在的漏洞风险降至最低，并极力捍卫各界利益相关者对我们的信任。通过定期评估、代码深度审计以及系统性地采纳行业最佳安全实践，安全理念已成为我们整个项目生命周期中的核心一环。

我们结合使用自动化和人工审计技术来应对瞬息万变的安全威胁，并不遗余力地优化我们的防御手段，包括计划接入更高级的静态代码分析与依赖分析工具。我们工作的主旨在于实现前瞻性的风险治理，并确保以高度负责任的态度处理任何上报的系统漏洞。

受支持的版本​

主版本号是否依然受支持
main✅
dev❌
其他历史版本❌

在何处以及如何报告安全漏洞​

开发者社区共建寄语

Open WebUI 开发者社区的繁荣昌盛，离不开像您这样热心于推动软件安全、为全体用户筑牢防线的安全专家。

为了确保您的漏洞发现能切实守护广大用户的隐私，并能被核心团队以极快的速度修复，请仅通过我们的 官方 GitHub 安全漏洞入口 提交所有的安全漏洞报告。任何其他网站、外部渠道，或所谓的“第三方众测悬赏”平台均与我们 没有任何关联（NOT affiliated），您提交的重要工作成果将根本无法传达给有权限修改代码的项目核心成员。

我们深知一些开出优渥赏金条件的外部中介平台极具诱惑力，但唯有 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 之外的任何第三方漏洞收集与悬赏平台。任何从这些外部中介渠道流入的漏洞报告或悬赏问询，将被我们一概忽略并直接予以驳回。此项安全策略属于非谈判条款，没有任何例外。

外部 CNA 授权机构与服务商处理声明​

当外部安全人员通过 GitHub Security Advisories（安全公告）通道向我们提交漏洞报告，而被核心维护团队依据本策略判定为“超出规范范畴（out-of-scope）”并执行关闭时，该关闭操作即代表了官方服务商对该安全事件的正式处理声明（vendor's disposition）。如果某个第三方 CVE 编号授权机构（CNA）在此之后执意为该事件强行下发 CVE 编号，且未在其公告中如实体现我们服务商的正式驳回结论，该机构的行为即被判定为违背官方服务商处理声明。

针对此类背离事实强行批复的 CVE 记录，我们将采取以下严厉的反制措施：

  1. 向 CVE 官方组织发起 REJECT（驳回） 申诉请求（如申诉未果，则以 DISPUTED（争议） 作为次级处理方式）。
  2. 在我们的 服务商处理声明 页面中将该违规 CVE 记录公开挂网，并指名道姓点名下发该编号的违规 CNA 机构。
  3. 拒绝向其提供任何官方技术声明、版本匹配映射、漏洞修补关联链接或任何其他配合协助，拒绝为该不实记录背书。
  4. 如果发现某一特定的 CNA 机构存在屡教不改的恶意下发行为，我们将直接向 CVE Program 的根管理机构（Root）提起正式申诉。

漏洞提报通道的合规性，并不赋予 CNA 强行凌驾于官方服务商处理声明之上的特权。 如果漏洞报告人员在官方给出了明确的“非漏洞/超出规范范畴”关闭结论后，依然私下将该事件扩大上报给其他第三方 CNA 机构以强行获取 CVE 编号，该人员将被永久取消向 Open WebUI 报告任何未来漏洞的资格。

漏洞报告指南​

您可以在此处获取最新版本的安全指引。

为了确保漏洞报告具有建设性、技术可操作性，并切实起到提升系统安全性的目的，所有提交的漏洞必须满足以下硬性条件：

  1. 必须是一个真实的系统漏洞：安全漏洞是指系统底层存在设计或实现上的可利用缺陷，导致系统产生违背预期行为的运作，从而允许攻击者绕过既定的安全防火墙、攫取未授权的数据访问、执行任意恶意代码或提升越权。系统正常的配置参数、尚未开发的功能项，以及符合通信协议标准的预期行为，绝对不属于系统漏洞。一个有效的漏洞必须至少突破以下安全屏障之一：机密性（Confidentiality）、完整性（Integrity）、可用性（Availability）、真实性/可信度（Authenticity）、不可否认性（Non-repudiation）。我们对这些屏障的界定极为宽泛，其他安全框架下的对等概念均包含在此范围内。

  2. 拒绝空洞模糊的报告：任何类似于“我发现了系统的漏洞”但未提供任何技术细节的报告，将被视作垃圾邮件直接予以关闭，不予受理。

  3. 要求具备深度技术理解：漏洞提报必须反映出对 Open WebUI 系统源码的清晰认知，并说明漏洞所处的受影响组件、触发机理以及可能产生的安全影响。

  4. 必须附带概念验证（PoC）证明：每一份报告必须附带撰写清晰、步骤详实的 PoC（Proof of Concept）用以还原攻击。PoC 必须直观展示有哪些安全屏障被成功穿透、攻击者是如何实施漏洞滥用的，以及攻击者由此能攫取到哪些权限或操作。可被采纳的 PoC 形式包括：一步步图文并茂的复现指引配以具体的执行指令；可完美独立运行的漏洞利用脚本代码附带详细的运行说明；或者用于辅证复现步骤的屏幕截图与操作视频。若涉及机密敏感信息，提报人员可以在 GitHub 上创建本仓库的私有 Fork，并将核心团队成员拉入共享。任何缺乏强有力复现凭证的报告都将被忽略。如果我们使用您提供的 PoC 无法还原出攻击效果，我们会向您说明；如果经多次反复尝试依然无法成功复现，该漏洞报告将被强制关闭。

  5. 必须附带修复建议（Remediation）：除了 PoC 之外，您在提交时还必须提供一套代码修复补丁/PR，或者一份具体的代码修补方案，让核心开发人员能清晰开展修补而无需靠猜测前行。您的修复方案应当指出：引发漏洞的可能根源（哪里的代码出了什么问题）、需要修改的具体代码路径（若知道，写明对应的文件名/模块名/函数名）、推荐的修复手段（如参数校验过滤规则、鉴权鉴权拦截、安全默认值设定等），以及该修补可能带来的安全折中考量或必须防范的系统功能回退风险。

  6. 在系统默认配置下进行测试：所有的安全漏洞必须能够在 Open WebUI 开箱即用的默认系统配置（out-of-the-box configuration）下完成复现。如果某个漏洞必须依赖管理员手动将其安全防火墙关闭、或故意将其安全参数调弱才能触发，该报告大概率会被驳回。但是，如果您认为您发现的漏洞虽然需要非默认配置配合，但该配置在真实的投产部署中被普遍采用，且它切实实现了对安全防御的绕过，请务必直接向我们提报。本规则的设立是为了过滤配置不当和部署不当引发的非系统缺陷，而不是为了限制正规的安全技术审计。

  7. 必须理解系统设定的威胁模型：漏洞报告必须体现出对 Open WebUI 架构的深度理解——本系统是一个**自托管、强鉴权鉴权、高度可扩展且基于角色权限控制（RBAC）**的技术架构。如果您直接将 Open WebUI 与那些在威胁模型上有着本质差异的云端 SaaS 服务进行生搬硬套的安全性比对，而完全无视两者在底层架构上的差异，您的报告大概率会被直接驳回。

  8. CVSS 漏洞评分必须准确：如果您在报告中自行附带了 CVSS 评分，该分数必须严密遵循 CVSS 评测规范。常见的典型评级错误包括：明明漏洞触发需要用户登录鉴权，却在“所需特权（PR）”维度上强行评级为“无（None / PR:N）”；对完全处于空想状态的复合攻击链进行盲目高评分，而非针对漏洞本身进行平实评估；或者在毫无实质凭证的情况下故意抬高受灾等级。核心团队会对不切实际的评分进行修正。存在恶意虚高评分的报告将被直接驳回。如果您引用其他已存在的 CVE 记录来论证您的发现，请确保它们在漏洞类型、威胁模型和攻击媒介上确实具有技术可比性。如果您引用的 CVE 来自完全不相干的产品线、不相干的漏洞分类或完全不同的网络拓扑，我们将高度怀疑您的报告是由 AI 自动化工具东拼西凑生成的。

  9. 由管理员主动发起的危险操作超出漏洞范畴：如果某个所谓的安全漏洞，必须依赖系统管理员手动去实施一系列不安全的操作才能触发，这不属于 Open WebUI 系统的安全缺陷。管理员在系统中拥有最高掌控权，应当理解并对其发起的每一项配置与操作的安全后果负责。这包括但不限于：管理员手动接入恶意的外部服务器（如模型、工具、Webhooks、Functions 插件）；管理员直接把不可信的恶意 Python 代码复制粘贴到 Functions / Tools 插件的编辑器中；或者管理员主动将内置的安全防护策略关掉。对于依赖于“管理员玩忽职守”或“针对管理员进行社会工程学欺诈”的漏洞提报，我们不予受理并直接驳回。但是，如果您确信发现了一个在管理员未执行任何危险操作、且在系统正常运作时就能危及管理员权限的真实漏洞，请务必直接向我们提报。本规则的设立是为了过滤针对管理员的钓鱼欺诈和部署人员自身的违规操作，而不是为了限制真正的安全研究。

  10. Tools（工具）与 Functions（函数）可以执行代码是系统设计的预期行为：Open WebUI 的 Tools 和 Functions 插件功能，在设计之初就是为了允许在服务器端执行用户自定义的 Python 代码。这是本系统极具含金量的核心设计功能，绝非系统漏洞。只有 administrator（管理员）有权创建和上传 Functions。而 Tools 插件的创建权限，则由 workspace.tools 权限参数控制——该权限对于非 admin 的普通用户在默认情况下是关闭的，且只能授予给在信任级别上等同于系统管理员的极度可信的用户。将 Tools 的创建权限授予某个用户，在安全意义上完全等同于直接向该用户下发了服务器的 Shell（终端命令行）控制权。 更宽泛地讲，凡是涉及 Tools 或 Functions 插件的任何攻击链路报告 —— 包含但不限于代码执行、文件越权读取、发起恶意网络请求、或读取敏感环境变量 —— 将一律被作为“符合设计预期/非漏洞”进行关闭。 无论是直接的代码执行，还是通过 frontmatter 注释块在后台触发的第三方库打包安装（pip install），均适用此排除规则。

  11. 已明示弃用的旧版代码路径（Legacy Code Paths）不予受理：Open WebUI 在官方文档中对部分历史代码路径明确打上了**“Legacy（旧版遗留）”的标签。这些旧版路径之所以依然被留在系统中（有些甚至依然是默认值），纯粹是为了照顾老用户升级时的向后兼容性，这绝不代表它们是目前推荐的或仍在维护的安全防御面。所有的安全加固和功能迭代都会作用于全新的替代架构上，而非这些老旧的遗留路径。如果漏洞提报人员在 legacy 路径下跑通了某项越权，而在官方推荐的替代架构中无法复现**，该报告将直接被判定为超出规范范畴而予以关闭。但如果该越权在 legacy 路径和全新替代架构下均能复现，或者该 legacy 路径是当前系统实现某一特定业务功能的唯一 documented 方式（暂时还未开发出迁移替代方案），我们依然高度欢迎您向我们提交。

  12. AI 生成漏洞报告的透明度声明：由于近期由 AI 编写或润色的劣质漏洞报告呈现出了爆发式的激增，您在提报时必须如实向我们披露您在任何环节上是否有使用 AI 辅助（包含用 AI 组织措辞、用 AI 编写 PoC 脚本，或者用 AI 跑自动化扫包检测）。我们绝不会仅仅因为一份报告带有 AI 协助痕迹就直接粗暴地拒绝它。但是，如果我们高度怀疑您有使用 AI 工具且未向我们进行诚实的主动说明，我们将向您发起一系列深度的专业技术追问，以全面考核您对您上报的漏洞细节以及 Open WebUI 系统本身的真实理解程度。一旦我们有充分的理由怀疑您隐瞒了 AI 的参与，且您提交的报告最终被证实与事实不符、并非系统漏洞或根本无法被成功复现，您将被直接永久取消未来的漏洞提报资格。这是一项被迫采取的安全治理手段，因为近期有大量完全由 AI 编造的劣质报告涌入我们的信箱，其中 99% 的内容其实都是根本不存在漏洞的故障配置，甚至完全没提供 PoC，严重违反了本页声明的各项准则，在行文中充斥着对 Open WebUI 运行机制的极度无知，技术论证前后矛盾，甚至充斥着大量荒谬的技术说辞。

  13. 仅危害提报者自身的安全事件不属于漏洞：一个合格的安全漏洞，必须存在突破安全防线并对提报人之外的其他关联方造成权益侵害的事实。如果提报人员所演示的漏洞，仅仅只能侵害其自身所持有的账号数据、浏览器会话、本地 Cookie 或其自己完全掌控的独立沙盒运行环境，这仅仅是一个系统 Bug，请直接在 GitHub 社区 Bug 追踪器 (Issue Tracker) 下发帖交流，切勿将其作为安全漏洞提交。如果该安全风险能够连带侵害到其他用户、系统运营商、宿主机底层系统或全局共享资源的安全，请在您的 PoC 报告中将这第二方受害者的受灾过程清洗、明确地演示出来。

对于任何违反上述安全规范的漏洞提报，我们将予以直接关闭；对于多次执意提交违规报告的技术人员，我们将直接予以永久拉黑。我们旨在同业界维持一个良性、高度专业且富有建设性的漏洞协同生态，真正有技术价值的漏洞提报配以完备、可直接合并的修复补丁，能够极大缩短我们响应的真空期，让全球的部署人员快速受惠。

如果您因为一些客观技术限制（如涉及超复杂的特定环境），确实无法 100% 凑齐上述提报标准，也请您放心地向我们提交——我们的安全专家会对每一封来信执行仔细核实。

预期的处理时效​

Open WebUI 每天都需要调度和应对海量的漏洞提报、Bug 贴、技术大辩论以及 PR 代码合并申请 —— 特别是近期因为大量 AI 劣质报告的无脑轰炸（参见上文 AI 报告透明度声明），核心团队正承担着前所未有的审核负荷。本项目是由一个精英微型团队在课余和工作之余进行维护，安全漏洞的排查只能与系统核心特性的开发和日常维护工作同步并进。

因此，您的漏洞提报可能需要数周的时间才能顺利走完初审（Triage）、深度复现、编写补丁和发版披露的流程。在这个过程中，系统保持长达数周的静默是完全正常的，这绝对不代表核心团队忽视了您的贡献 —— 仅仅是因为我们眼下的算力与带宽尚未调度到该任务上。一旦您的漏洞被初审认定有效，您会立刻收到我们的确认回执，并在后续的修复推进中持续收到状态更新。如果您的漏洞挂网很久未得到回复且您急需了解状态，随时欢迎您在对应的 Advisory 安全单内留言垂询。

对于我们判定在现实投产中具有广泛深远或灾难性危害的重大漏洞 —— 无论其最终的 CVSS 评分有多低 —— 我们在发布修复版本后的 1 到 2 周内，可能会选择对漏洞的技术细节进行暂时性的机密保护延时发布，以给全球的系统管理员预留出充足的补丁升级时间窗口。

漏洞报告处理流程​

如果您向我们报告了一个真实的漏洞，而该漏洞在此前已被另一位安全专家抢先一步提交，我们将把您的单子作为“重复（Duplicate）”单进行关闭。我们将始终以第一位提报人的漏洞单作为唯一的排障与跟踪主单。核心团队绝不会针对同一个技术安全缺陷签发多份重复的安全公告。

当有多位独立的安全研究员在同一个时间段内，指出了相同的漏洞分类，但各自演示了截然不同的、独立的漏洞利用链路时 —— 例如，通过完全不同的业务接口绕过了同一处越权校验 —— 我们会将这些漏洞链路统筹并入最先提交的主单中，并会在最终发布公告时，将所有作出了独特技术贡献的发现者均并列列为贡献人。最终，官方只会针对该次合并修补签发唯一的一个 CVE 编号。

为什么重复的报告无法获得贡献署名​

我们只对最早的、首位漏洞发现者进行贡献署名，其核心考量如下：

  1. 首位提报人完成了最艰难的破冰工作。在后来的重复单子流入我们的信箱前，初审和修补代码的编写往往已经在快速推进中了。后来的单子无法改变代码修复的最终成果和发版时间表；如果把署名权慷慨地发给所有重复单提报人，是对真正破冰的首发提报人的极度不公。
  2. 对重复单署名会滋生投机倒把的“漏洞洗稿”风气：如果只要提交了相同原理但较晚的报告也能拿到贡献，理性的市场选择就是每天盯着其他社区公开的安全单子，进行技术微调后换个说辞疯狂复刷。我们目前正承受着极大的此类投机行为的侵扰 —— 实行“首发提报人唯一署名制”是目前唯一行之有效的防御策略。
  3. 协同发现与无意义的重复是两码事。只有当不同的安全专家各自贡献了具有独特技术价值的发现时 —— 比如发现并攻破了完全不同的路由端口、影响了完全不同的底层组件，或攻克了前人报告完全没能覆盖到的隐秘分支逻辑 —— 我们才会在公告中进行并列致谢。这属于上文提到的“合并统筹规则”。仅仅是机械性地把前人已提交过的漏洞单再发一遍，绝对不属于协同发现。

机密披露规范​

通过 GitHub Security Advisories 提交的所有安全漏洞，均属于极度隐私且受法律保护的机密信息。在官方将该安全公告面向全球正式公开（Fully Published）之前，提报人被严厉禁止以任何形式向公众泄露该漏洞的任何蛛丝马迹 —— 请注意，这一禁止期限一直持续到安全公告在 GitHub 上 100% 对外公开可见为止，而绝非仅仅到该漏洞被批复了 CVE 编号。

这一机密保护限制无差别适用于所有的网络信息入口，包含但不限于以下渠道：

  • 在 GitHub（或任何其他代码平台）的公共 PR、Issue 讨论区或社区 Discussion 下发表包含蛛丝马迹的留言
  • 在个人的社交媒体、博客文章、技术论坛或任何第三方网站上发帖
  • 在 Discord、Reddit，或任何其他群聊工具、公共社群及网络服务上交流

尚未封口的漏洞细节如果被提前捅向公众，会瞬间置全球成千上万的 Open WebUI 用户于完全不设防的黑客攻击风险下，这严重背离了负责任的漏洞披露道德共识。凡是在官方正式公开披露前，执意私自公开透露任何漏洞细节的提报人，将被永久封杀，核心团队将永远不再受理其提交的任何漏洞。

如果您的技术关切不符合上文声明的漏洞标准、或者压根不是漏洞，但依然与 Open WebUI 的安全加固相关，请移步至以下更契合的交流渠道：

此类不属于系统漏洞但与安全密切相关的事件包括：建议官方调优默认的环境变量以实现开箱即用安全性；提交提升系统防御强度的实践方案；企业部署级安全加固指南的错漏纠正；针对 2FA（双因子验证）、审计日志等可选安全特性的开发请愿；或者任何关于生产环境部署安全的常规咨询。请针对您的具体技术诉求，正确选用合适的交流渠道。

Tools（工具）、Functions（函数）与 Pipelines（管道）安全性​

Open WebUI 提供了近乎无限的系统可扩展性，这一切主要由 Tools（工具）、Functions（函数）（包含 Pipes 管道、Filters 过滤器和 Actions 动作插件）以及 Pipelines 独立管道三大模块提供。它们支持在系统中直接编排用户自定义的 Python 代码。但在攫取这一强大可定制能力的背后，部署人员必须清醒地意识到其对应的安全连带责任。以下官方说明文档页均包含了其各自细分的安全性警告 —— 请务必通读以获取系统性认知：

注意

Tools（工具）、Functions（函数）与 Pipelines（管道）会在您的服务器底层直接执行未经验证的任意 Python 代码。 这在架构设计上是完全符合预期的 —— 也是它们之所以如此强大的原因。但这同时也意味着，这些插件在操作系统层面上拥有与 Open WebUI 后端主进程完全等同的系统资源访问权限。

安全风险与潜在影响​

一旦您在系统中盲目安装了某个 Tools、Functions 或 Pipelines 插件，就相当于直接下发了以下系统级权限给它：

  • 操作系统文件越权读取 — 允许读写任何 Open WebUI 主进程有权碰到的底层机密文件
  • 发起任意网络请求 — 可以连通任意的外部网络服务，使黑客极易通过此通道向外盗取并回传您的数据库与配置秘钥
  • 执行底层系统指令 — 可以通过 subprocess 管道在您的宿主机或容器内直接运行任意的 Shell 指令
  • 读取机密环境变量 — 轻松抓取到您配在系统里的第三方大模型 API key、商业秘钥以及数据库管理员账号
  • 篡改或破坏核心数据库 — 随意读写和污染系统落库的配置数据与聊天记录
  • 掠夺服务器计算资源 — 可以悄悄跑满 CPU/GPU 执行诸如挖矿或其他恶意计算

安全最佳实践​

核心守则对应的安全要求与行为细则
仅从高度可信的渠道下载插件请仅选用官方社区应用商店中经过审核的 Tools/Functions，或者来自于您 100% 信任的开发者的插件
安装前必须执行代码审计在导入任何 Tools/Functions 之前，请务必人工阅读其每一行 Python 代码，彻底搞懂它的运作机制
精简 Workspace 菜单的分配将系统的 Workspace 修改与创建权限牢牢锁在受高度信任的超级管理员手中
定期审计已安装的插件清单养成好习惯，定期清点您系统中已启用的 Tools（Workspace → Tools）和 Functions（Admin Panel → Functions）
严防死守您的本地数据盘/app/backend/data 挂载目录不仅有您的核心数据库，还存放着已缓存的插件代码 —— 必须对该物理路径配置严苛的访问权限
实时监控服务器资源占用密切监视 CPU 占用的异常飙升，这往往是容器被黑客入侵挂载挖矿脚本或发起 DDOS 的标志
必须使用官方发布的 Docker 镜像请仅从 ghcr.io/open-webui/open-webui 或 openwebui/open-webui (Docker Hub) 官方仓库拉取镜像 —— 外部个人打包的非官方镜像极有可能被植入了后门

哪些情况不被认定为漏洞​

以下指出的典型应用场景绝不会被判定为系统漏洞，因为它们完全是由于管理员自身的危险操作或配置错误导致的（参见上文 管理员操作不属于系统缺陷 和 系统威胁模型理解）：

  • 管理员在后台手动下载并运行了一个恶意攻击插件。
  • 管理员盲目把 Workspace 的最高控制权下发给了一个不可信的普通用户。
  • 管理员从一个未经验证的第三方论坛复制并导入了一段危险的代码。
  • 攻击者已经攻破了宿主机的物理防火墙，并攫取了本地数据挂载卷的写入权限，进而篡改了已缓存的插件代码。

更广泛地讲，凡是涉及 Tools 或 Functions 插件的任何攻击链路报告 —— 包含但不限于代码执行、文件越权读取、发起恶意网络请求、或读取敏感环境变量 —— 将一律被作为“符合设计预期/非漏洞”进行关闭。 如果管理员执意把 Tools 创建权限赋予一个不可信的账户，这在性质上属于主观层面的危险配置，不属于软件漏洞。

此类事件只会被归类为管理员的主观玩忽职守或服务器物理环境已被攻破，不属于 Open WebUI 自身的代码安全漏洞。详情请参阅 我们的官方安全策略 以及 插件安全说明文档。

生产环境部署安全规范​

Open WebUI 被设计为应当运行在可信的私有网络（private networks）内，且为了降低新手的搭建门槛，我们发行的默认配置都倾向于宽松。如果您计划将系统投产于需要处理高度敏感业务数据的公网生产环境下，请务必通读 系统加固指南 (Hardening Guide) 逐一落实安全防线。

这里需要重申一个极其关键的技术考量：在未接入 Redis 的情况下，用户的登出行为和修改密码操作并不会让已生成的旧 JWT Token 即刻失效 —— 这些 Token 在长达 4 周的有效期内依然是完全合法的。这意味着一旦用户的 Token 在本地泄露，系统将无法通过登出强制使其失效，管理员即便在后台禁用了该账号，也无法立刻切断该 Token 调取接口的通道。针对生产环境，请务必部署 Redis 服务 以确立 Token 的硬性吊销机制，或者将 JWT_EXPIRES_IN 环境变量调小，以缩短风险敞口的时间窗口。详情请参阅 Token 吊销规范。

产品安全流程​

  • 内部以及周期性委托外部安全机构，对我们的系统整体架构和发布流水线进行安全性审计。
  • 针对前端和后端系统，同时部署自动化扫包和人工渗透测试。
  • 在日常开发中，实施前瞻性的风险管控，并将代码同行评审（Code Review）贯彻到每一次的代码合并中。
  • 持续引入和集成最尖端的静态应用测试（SAST）和动态分析（DAST）工具。

如果您发现了一个迫切需要修复的系统安全威胁，请立刻前往我们的 安全顾问提交页面 或者 Bug 追踪器 提交您的报告。

This content is for informational purposes only and does not constitute a warranty, guarantee, or contractual commitment. Open WebUI is provided "as is." See your license for applicable terms.