1. 一个模型地址引发的连锁反应

把大模型对话界面部署到内网，图的就是数据不出域、调用链路自己说了算。很多人选 Open WebUI，就是看中它开箱即用、界面清爽、能对接各种后端推理服务。但我在实际部署和复盘安全事件的过程中发现一个很反直觉的现象：真正被攻破的入口，往往不是复杂的越权逻辑，也不是什么高深的注入技巧，而是一个看起来人畜无害的配置项——模型地址。

标题里说的“只填了个模型地址，5 秒就被接管”，听起来像标题党，但拆开来看，它描述的是一条完整的攻击链：攻击者通过一个可控的模型服务地址，让 Open WebUI 主动去连接、去拉取、去执行，最终拿到服务端权限。整个过程不需要你点任何可疑链接，也不需要你装任何插件，只要那个地址被填进去，剩下的就是时间问题。

这篇文章我打算把这条链路从头到尾拆一遍，重点讲清楚三件事：第一，为什么一个模型地址能变成攻击入口；第二，这条链路在真实环境里是怎么一步步走通的；第三，为什么这个漏洞在披露时被“拒了 CVE”，以及这个“被拒”背后暴露出的、比漏洞本身更值得警惕的认知偏差。适合正在用 Open WebUI 做内网部署的运维、后端开发，以及任何对 AI 应用安全边界感兴趣的人。

需要先说明的是，下面涉及的所有地址、服务名、路径都做了脱敏和虚构处理，只保留技术逻辑，不指向任何真实环境。你如果在自己的部署里看到类似结构，请直接对照排查。

2. 模型地址为什么能变成攻击入口

2.1 Open WebUI 的模型连接机制到底做了什么

要理解这条链路，得先搞清楚 Open WebUI 在“填模型地址”这个动作背后到底干了什么。它不是一个简单的 HTTP 客户端，把请求转发出去就完事。Open WebUI 支持对接多种后端，包括兼容 OpenAI 接口规范的服务、本地推理框架、以及一些自定义的模型网关。当你把一个地址填进配置里，它做的事情大致分三步。

第一步是连通性探测。它会向这个地址发起请求，确认对方是不是一个可用的模型服务。这个探测请求通常走的是标准的模型列表接口或者健康检查接口。第二步是能力协商。它会根据对方返回的元数据，判断支持哪些模型、哪些参数、哪些能力，然后把这些信息渲染到前端界面上。第三步是会话代理。用户在前端发起的每一次对话，都会经由 Open WebUI 的服务端转发到你填的那个地址，再把结果拿回来展示。

问题就出在第二步和第三步之间。能力协商阶段，Open WebUI 会信任对方返回的内容，并据此构建后续的请求。如果这个地址是攻击者控制的，那么对方返回的就不只是模型列表，还可以是一组精心构造的响应，诱导 Open WebUI 在后续请求中带上不该带的东西，或者去访问不该访问的地方。

2.2 从“可信配置”到“可控输入”的认知错位

大多数部署者会把“模型地址”当成一个配置项，而不是一个输入项。配置项意味着什么？意味着它是我自己填的，是我信任的，不会变。但实际情况是，在很多部署场景里，这个地址的来源并不完全可控。

比如团队协作场景，多个成员共用一套 Open WebUI，管理员可能允许有权限的成员自行添加模型后端。再比如一些自动化部署脚本，模型地址是从环境变量或者配置中心读取的，而配置中心的写入权限可能比想象中宽松。还有一种更隐蔽的情况：地址本身是内网可信地址，但那个地址背后的服务被攻击者以某种方式影响了，返回了恶意内容。

一旦“模型地址”从可信配置变成了可控输入，整个信任模型就塌了。Open WebUI 服务端会带着自己的身份、自己的网络位置、自己的权限，去访问这个地址。攻击者不需要直接攻破 Open WebUI，只需要让 Open WebUI 主动来找自己，就能借它的手完成很多事情。

2.3 服务端请求伪造在这里的典型形态

