事件概述
Broadcom 在 2026 年 7 月 29 日发布 VMware 安全公告 VMSA-2026-0006，并在 8 月 19 日更新信息，披露 VMware ESX、vCenter、Workstation、Fusion、VMware Cloud Foundation、vSphere Foundation 以及部分 Telco Cloud 产品存在多项漏洞。公告中最需要优先处理的是 vCenter Server 的两个 9.8 分高危问题：CVE-2026-59309 与 CVE-2026-59310。前者是 VMware Directory Service 中的身份认证绕过漏洞，后者是 vCenter Syslog server 中的目录遍历漏洞，官方描述显示，攻击者只要能够从网络访问到受影响的 vCenter，就可能分别实现未授权访问或任意代码执行。
这类漏洞的危险点不只在 CVSS 分数高，而在于 vCenter 本身是虚拟化环境的管理中枢。它通常掌管 ESXi 主机、虚拟机、资源池、网络、存储、快照、模板、迁移和权限策略。一旦管理面被突破，攻击者不一定要逐台入侵业务虚拟机，也可能直接从控制平面接触大量关键资产。因此，对于运行 VMware 虚拟化平台的企业、IDC、云服务商、学校和中小企业机房来说，这不是“有空再补”的普通更新，而是需要纳入应急优先级的管理面风险。
影响范围
根据 Broadcom 公告，受影响产品覆盖 VMware vCenter、VMware ESX、VMware Workstation、VMware Fusion、VMware Cloud Foundation、VMware vSphere Foundation、VMware Telco Cloud Platform 和 VMware Telco Cloud Infrastructure。就 vCenter 两个关键漏洞而言，受影响版本包括 vCenter 9.1.x、9.0.x、8.0，以及部分 VCF、vSphere Foundation、Telco Cloud 组合环境。官方给出的修复版本包括 vCenter 9.1.0.0300、9.0.2.0100、8.0 U3k、8.0 U2f；vCenter 7.0 场景需要结合扩展支持合同联系 Broadcom 支持确认修复路径。
同一公告还包含 ESX 侧的 CVE-2026-47876，这是 VMXNET3 虚拟网卡中的越界写漏洞，最高 CVSS 9.3。官方说明中，具备虚拟机本地管理员权限的攻击者，如果目标虚拟机使用 VMXNET3 虚拟网卡，可能借此在宿主机上执行代码；非 VMXNET3 虚拟网卡不受该漏洞影响。这个点提醒运维团队：虚拟化安全并不只等于“管理后台别暴露”，虚拟机到宿主机的隔离边界同样需要打补丁。
为什么普通站长和中小企业也要关注
很多小团队会觉得 vCenter 是“大企业机房”的东西，和自己关系不大。但现实里，中小企业托管机房、私有云、研发测试平台、学校实验环境、外包运维环境都可能使用 VMware。部分环境为了远程维护方便，曾经把 vCenter、ESXi 管理入口、跳板机或 VPN 暴露到公网；也有环境虽然没有直接暴露公网，但内网分区粗放，办公网、研发网和管理网之间缺少隔离。对于这次这类不需要认证、只要求网络可达的 vCenter 漏洞来说，管理面“能被谁访问”往往比“密码是否复杂”更关键。
此外，vCenter 被攻击后的影响具有放大效应。攻击者可能查看或修改虚拟机配置、创建高权限账号、调整网络策略、访问快照和模板、影响备份链路，甚至为勒索软件扩散创造条件。即使业务系统本身没有直接漏洞，只要底层虚拟化控制面失守，业务连续性、数据完整性和恢复能力都会受到冲击。这也是为什么安全公告一更新，运维侧就应该先查资产清单，而不是等到扫描器报红才行动。
攻击风险与利用前提
从官方描述看，CVE-2026-59309 和 CVE-2026-59310 都需要攻击者对 vCenter 具备网络访问能力，不要求提前拿到账号密码。Rapid7 的分析也强调，若 vCenter 管理接口被限制在专用管理网，公网直接攻击风险会下降；但如果攻击者已经进入内网，或者管理网与办公网、研发网之间缺少边界控制，仍可能从内部横向移动到 vCenter。HKCERT 在 8 月 19 日更新的通告中进一步提示，CVE-2026-59310 已出现被利用信息，若 vCenter 对互联网开放，远程攻击者可能触发远程代码执行风险。
需要注意的是，安全解读不应把“没有公开 PoC”误读成“可以拖延”。vCenter 历史上多次成为攻击者重点目标，因为它的控制价值远高于普通单点服务器。对企业来说，正确的判断方式是：只要资产确认为受影响版本、管理入口存在可达路径、补丁尚未完成，就应视为高优先级风险；若还叠加公网暴露、弱网络隔离、共享管理员账号、缺少登录审计等问题，则应进入应急处理清单。
排查思路
第一步是确认资产。运维团队应列出所有 vCenter、ESXi、VCF、vSphere Foundation、Workstation 和 Fusion 资产，区分生产、测试、灾备、实验环境，不要只看核心生产集群。很多安全事故并不是从主生产入口开始，而是从长期无人维护的测试平台、临时迁移平台或旧版本管理节点进入。
第二步是确认版本和暴露面。vCenter 管理后台、API、Syslog 相关服务、ESXi 管理口应当只允许管理网、跳板机或 VPN 后的可信来源访问。可以从网络设备、云安全组、防火墙、WAF 或访问控制列表中检查是否存在公网放行、全网段放行、历史临时规则未回收等情况。对于云上或混合云环境，还要同步检查公网 IP、NAT、端口映射和堡垒机策略。
第三步是看日志和账号变化。重点关注近期是否出现异常登录、失败登录激增、来源 IP 异常、管理员账号新增、权限组变更、任务计划异常、虚拟机快照或克隆行为异常、ESXi 主机配置被修改等迹象。日志分析不能只看 vCenter Web 登录，还要结合系统日志、管理网流量、堡垒机审计、EDR 或 SIEM 记录综合判断。
修复与缓解建议
官方明确表示 CVE-2026-59309 和 CVE-2026-59310 没有替代性 workaround，核心修复方式是升级到 Broadcom Response Matrix 中列出的固定版本。因此建议先在维护窗口内完成备份和变更评估，再按厂商文档升级 vCenter 与 ESXi。生产环境升级前，应确认当前版本、插件兼容性、备份状态、证书状态、外部 PSC 或集成组件情况，并在测试或低风险窗口验证升级流程。
对 vCenter 9.1.x，可关注 9.1.0.0300；对 9.0.x，可关注 9.0.2.0100；对 vCenter 8.0，可关注 8.0 U3k 或 8.0 U2f。对 ESXi 侧的 CVE-2026-47876，应根据版本升级到 ESXi 9.1.0.0200、9.0.2.0100、8.0 U3k 或 8.0 U2f 等官方列出的修复版本。VCF、Telco Cloud 和扩展支持场景不要套用单机 ESXi 的经验，应按 Broadcom KB449886、异步补丁指南或支持合同确认路径。
如果短时间内无法立即升级，仍然可以先做降低暴露面的临时措施：关闭公网访问路径，将 vCenter、ESXi 管理口限制到专用管理网；要求通过堡垒机、VPN 或零信任网关访问；收紧防火墙和安全组，只允许必要管理源地址；审查管理员账号和 API Token；开启并集中保存关键日志；对异常账号、异常任务、异常快照和异常网络策略做人工复核。临时缓解不能替代补丁，只能降低被直接触达的概率。
后续观察
接下来需要关注三类变化：一是 Broadcom 是否继续更新 VMSA-2026-0006、补丁版本或 FAQ；二是 CISA KEV、CERT、HKCERT、安全厂商是否确认更多在野利用或扫描活动；三是漏洞检测规则、漏洞扫描器和 EDR/SIEM 规则是否已经覆盖相关版本识别与攻击迹象。对于管理面资产，建议把“是否公网暴露、是否已纳入补丁基线、是否有集中审计”做成固定检查项，而不是每次漏洞爆发后临时盘点。
虚拟化平台的价值在于集中管理，但风险也来自集中管理。vCenter、ESXi、跳板机、备份系统和管理网，本质上都属于高价值控制面。此次 VMware 多漏洞更新给运维团队的提醒很直接：补丁要快，暴露面要小，权限要分层，日志要能追溯。对于中小企业来说，不一定要建设复杂的安全体系，但至少要做到管理入口不裸奔、关键版本有台账、升级前有备份、异常行为有人看。
参考信息
本文主要参考 Broadcom 官方安全公告 VMSA-2026-0006、Broadcom KB449886、Rapid7 对 CVE-2026-59309/CVE-2026-59310 的风险分析，以及 HKCERT 在 2026 年 8 月 19 日更新的 VMware 产品多漏洞通告。具体影响版本、修复版本和升级步骤应以 Broadcom 官方公告与对应产品 Release Notes 为准。
