文章总结： Coolify被曝存在11个高危漏洞，涵盖命令注入与SSH私钥泄露，攻击者可获取Root权限并逃逸容器接管宿主机。鉴于全球超5万台实例暴露公网，建议立即升级至v4.0.0-beta.451以上版本，限制管理面板公网访问并遵循最小权限原则，以防范服务器被接管的风险。 综合评分： 93 文章分类： 漏洞分析,漏洞预警,云安全

从入门到“被黑”？Coolify 这一波 Command Injection 教科书式漏洞解析

原创

Hankzheng

技术修道场

2026年1月12日 07:57 广东

大家好，在 IT 圈摸爬滚打这么多年，我们总在寻找那个“完美”的工具——既能像 Vercel 那样一键部署，又要像原生 Linux 那样自由可控，关键还得省钱。于是，Coolify 成了这两年我们眼中的“白月光”，被称为自托管界的 Heroku 杀手。

但是，兄弟们，今天这杯咖啡可能有点苦。

就在刚才，安全研究人员一口气丢出了 Coolify 的 11 个致命漏洞。注意，我用的是“致命”这个词，不是吓唬大家。在这 11 个漏洞里，有好几个 CVSS 评分直接拉满到了 10.0（满分）。

这意味着什么？意味着只要黑客稍微动动手指，就能绕过你的防御，拿到 Root 权限，甚至从容器里逃逸出来，直接接管你的宿主机。如果你的 Coolify 是暴露在公网上的（根据数据，全球有 5 万多台这样的机器），那你现在的处境非常危险。

今天，咱们不谈虚的，我就带大家从技术角度扒一扒，这波漏洞到底是怎么炸的，以及为什么这次的“翻车”如此严重。

01 灾难现场：当“命令注入”遇上“高权限”

这次曝光的漏洞列表，简直就是一本《命令注入（Command Injection）实战指南》。

大家知道，Coolify 的核心优势是自动化——它帮我们在服务器上自动执行 Docker 命令、配置 Nginx、管理数据库。而这种“自动化”的背后，往往意味着程序需要频繁地调用底层系统 shell。

只要输入过滤不严，灾难就来了。

这一次，Coolify 在多个关键功能点上都“失守”了：

⚠️ 数据库备份与导入：容器逃逸的温床

CVE-2025-66209 / CVE-2025-66210 (CVSS 10.0)

这两个漏洞评分全是满分。问题出在数据库的备份和导入功能上。

• 技术原理：

  当你作为一个有权限的用户去执行数据库备份时，后端代码直接将你的参数拼接到了 shell 命令中。

• 严重后果：

  攻击者可以利用这个入口，执行任意系统命令。最可怕的是，这不仅仅是在容器内执行，攻击者可以利用这种特权操作实现 Container Escape（容器逃逸），直接控制宿主服务器。这是所有云原生架构的噩梦。

⚠️ PostgreSQL 初始化与代理配置：Root 提权

CVE-2025-66211 / CVE-2025-66212 (CVSS 10.0)

这又是一组满分漏洞。

• 技术原理：

  在初始化 PostgreSQL 脚本或配置动态代理时，Coolify 没有严格清洗用户输入。

• 底层逻辑：

  这些操作通常需要以 Root 身份在服务器上运行。一旦黑客在这里注入了恶意指令（比如反弹 Shell），他们拿到的直接就是 Root 权限，而不是一个低权限的普通用户 Shell。这意味着他们可以安装后门、窃取所有应用的数据、甚至把你的服务器变成矿机。

02 令人窒息的操作：SSH 私钥泄露

如果说上面的 RCE（远程代码执行）还需要点技术含量，那这个漏洞简直就是“送人头”。

CVE-2025-64420 (CVSS 10.0)

研究人员发现，一个低权限的用户（Low-privileged user）竟然可以查看 Coolify 实例中 Root 用户的私钥！

这在安全架构上是绝对的禁忌。

一旦拿到了 Root 私钥，攻击者根本不需要搞什么复杂的注入，直接开个终端 ssh root@your-server -i stolen_key 就进去了。这就像是你给家门装了防盗窗，结果把大门钥匙挂在了门把手上。

03 更多攻击面：无孔不入的 Docker Compose

还有几个漏洞（CVE-2025-64419 等）涉及到了 docker-compose.yaml 文件的处理。

很多开发者习惯直接复制粘贴 Docker Compose 配置。Coolify 允许用户通过 Git 源或直接输入来定义这些配置。

• 攻击向量：

  攻击者可以在 YAML 文件中通过特定的指令或在 Git 仓库字段中注入 Shell 命令。

• 底层逻辑：

  当 Coolify 解析并执行这些 Compose 文件时，它会调用底层的 Docker 引擎。如果此时注入了恶意的 OS 命令，这些命令就会在底层宿主机上以高权限执行。

04 你的服务器还安全吗？

根据 Censys 的数据，截至 2026 年 1 月 8 日，全球大约有 52,890 个 Coolify 实例暴露在公网，其中美国和德国是重灾区，但国内肯定也有不少极客在用。

虽然目前还没有大规模的“野外利用”（In the wild）报告，但你要知道，漏洞详情一旦公开，脚本小子们的扫描器马上就会跟进。对于这种 RCE 级别的漏洞，从公开到被大规模利用，通常也就是几天的时间差。

05 自救指南

如果你的团队正在使用 Coolify，请立即执行以下操作：

1. 马上升级！马上升级！

• 绝大多数 RCE 漏洞在 v4.0.0-beta.451 及以上版本中已修复。
• Docker Compose 相关漏洞修复于 v4.0.0-beta.445。
• 一定要检查你的版本号，不要抱有侥幸心理。

1. 隔离访问

• 如果可以，不要把 Coolify 的管理面板直接暴露在公网。通过 VPN 或者 SSH 隧道访问管理后台。

1. 最小权限原则

• 这次很多漏洞的前提是“Authenticated User”（已认证用户）。检查你的团队成员权限，不要给不必要的人员（或被攻破的低权限账号）开启数据库管理或服务器管理权限。

写在最后

Coolify 依然是一个很棒的开源项目，它降低了 DevOps 的门槛。但这次事件也再次给我们敲响了警钟：便捷性和安全性往往是成反比的。

开源软件虽然代码透明，但不代表它天然安全。作为技术负责人，我们在享受开源红利的同时，必须时刻保持对安全更新的敏感度。毕竟，服务器是你自己的，数据丢了，开源社区可不负责赔偿。

如果你觉得这篇文章帮你看清了风险，请点赞并转发给你身边的运维和开发朋友。

免责声明：

本文所载程序、技术方法仅面向合法合规的安全研究与教学场景，旨在提升网络安全防护能力，具有明确的技术研究属性。

任何单位或个人未经授权，将本文内容用于攻击、破坏等非法用途的，由此引发的全部法律责任、民事赔偿及连带责任，均由行为人独立承担，本站不承担任何连带责任。

本站内容均为技术交流与知识分享目的发布，若存在版权侵权或其他异议，请通过邮件联系处理，具体联系方式可点击页面上方的联系我。

本文转载自：技术修道场 Hankzheng《从入门到“被黑”？Coolify 这一波 Command Injection 教科书式漏洞解析》