这条链路的核心，是服务端请求伪造的一个变种。传统意义上的服务端请求伪造，是攻击者让服务端去访问一个内网地址，从而探测内网结构或者读取内网资源。但在 Open WebUI 这个场景里，它多了一层：服务端不仅会去访问你指定的地址，还会把访问结果解析、渲染、甚至执行。

我把它拆成三个层次来看。最浅的一层是信息泄露，攻击者通过控制模型地址，让 Open WebUI 去请求内网某个服务的接口，把返回内容通过模型列表或者错误信息带出来。中间一层是资源滥用，攻击者让 Open WebUI 去请求一个计算密集型的接口，消耗服务端资源。最深的一层是代码执行或者权限提升，攻击者构造的响应内容触发了 Open WebUI 在处理模型元数据时的某个解析缺陷，最终在服务端执行了任意代码。

标题里说的“5 秒就被接管”，指的就是最深这一层。从地址被填入，到服务端被控制，中间的时间窗口非常短，因为整个链路是自动化的，不需要人工交互。

3. 五秒接管链路的分步还原

3.1 第一步：地址填入后的自动探测

假设攻击者已经通过某种方式，让一个恶意地址进入了 Open WebUI 的模型配置。这个“某种方式”可能是社工、可能是配置接口的弱权限、也可能是供应链环节的污染，这里不展开。重点是地址进去之后发生了什么。

Open WebUI 在保存配置或者重启服务时，会触发一次自动探测。这个探测请求发向攻击者控制的地址，请求内容里包含了 Open WebUI 自身的版本信息、可用的模型列表接口路径、以及一些默认的请求头。攻击者收到这个请求后，立刻就能确认两件事：目标存活，以及目标版本。

这一步通常在地址填入后的极短时间内完成，因为很多部署方式是保存即生效，或者有定时健康检查。攻击者不需要等待，探测是自动来的。

3.2 第二步：恶意响应中的元数据投毒

探测请求到达攻击者服务器后，攻击者返回一个精心构造的响应。这个响应表面上是一个合法的模型列表，里面包含几个看起来正常的模型名称。但在这些正常内容之外，响应里还夹带了一些额外的字段。

这些额外字段的作用，是影响 Open WebUI 后续的行为。比如，响应中可能包含一个指向内网地址的模型端点，诱导 Open WebUI 在后续请求中把内网地址当作模型服务来访问。再比如，响应中的某个字段值被构造成包含路径穿越字符，当 Open WebUI 用它来拼接本地文件路径时，就会读到不该读的文件。

这一步的关键在于，Open WebUI 对模型服务返回的元数据缺乏足够的校验。它默认对方是可信的，返回什么就信什么。这种信任在正常场景下没问题，因为模型服务通常是自己部署的。但一旦地址可控，信任就变成了漏洞。

3.3 第三步：会话代理阶段的请求重放与权限借用

元数据投毒完成后，攻击者等待用户发起一次对话。用户在前端输入内容，Open WebUI 服务端按照配置，把请求转发到攻击者控制的地址。攻击者此时可以做的，不只是返回一个模型回复。

由于 Open WebUI 的服务端在转发请求时，会带上自己的身份凭证、会话信息、以及可能的内部令牌，攻击者可以在响应中构造一些内容，诱导 Open WebUI 在后续的内部请求中使用这些凭证去访问其他接口。这就好比攻击者拿到了 Open WebUI 的工牌，虽然不能直接进大门，但可以让 Open WebUI 自己拿着工牌去刷各个门禁。

这一步是权限借用的核心。攻击者不需要窃取凭证，只需要让凭证的持有者主动为自己服务。

3.4 第四步：从元数据解析到服务端执行的跨越

最后一步，是把前面的信息收集和权限借用，转化为实际的服务端执行。这通常依赖于 Open WebUI 在处理某些特定格式的模型响应时，存在解析缺陷。比如，某个字段被当作模板来渲染，而模板引擎允许执行表达式；或者某个字段被当作文件路径来读取，而路径没有做足够的限制。

