cPGuard 更新通道被投毒 我按厂商通告理了一份 Linux 主机自查单

起因是群里有人贴了 OPSSHIELD 发给客户的那封邮件截图。我第一反应是“又一个供应链投毒”，划过去就算了，后来看到里面有一句 Complete this step even if the update succeeds，才停下来，回头把整件事捋了一遍。这句话的意思是升级成功不等于没事。我看到的多数中文转述只写了“升级到 5.88.25”，把这句漏了，而漏掉的恰好是最要紧的一句。

先把事情摆清楚。cPGuard 是装在 Linux 主机上的防护软件，防火墙加恶意文件扫描，主机商和 cPanel 环境用得比较多。11 月 2 日 02:06 UTC，有人用有效凭据进了 OPSSHIELD 的 CDN 和更新分发网络，通过 cPGuard 自己的更新通道推了一个恶意脚本出去。厂商明确说了没有利用软件漏洞，靠的是能用的账号密码。受影响版本 5.88.12 到 5.88.19。

这就是供应链投毒最难受的地方：它不是伪装成更新，它就是更新。主机上的 cpgcli 定时去拉，拉的是官方地址，走的是官方分发链路，装的时候还带着 root 权限。运维这边看不到任何异常告警，因为整条链路每一环都是“正常”的。



厂商 12 小时内发现并掐断了分发，11 月 3 日发了通告。恶意脚本被定名为 cpguard-v58812-i91511.sh，落地后干了几件事：

在 /var/tmp/.cpg91511_sh 放一个后门 shell；
把 /etc/shadow、/etc/passwd、root 的 my.cnf、root 的 shell history、/root/.ssh 下的授权与 known_hosts 打包，放到 /var/tmp/.cpg91511/ 下面，归档名 loot.tgz；
把打包的东西传到厂商 licensing 服务器上的一个被控账号，等攻击者自己来取。

到 11 月 3 日的调查更新，厂商说从自己的 licensing 服务器上确认被取回的文件大约 32 个，每个对应一台客户服务器。这个数字要读准：它是“确认被取走”的数量，不是受影响服务器总数。厂商自己也写了，12 小时内掐断不等于没传出去。

受影响服务器总数我这边给不出准确数字。中文转述里有两个版本，一个写 2946 台拉取了恶意更新，一个写约 2950 台，都指向同一篇 BleepingComputer 的报道。我去拉原文被 Cloudflare 挡了，403，error_code 1005，asn_banned，页面还明确写了 Do not retry，所以没拿到一手数字。这篇就不写具体台数，只保留厂商的口径：受影响范围仍在调查。

下面是我按通告原文理的自查顺序。先交代一句，我手上这台是 Windows，没装 cPGuard，下面这些路径和命令全部照抄厂商通告，没在我自己的 Linux 机器上跑过。所以我不给回显，只给判断标准，宁可写得干一点，也不编一段看起来很像的输出。

第一步，看版本。跑 cpgcli --version。结果落在 5.88.12 到 5.88.19 之间，就说明装过投毒区间的版本。

第二步，看升级历史。grep 'Successfully updated' /opt/cpguard/logs/install_log。命中投毒区间里任何一个版本号，说明这台机器确实把带毒的更新装进去了。注意判据是“装过就算”，哪怕现在已经是更高版本，也要按可能失陷对待。

这里有个版本号上的出入得提一下。厂商通告写的修复版本是 5.88.25，我看到的至少一家中文转述写的是 5.88.26。以通告为准，目标是 5.88.25 或更高。数字差一位看着不要紧，但在一堆机器上批量比对版本时会直接导致漏判，所以这个得先对齐。

第三步，看文件。/var/tmp/.cpg91511_sh 是后门本身，/var/tmp/.cpg91511 是收集目录，里面应该有 loot.tgz。这两个路径存在，基本不用再猜了。反过来，文件不在不代表没中过，升级会清掉它们，脚本自己也可能收尾。厂商写得很直白：清理后找不到恶意文件，不能证明这台机器没被碰过。

