VMware vCenter 漏洞 CVE-2026-59310 被勒索团伙利用：虚拟化管理面的排查与加固清单

事件概述：从"漏洞通告"升级为"勒索武器"

9 月 15 日，CISA 更新了已知被利用漏洞（KEV）目录中 VMware vCenter 漏洞 CVE-2026-59310 的条目，将其标记为"已被勒索软件团伙用于已知攻击活动"。这枚漏洞早在 7 月 29 日就由 Broadcom 在 VMSA-2026-0006 通告中修复，但修复之后的两个月里，攻击不仅没有停止，反而从间谍性质的入侵演变为勒索软件的入口。

CVE-2026-59310 是 vCenter 内置 Syslog 接收服务中的目录穿越漏洞，CVSS 评分 9.8。由于日志消息中的部分字段被用于构造日志文件的落盘路径且未做充分约束，未经认证的攻击者只要能通过网络访问该服务，就可能把任意内容写到预期目录之外的位置，进而实现远程代码执行、完全控制 vCenter 管理面。同一天修复的 CVE-2026-59309（VMware Directory Service 认证绕过，同为 9.8 分）也被攻击者用于扫描，部分受害系统同时遭到两个漏洞的组合利用。

影响范围：361 个 IP、47 个国家，修复窗口只有五天

德国应急响应公司 QUIRSO 的追踪显示，攻击者在漏洞披露后第 5 天（8 月 3 日）就开始实际入侵，到 8 月 7 日已有约 361 个受害 IP 分布在 47 个国家，其中德国、美国、土耳其、伊朗、法国占了一半左右。需要说明的是，361 个 IP 不等于 361 家受害组织——其中不少属于云服务和主机托管商的共享基础设施，实际受影响单位可能更少，但覆盖面已经足够说明问题的普遍性。

另一组数据同样值得注意：Shadowserver 的监测显示，目前仍有数百个 vCenter 实例暴露在公网上。官方没有提供任何临时绕过方案，升级到修复版本是唯一的根治手段。

攻击链长什么样：目录穿越、反向 SSH 与 .babyk 勒索

根据多家安全机构的复盘，这次攻击的典型链条是这样的：先利用目录穿越写入文件并触发执行，拿到 vCenter 设备上的初始权限；接着写入计划任务实现持久化；再部署开源工具 reverse_ssh，建立一条由内向外发起的命令与控制通道——这条通道在只监控入站流量的网络里看起来就是普通的出站连接，因此可以潜伏数周而不被发现。

站稳脚跟之后，攻击者会创建新的管理员账号、通过 vSphere API 摸清资产，部分受害环境的 ESXi 主机上随后出现了以 .babyk 为扩展名的 Babuk 衍生勒索软件，加密 ESXi 日志文件。研究人员提醒，加密日志本身更像是掩盖真实入侵目的的烟雾弹，攻击者的长期意图仍然是维持对虚拟化基础设施的访问。官方虽将活动归于说中文的攻击者（中等置信度），但归属存在不确定性。

为什么站长和企业运维都要关心：管理面就是"一键全拿下"

vCenter 是整个虚拟化环境的控制平面：开机、关机、快照、克隆、宿主机访问，全部经过它。攻击者拿下 vCenter，等于绕过一台一台加密终端的低效路径，直接在虚拟化层面对所有业务动手。这也是近年勒索攻击明显转向的方向——先打管理面，再决定是加密还是只偷数据。

更麻烦的是修复的时效问题：从官方通告到在野利用只隔了五天，绝大多数受害 IP 在通告后一周内就被打穿。对仍按月度、季度节奏安排补丁的团队来说，管理面类漏洞的处理逻辑需要换一挡：先把暴露面收起来，再从容安排升级窗口。

排查思路：从版本号到 /etc/cron.d

如果你维护着 vSphere 环境，建议按下面的顺序做一次排查：

第一，盘点所有 vCenter Server Appliance，确认版本与构建号（可在设备上用 vpxd -v 或管理界面查看），低于修复版本的（9.1 系低于 9.1.0.0300、9.0 系低于 9.0.2.0100、8.0 系低于 U3k/U2f）全部列入升级清单；不要依赖"记得打过补丁"的记忆，以实际构建号为准。同时确认该实例是否曾经暴露在公网或可从办公网直接访问。

第二，如果版本偏低或曾经暴露，重点排查 7 月 29 日以来的持久化痕迹：/etc/cron.d 和 crontab 中是否出现陌生条目、是否有命名异常的日志样式文件被写入意外目录；是否存在 reverse_ssh 进程或来源不明的出站 SSH 连接；SSO 管理员列表里是否多了不认识的新账号；vCenter 的 access.log 中是否有包含连续 ../ 序列的请求或来源异常的高频访问。

第三，交叉核对 ESXi 侧：本地账号列表是否与变更记录一致，数据存储上是否出现异常的加密或改名事件（.babyk 扩展名是明确的危险信号）。一旦发现勒索迹象，应立即隔离相关主机、保留现场，把所有受管主机都纳入排查范围，而不是只处理报警的那一台。

修复与加固建议

升级路径参考 Broadcom 官方通告 VMSA-2026-0006：vCenter 9.1 系升级至 9.1.0.0300 或更高，9.0 系升级至 9.0.2.0100 或更高，8.0 系按分支升级至 8.0 U3k 或 8.0 U2f；VMware Cloud Foundation 5.x 用户按官方异步补丁指引处理，7.0 等旧版本如持有扩展支持合同需联系 Broadcom 获取补丁。补丁是累积式的，动手前建议以 Broadcom 在线的响应矩阵为准确认最新版号。

升级属于生产变更，务必先在测试环境验证，提前备份 VCSA 与关键虚拟机，并在业务低峰窗口执行，升级后确认虚拟机状态、账号权限和计划任务都正常。升级之外，还有几件事同样重要：把 vCenter 和 ESXi 的管理接口从公网撤下，只允许通过跳板机或固定管理 IP 访问；对管理面做网络分段，避免它成为内网横向移动的顺路站点；确认备份和快照存放在 vCenter 服务账号无权删除的位置，并实际演练一次恢复；如果确认环境曾被入侵，vSphere SSO 及相关服务凭据都应轮换。对无法立即升级的环境，可在边界用 WAF 或入侵检测过滤针对 Syslog 服务接口的恶意请求作为过渡，但这只是缓解，不能替代补丁。

后续观察

这枚漏洞暴露在公网上的实例数量仍然可观，后续不排除有新的攻击团伙跟进复用现有利用代码。建议持续关注 Broadcom 官方通告页的更新、CISA KEV 目录的相关条目，以及安全社区针对 reverse_ssh 和 .babyk 的新检测规则。对虚拟化管理面的安全而言，结论其实很朴素：漏洞修复决定下限，暴露面管理决定上限，而两者都要抢在攻击者前面完成。