VMware vCenter Syslog 目录遍历漏洞 CVE-2026-59310 遭在野利用：虚拟化控制平面如何排查与修复-速维云

事件概述

2026年7月29日，Broadcom 发布安全公告 VMSA-2026-0006，修复了 VMware vCenter Server 与 ESXi 中的多个高危漏洞。其中最严重的是 vCenter Syslog 服务中的目录遍历漏洞 CVE-2026-59310（CVSS 9.8）和 VMware Directory Service 中的身份认证绕过漏洞 CVE-2026-59309（CVSS 9.8）。两者都允许未经认证的远程攻击者直接利用，前者可在 vCenter 设备上执行任意代码。令人担忧的是，公开补丁发布仅约5天后（8月3日），安全公司 QUIRSO 就观测到首个在野利用；到8月中旬，已有361个受害 IP 分布在47个国家/地区，攻击者利用该漏洞在 vCenter 设备上植入 cron 任务和 reverse_ssh 反向隧道，建立持久化控制。CISA 已于8月18日将该漏洞纳入已知在野利用漏洞目录（KEV）。

为什么虚拟化平台是"皇冠上的宝石"

vCenter 是整个 VMware vSphere 环境的集中管理平面，管理着所有 ESXi 主机、虚拟机、存储、网络、用户账户和权限。一旦攻击者在 vCenter 上取得代码执行权限，等同于获得了整个虚拟化环境的"域管理员"级控制：可以为运行中的系统创建快照提取凭据、关闭生产负载、将勒索软件以 VM 磁盘镜像的形式同时部署到所有托管虚拟机，甚至横向渗透到 ESXi 宿主机本身。此次观测到的攻击链还使用了反向 SSH 隧道——它从 vCenter 主动向外连接攻击者基础设施，这意味着只阻挡外部入站连接的防火墙规则对它无效。

虚拟化与云主机承载着企业核心业务，管理平面安全是第一道防线

攻击链与利用前提

攻击者利用 Syslog 服务中的目录遍历缺陷，将文件路径操纵到预期目录之外，从而在设备上写入并执行代码（CVE-2026-59310）。随后攻击者部署恶意 cron 任务实现持久化，并安装开源工具 reverse_ssh 建立出站控制通道。同一公告中的 CVE-2026-59309 可以绕过 vCenter 登录认证，两个漏洞可以串联使用；此外 ESXi 的 VMXNET3 虚拟网卡越界写入漏洞（CVE-2026-47876，CVSS 9.3）允许拥有虚拟机本地管理员权限的攻击者逃逸到宿主机。利用前提只需要攻击者能够网络访问 vCenter 管理平面——不一定要暴露在公网，能从用户网络或工作负载网络到达同样危险。Broadcom 明确表示这两个 vCenter 漏洞没有官方临时缓解方案，补丁是唯一修复方式。

排查思路

如果你的环境运行 VMware vCenter，建议按以下步骤排查：

1. 核对 vCenter 当前构建版本，对照官方公告确认是否在受影响范围：vCenter 8.0（8.0 U3k 之前）、9.0.x（9.0.2.0100 之前）、9.1.x（9.1.0.0300 之前），以及运行这些版本的 Cloud Foundation / vSphere Foundation 部署；仍在运行已停止常规支持的 vCenter 7.0 的环境应尽快联系 Broadcom 获取迁移方案。

2. 检查 vCenter 设备上的可疑计划任务（cron 条目）和未知二进制文件，特别是名为 reverse_ssh 的程序。

3. 检查 Syslog 服务日志中是否出现目录遍历特征（如包含 ../ 的异常路径请求）。

4. 检查是否有异常的出站 SSH 连接——反向隧道会从 vCenter 主动连向外部基础设施。

5. 检查 vCenter 和 ESXi 的管理员账户列表，留意新建的管理员账户、异常配置变更和未预期的虚拟机操作记录（快照、开关机、迁移）。

修复与缓解建议

官方修复版本：vCenter 9.1 升级到 9.1.0.0300；9.0 升级到 9.0.2.0100；8.0 升级到 8.0 U3k（或按分支升级到 8.0 U2f）；Cloud Foundation 5.x 用户需通过 Broadcom 支持门户的异步补丁流程升级；Telno Cloud 部署参考 Broadcom KB449886。ESXi 对应修复版本包括 ESXi80U3k 等。

由于两个 vCenter 漏洞没有官方 workaround，升级是唯一彻底修复方式。升级属于生产变更操作，务必先在测试环境验证、备份 vCenter 配置和关键虚拟机、评估业务窗口后再执行。在完成升级之前，可以采取以下降低暴露面的临时措施：

1. 将 vCenter 管理接口限制在专用管理网段，只允许运维跳板机访问，禁止从用户网络、工作负载网络和公网访问 443/5480 等管理端口。

2. 如怀疑已被入侵，优先保留日志与配置证据，再进行隔离处置；补丁只能堵住入口，无法清除已建立的持久化后门，受影响设备需要做完整的入侵排查。

3. 排查期间可在边界防火墙上限制 vCenter 的出站连接（仅放行必要的更新和 NTP 目标），阻断反向隧道的控制通道。

4. 审查特权账户，最小化拥有 vCenter 管理权限的账户数量，并对关键操作启用审计日志。

后续观察

从补丁发布到大规模在野利用只有5天，再到361个受害节点只用了不到两周，这次事件再次说明：虚拟化管理平面的补丁窗口远比想象中短。建议运维团队把 vCenter/ESXi 的版本核对纳入例行巡检，对暴露面做一次彻底清点。后续可关注 Broadcom 安全公告页面是否有新的 VMSA 更新，以及 CISA KEV 目录中虚拟化相关条目的变化。

文章版权归作者所有，未经允许请勿转载。

THE END