攻击者构造的响应触发这个缺陷后，服务端就会执行攻击者指定的操作。这个操作可能是写入一个文件、可能是发起一个反向连接、也可能是直接启动一个进程。由于 Open WebUI 服务端通常以较高权限运行，这一步完成后，攻击者就拿到了服务端的控制权。

整个链路从地址填入到执行完成，在自动化工具的支持下，确实可以在数秒内走完。标题里的“5 秒”是一个形象的说法，强调的是这条链路的自动化和低交互特性。

4. 被拒 CVE 背后的判定逻辑与争议

4.1 为什么这个漏洞没能拿到 CVE 编号

这条链路被披露后，并没有顺利拿到 CVE 编号，而是被拒绝了。拒绝的理由，根据我了解到的信息，主要集中在“攻击者需要先具备配置模型地址的权限”这一点上。CVE 的判定机构认为，如果攻击者已经能修改模型地址配置，那么他本身就已经具备了一定的权限，这个漏洞更像是权限滥用，而不是一个独立的、可从外部直接触发的安全缺陷。

这个判定逻辑有它的道理。CVE 的核心是标识一个可以被独立利用的漏洞，如果利用前提是攻击者已经拥有高权限，那么漏洞的严重性就会被打折扣。但问题在于，这个判定忽略了一个关键事实：在很多实际部署中，修改模型地址配置的权限，并不等同于服务端控制权限。

4.2 “需要高权限”这个前提在真实部署中站不住脚

我见过不少 Open WebUI 的部署方式，模型地址的配置权限往往比想象中宽松。有的团队为了图方便，把配置接口开放给了所有登录用户；有的部署把配置文件放在了共享目录里，任何能访问该目录的进程都能改；还有的通过环境变量注入，而环境变量的管理权限和容器管理权限是分离的。

在这些场景里，一个只有“配置模型地址”权限的普通用户，就能触发整条攻击链，最终拿到服务端的完整控制权。这显然是一个权限提升的过程，而不是简单的权限滥用。CVE 的判定把这个过程简化成了“你已经有权限了，所以不算漏洞”，这在逻辑上是有漏洞的。

4.3 被拒之后，风险并没有消失

被拒 CVE 带来的最大问题，不是漏洞本身没被记录，而是它给部署者传递了一个错误的信号：既然没拿到 CVE，那可能不严重。这种认知偏差比漏洞本身更危险。

我在实际排查中发现，很多团队在得知“没有 CVE”之后，就把这件事放下了，既没有去检查自己的模型地址配置权限，也没有去限制 Open WebUI 服务端的出站访问。结果就是，漏洞依然存在，只是没人再提了。

这里我想强调一个观点：CVE 编号是漏洞严重性的一个参考，但不是唯一标准。一个漏洞是否值得修复，取决于它在你的部署环境里能不能被触发，而不是取决于它有没有编号。被拒 CVE 的漏洞，往往是因为判定标准的局限，而不是因为风险真的低。

5. 部署侧的真实排查与加固路径

5.1 先确认你的模型地址到底谁能改

加固的第一步，不是去改代码，而是去理清楚权限。你需要回答几个问题：当前部署里，模型地址是通过什么方式配置的？是配置文件、环境变量、还是管理接口？这些配置方式的写入权限，分别掌握在谁手里？

如果是管理接口，去看接口的鉴权逻辑，确认是不是所有登录用户都能调用。如果是配置文件，去看文件的属主和权限位，确认是不是只有服务账户可写。如果是环境变量，去看容器的启动参数和编排配置，确认环境变量的注入来源是否可控。

这一步的目标，是把“模型地址”从一个可能被多人影响的输入，收敛成一个只有极少数人可改的配置。收敛之后，攻击面就小了一大半。

5.2 限制服务端出站访问的实操配置

第二步是限制 Open WebUI 服务端的出站访问。即使模型地址被恶意修改，如果服务端根本访问不到攻击者的地址，链路也走不通。

具体做法是，在容器或者主机层面，配置出站访问控制。只允许 Open WebUI 访问明确需要的地址和端口，其他一律拒绝。比如，如果模型服务部署在同一个内网的某个固定地址，那就只放行那个地址。如果模型服务在公网，那就只放行那个域名解析后的地址段。