第四步，看凭据有没有被动过。/etc/shadow 的修改时间如果在 11 月 2 日 02:06 UTC 之后有变动，又不是你自己改的，就按最坏情况处理。同理看 /root/.ssh 下的 authorized_keys 有没有多出来的公钥。

处置这块，通告给的动作比我预想的重，我觉得这个方向是对的：升级只是第一步。cpgcli update --start，然后用 cpgcli --version 确认到 5.88.25。接下来不管怀不怀疑脚本跑过，root 和其他所有能登录的本地账号口令都要在可信环境里重置；复用到别处的口令一起换；数据库口令、S3 access key、DigitalOcean token、root 历史里出现过的密钥全部轮换；/root/.ssh 下的私钥换成新的，并且把对应的旧公钥从所有信任它的机器上删掉。

最后一条最容易被跳过，也最要命。主机商一台机器上的 root 私钥，往往在几十台机器上被信任。密钥不撤，前面那些口令换得再干净，等于门锁换了钥匙还挂在原处。

还有个细节：厂商在 11 月 3 日的更新里说，会再发一版把他们的 support-access key 从客户机器上移除。也就是说 5.88.25 之后还有动作，装完别就当结束了，留意后续通告。

厂商目前不建议整机重装，理由是调查还在早期。这个判断我持保留意见。如果这台机器上跑着别人的站、别人的数据库，重装的成本和“万一没清干净”的风险要放在一起算，这个账只有当事人自己能算。

这件事真正让我在意的不是三千台还是三十台，而是这类产品的定位。防护软件本身 root 权限跑、自己会联网、还从固定地址拉更新，它同时是最该被保护的东西和最方便的跳板。你装它是为了少一个风险点，结果它成了唯一一个不需要你点确认就能在你机器上执行任意代码的通道。这个结构性问题补不了，只能靠“把更新通道也当成攻击面来管”：包落地前验签、异常版本能回滚、更新日志留档。这次能查出哪台中招，靠的就是 install_log 那几行。

来源：
OPSSHIELD 致客户通告原文（2026-11-03，由订阅用户在 r/cybersecurity 贴出，另有多处转载，文本一致）
https://yanac.hu/2026/11/03/cpguard-opsshield-llp-breach
Daily Security Review，cPGuard Update Channel Hijacked to Push Linux Server Backdoor
https://dailysecurityreview.com/cyber-security/cpguard-update-channel-hijacked-to-push-linux-server-backdoor
TheHackerWire（经聚合页转述，给出脚本名 cpguard-v58812-i91511.sh 与文件清单）
https://inoreader.com/stream/user/1005731030/tag/Cyber%20News/view/html?c=hqiJFIqdUUM_
蚁景网安实验室 网络安全日报 2026-11-04（中文转述，2946 与 2950 台、5.88.26 两处口径差异出自此处）
https://www.yijinglab.com/industry/20261104091916
BleepingComputer 原文（2026-11-05 访问被拒，403 error_code 1005 asn_banned，未获取正文，仅作来源标注）
https://www.bleepingcomputer.com/news/security/hackers-hijack-cpguard-autoupdate-to-deploy-backdoor-steal-data/

交叉验证说明：攻击时间 11-02 02:06 UTC、受影响版本 5.88.12 至 5.88.19、后门路径 /var/tmp/.cpg91511_sh、收集目录 /var/tmp/.cpg91511、归档 loot.tgz、修复版本 5.88.25、32 个被取回文件，通告原文与 Daily Security Review、TheHackerWire 三方一致。受影响服务器总数（2946 或 2950）与 5.88.26 这两个数字只出现在中文二手转述里，一手页面未能访问，属单一来源且互相矛盾，本文不采用为事实，只作标注。32 个文件是确认被取回的数量，不等于受影响服务器总数，两者不能混。

HKTULU
2026-11-05