ComfyUI 的四个高危漏洞与为什么必须升到 0.28.0
如果你的 ComfyUI 还停在 v0.27.0 或更早，这篇的结论可以先看：升。这是关于 ComfyUI 少有的一条能说得这么硬的建议，因为它不是我的判断，是官方安全公告直接给出的结论——四条 GitHub Security Advisory，严重等级全是 high，修复版本全是 0.28.0。
但「升到 0.28.0」并不是终点。这篇想把话说完整：这四条公告我们到底知道什么、不知道什么；除了升级还有哪些官方开关可用；以及一个挺有意思的后续——0.28.0 的这次安全修复自己带出了一个前端回归，两周后才在 v0.30.0 修掉。
一、先把「我们知道什么」划清楚
这一段很关键，请先看完再看下面的表。
我们从 Comfy-Org/ComfyUI 的 GitHub Security Advisories 里取到的，只有四项字段：GHSA 编号、severity、summary、published_at，以及修复版本。
我们没有取到 CVE 编号、没有 CVSS 分值、没有详细的技术分析、也没有官方给出的缓解建议。 所以这篇文章里不会出现「这个漏洞的 CVSS 是几分」「攻击者可以这样构造请求」「不能升级的话可以先这样绕过」——这些我们一个字的依据都没有。同样地，漏洞的利用方式、payload、复现步骤，本文不会写，也请你不要从 summary 的字面去反推着自己试。
能确定的只有一句：运行 v0.28.0 之前版本的实例，存在下面这四个 high 级问题。
二、四条公告本身
四条全部发布于 2026-07-15，severity 均为 high，patched 版本均为 0.28.0。
| GHSA ID | 严重等级 | 官方 summary（原意） | 修复版本 |
|---|---|---|---|
| GHSA-rj8c-c4p8-3c5h | high | 经 /view 端点上传 SVG 文件导致的存储型 XSS | 0.28.0 |
| GHSA-53g8-45wq-pcv8 | high | /userdata/{file} 缺少 Content-Type 处理导致的存储型 XSS | 0.28.0 |
| GHSA-rvxv-29p8-pxgq | high | LoadImage 经 /prompt API 的路径穿越，可用于任意探测文件是否存在并外泄图片 | 0.28.0 |
| GHSA-pj59-g5vv-74q4 | high | /experiment/models/preview 的路径穿越，可任意读取图片文件 | 0.28.0 |
对应的 release note 条目在 v0.28.0（2026-07-15）里，写的是「security: fix four vulnerabilities (GHSA-779p-m5rp-r4h4)」，对应 PR #14734。注意 release note 里给的这个编号和上表四条 ID 不是同一个，所以对着 release note 找这四条会对不上号，认 PR #14734 这条线索更稳妥。
顺带说一句时间线上的背景：SECURITY.md 是 v0.22.0（2026-05-20）才加进仓库的，v0.23.0（2026-06-01）有一条「Repo security stuff.」（PR #14019）。也就是说，安全响应流程本身在这个项目里也是近期才成形的。这不是黑它——一个 125.2k star 的项目，开放 issue 有 4k 条，安全流程后补是常态。但它意味着：你不能假设更早的版本里没有类似问题只是没人报。
三、决策路径：你手上是什么实例
不要一上来问「我该开哪些参数」，先问「我这台是干什么用的」。下面四种处境，处置完全不同。
处境 A：本机自用，浏览器和服务在同一台机器上。
这是风险面最小的一种。--listen 的默认值是 127.0.0.1，按参数语义就是只监听本机，你不主动改，服务不会往局域网或公网上听。但请注意「风险面小」不等于「不用升」：上表里有两条是存储型 XSS，触发点在你自己的浏览器里，跟服务是否对外监听不完全是一回事。所以 A 的结论是：照样升，优先级可以排在 B/C 之后。
处境 B：局域网内多人共用一个实例。
你多半已经用了 --listen。这里有个很容易踩的点：--listen 不带参数时等于 0.0.0.0,::，即监听所有 IPv4 与 IPv6 网卡，不是只监听你想的那一张网卡。再叠加 --enable-cors-header 不带参数时默认是 *（允许所有来源），暴露面比很多人以为的要大。B 的结论：尽快升，并且回头核一遍自己启动脚本里这两个参数到底带没带值。
处境 C：公网可达。 这一档我只能给出官方参数语义层面的事实，不打包票。
- TLS 需要
--tls-keyfile与--tls-certfile成对给出才生效，只给一个不会启用。 - README 提供了自签证书的生成命令，同时明确注明该自签证书 “not appropriate for shared/production use”（不适合共享或生产使用）——这句是官方自己写的，别当没看见。
- 用户名密码认证在官方仓库里仍然是一个 open 的 feature request（issue #987，创建于 2023-07-27，标签 Feature，截至 2026-08-09 仍为 open）。另一方面 v0.23.0 确实新增过 OAuth 2.1 + RFC 7591 DCR 端点（PR #14026）。这两件事不矛盾，但都不足以让我替你下「ComfyUI 有/没有鉴权」的断言。
至于反向代理、防火墙、加一层网关认证这些做法——那属于通用运维做法，不是 ComfyUI 官方文档里的内容，我不会把它包装成「官方推荐配置」写给你。C 的结论：先升，然后把「公网直接暴露」这件事本身重新评估一遍。
处境 D：接进了生产流程，或者装了一堆第三方自定义节点。 自定义节点是另一条独立的风险线，跟这四条 GHSA 无关。社区在 issue #11791 中报告了通过 Comfy Registry 分发的、名为 Upscaler_4K 的自定义节点携带 Akira Stealer 的情况，该 issue 创建于 2026-01-10，截至 2026-08-09 仍为 open。这条我只能说到这里：我们没有读过 issue 正文与评论，所以它的具体行为、感染链、清除方法，本文一概不写。
官方在 comfy/cli_args.py（v0.31.0）里给了几个直接相关的开关，这是硬事实：
| 手段 | 参数 | help 原意 |
|---|---|---|
| 全部禁用自定义节点 | --disable-all-custom-nodes | 不加载任何自定义节点 |
| 白名单放行 | --whitelist-custom-nodes NAME [...] | 在上一条开启时仍加载指定目录 |
| 关闭 API 节点与前端联网 | --disable-api-nodes | 不加载 api 节点，同时阻止前端与互联网通信 |
| 只关 Manager 的 UI | --disable-manager-ui | 只禁 Manager UI 与端点，后台任务仍运行 |
由这几条参数的语义可以直接推出一个可执行动作：用二分法定位自定义节点。 先加 --disable-all-custom-nodes 启动，如果起得来、问题消失，说明问题在自定义节点侧；再用 --whitelist-custom-nodes 逐个目录放行，缩到具体是哪一个。
--disable-manager-ui 有个容易误读的地方：它只禁 Manager 的 UI 与端点，README 说后台任务（包括安全检查、计划安装的完成动作）仍然在跑。别把它当成「Manager 彻底关了」。
D 的结论：升级只是其中一件事，自定义节点这条线要单独盘。
四、升到 0.28.0 就够了吗
严格按公告说，四条的 patched 版本是 0.28.0，升到 0.28.0 这四条就修了。但如果你正在决定「升到哪一版」，有两条后续值得一起看。
第一条，PR #14734 引出了一个回归。v0.30.0（2026-08-03）的 release note 里有一条「Fix user.css loading broken by #14734」（PR #15000）——也就是说，那次安全修复顺手弄坏了 user.css 的加载，两周后才修回来。这是个挺真实的教训：安全修复不是纯粹的加法，收紧文件访问路径这类改动，很容易连带影响到本来就走同一条路径读取的正常前端资源。按 release note 的时间线推，这个回归引入于 0.28.0、修复于 v0.30.0，中间的 0.29.x 区间也在其中；如果你自定义过 user.css，停在这个区间就有可能碰上它。至于回归的具体表现和影响范围，release note 只给了这一行，我们不往下编。
第二条，v0.30.0 还有一条同方向的变更：「Add dataset folder to avoid arbitrary folder access for dataset stuff.」（PR #14807）。方向和四条 GHSA 里的路径穿越是一致的——把可访问范围收进一个明确的目录。
所以按处境给版本建议：
- 只想尽快脱离已知 high 级问题，且不改 user.css → 0.28.0 已达成公告口径。
- 用了自定义 user.css → 直接去 v0.30.0（2026-08-03）或更新，避开那个回归。
- 没有特殊约束 → 跟当前 stable，本文核对时是 v0.31.0（2026-08-08）。
有一条 README 的规则要一起记住：ComfyUI 大约每 2 周发一个 major stable 版本，而且 stable release tag 之外的 commit 可能非常不稳定，会弄坏很多自定义节点。所以「升级」请升到 tag，别顺手跟 master——你为了修安全问题去跟 master，很可能换来一堆节点报错。
五、这些维度我们不比
为了不误导，明确列一下本文回避的东西：
- 四条漏洞谁更严重：官方给的 severity 都是 high，没有 CVSS 分值，没有可比的量化维度，本文不比。
- 升级后还剩多少风险：没有任何依据能回答，也不存在「这样配就没事了」的结论。官方提供了上面这些开关，仅此而已。
- 其它自定义节点是否安全：除 issue #11791 中被报告的那一个，本文不点名任何节点。
- 0.28.0 之前的版本是否还有别的未披露问题：无从判断。
写这篇的目的很简单：把「必须升到 0.28.0」这条为数不多的硬结论说清楚，同时把「我们只有 summary」这个边界摆在明面上。安全类内容最怕的就是作者在没有依据的地方替读者做决定。
延伸阅读
本文依据 ComfyUI 官方仓库（github.com/Comfy-Org/ComfyUI）的 README、comfy/cli_args.py、
release notes 与官方安全公告整理，核对日 2026-08-09，对应版本 v0.31.0；
文中引用的 issue 状态为该日期的快照。本文内容为官方文档与源码口径，非本机实测。
参数、默认值与功能随版本变动，请以官方文档与 python main.py --help 的实际输出为准。
安全公告信息来自 GitHub Security Advisories，本文不含漏洞利用细节。