cPGuard 更新被投毒：服务器打完补丁，为什么还要换 SSH 密钥？

被信任的更新，为什么会变成入口？

服务器上的安全软件通常需要高权限：它要读取日志、扫描文件，也要更新自己的规则和程序。管理员一旦允许它自动更新，软件就会从厂商渠道取回新文件并执行。这次被利用的正是这条原本用于防护的路径。

cPGuard 开发商 OPSSHIELD 披露，攻击者进入其计费和授权系统，取得用于发布更新的密钥，随后通过正常更新渠道分发恶意版本。厂商后续调查称，恶意更新约在 11 月 2 日 02:08 至 03:20 UTC（北京时间 10:08 至 11:20）被约 2,950 台客户服务器安装并以 root 运行。这个数量来自厂商披露，不代表每台机器的所有凭据都已被证明外传。

最初入口的具体请求仍未确认。厂商提到攻击者先注册试用账号并探测计费应用，但没有公开足以证明这次攻击由 AI 自主完成的证据。

先看历史，不要只看现在的版本

受影响的是 5.88.12 至 5.88.19 这些更新。如果机器现在已经自动升到新版本，当前版本号只能告诉你现在运行什么，不能抹掉之前安装过恶意更新的事实。厂商建议查看安装日志中的成功更新记录：

在输出中查找 5.88.12 到 5.88.19。出现这些版本，说明安装过受影响更新，应按可能失陷处置；它本身不能证明具体哪些文件被读取或外传。反过来，查不到记录、日志缺失或不完整，也不能证明安全。日志可能使用服务器本地时区，不能直接把每条时间当成 UTC。

grep 'Successfully updated' /opt/cpguard/logs/install_log

脚本拿走的是什么？

厂商披露的目标包括本地账户密码哈希、root SSH 文件、MySQL root 配置和 root 的 shell 历史；后者可能包含人工输入过的密码、令牌或连接命令。厂商后续披露还提到部分机器上的云存储密钥，以及留下的隐藏 root shell 和计划任务。不同服务器实际被收集和取走的内容并未逐台确认。

密码哈希不是明文密码，但弱密码可能被离线猜出；数据库配置、SSH 私钥和历史记录中的令牌则可能直接用于访问其他系统。厂商早期公告估计攻击者确认取回 32 份收集文件，这是当时确认取回的估计，并非受影响服务器总数，也不是其他机器一定没有泄露的证明。

更新软件之后，凭据怎么办？

厂商早期公告要求升级至 5.88.25 或更高版本；后续事件披露列出清理隐藏 shell 的 5.88.26 和移除计划任务的后续更新。应核对厂商最新公告与更新结果，确认已完成其列出的清理步骤。升级能清除已知残留，却不能让已经复制出去的密钥自动失效。

如果恶意更新曾运行或无法排除，先保留必要证据并从可信的管理或恢复环境处理：重置可能受影响的本地账号密码，轮换数据库和云服务凭据，替换可能暴露的 SSH 私钥，并从所有信任旧公钥的目标服务器上撤销它。关联机器是否受影响需要分别排查，单纯在原服务器生成新密钥并不会自动删除其他服务器上的旧授权。

对于计费门户账户，厂商称账户资料及 bcrypt 密码哈希被复制，建议用户重置门户密码并启用双重验证。若发现额外入侵、无法建立系统完整性，或厂商通知有人手动登录服务器，应升级为完整应急响应并评估从可信备份重建；厂商早期说法并未要求所有机器一律重装，后续披露对被人工登录的机器提出了重建要求。

不要只找几个文件就宣布安全

厂商列出的恶意脚本、临时目录和计划任务可帮助缩小排查范围，完整路径及适用范围见事件披露。清理更新执行后，已知文件可能已经消失；没有找到它们不能证明脚本从未运行。厂商还把部分更复杂的植入指标明确标注为其内部服务器发现，不能直接当成每台客户主机都存在的证据。

如果不使用 cPGuard，这次受污染的更新本身并不意味着服务器中招。使用 cPanel、Plesk 或其他面板也不等于一定安装了 cPGuard；应先核实实际安装的软件，再判断是否需要进入这套处置流程。本文依据厂商公告整理，未在第三方服务器运行命令或复现。