这里有一个实操细节：很多部署者会用域名而不是 IP 来配置模型地址，因为域名更灵活。但域名解析是可以被影响的，如果 DNS 被污染，域名可能解析到攻击者的地址。所以，如果条件允许，尽量用 IP 加端口的方式配置，并且在出站规则里写死。如果必须用域名，那就把域名解析结果固定下来，或者在内网 DNS 里做静态记录。

5.3 模型响应内容的校验与隔离

第三步是在 Open WebUI 这一侧，对模型服务返回的内容做校验和隔离。这一步需要改代码或者加中间层，难度比前两步高，但效果也更彻底。

校验的思路是，对模型服务返回的元数据做白名单过滤。只接受已知的、必要的字段，其他字段一律丢弃。对于字段值，做格式校验，比如模型名称只允许字母数字和连字符，不允许路径分隔符和特殊字符。对于响应中出现的地址，做协议和网段校验，拒绝内网地址和非预期协议。

隔离的思路是，把模型服务的响应处理放在一个受限的环境里。比如，用一个独立的进程或者容器来处理模型响应，这个环境没有访问敏感文件系统的权限，也没有发起网络请求的权限。这样即使响应里有恶意内容，影响范围也被限制住了。

5.4 日志与告警：让异常连接无处藏身

最后一步是补上可观测性。前面三步是预防，这一步是发现。你需要知道 Open WebUI 服务端在什么时候、向哪个地址、发起了什么请求。

具体做法是，在出站访问控制层记录日志，把所有被拒绝的连接记下来。在 Open WebUI 的应用日志里，记录模型地址的变更历史和探测请求的结果。然后配置告警，当出现向非预期地址的连接尝试时，及时通知。

这一步的价值在于，它不仅能发现攻击，还能发现配置错误。很多时候，模型地址被改并不是因为攻击，而是因为误操作。有了日志和告警，误操作也能被及时发现和纠正。

6. 从这条链路里能带走的通用经验

6.1 配置项和输入项的边界要划清楚

这条链路给我最大的启发，是配置项和输入项的边界问题。在开发者的心智模型里，配置项是可信的，输入项是不可信的。但实际部署中，很多配置项的来源并不可信，只是被当成了可信的。

我的经验是，凡是能被外部影响的配置，都要按输入项来对待。模型地址能被管理接口改，那它就是输入项。数据库连接串能被环境变量注入，那它也是输入项。对待输入项，就要做校验、做过滤、做隔离，不能因为它叫“配置”就放松警惕。

6.2 服务端的出站请求是最容易被忽视的攻击面

大多数安全讨论都集中在入站请求上，怎么防注入、怎么防越权、怎么防文件上传。但出站请求同样重要，甚至更危险。因为出站请求是服务端主动发起的，它带着服务端的身份和权限，一旦被利用，攻击者就能借刀杀人。

我现在的习惯是，任何服务端组件，只要它会发起出站请求，我都会问三个问题：它能访问哪些地址？这些地址是谁决定的？如果地址被改，最坏的结果是什么？这三个问题问完，很多隐患就浮出来了。

6.3 没有 CVE 不等于没有风险

最后一点，也是我最想强调的。CVE 是一个有用的参考，但它不是安全工作的全部。一个漏洞有没有 CVE，取决于披露流程和判定标准，不取决于它在你的环境里能不能被利用。

我见过太多团队，把“有没有 CVE”当成“要不要修”的唯一标准。有 CVE 就紧急修复，没 CVE 就放着不管。这种做法的风险在于，它把安全决策外包给了一个不掌握你环境信息的第三方机构。真正应该问的问题是：这个漏洞在我的环境里，需要什么前提才能触发？这些前提我能不能控制？如果控制不了，最坏的结果是什么？

把这些问题回答清楚，比拿到一个 CVE 编号更有价值。毕竟，攻击者不会因为一个漏洞没有编号就不去利用它。