VMware ESXi高危漏洞修复工作情况报告

3月5日凌晨2点17分，高危工作安全运维群里的漏洞警报声炸了——CVE-2025-22224、CVE-2025-22225、修复CVE-2025-22226三个漏洞同时被标记为“已利用”。情况我盯着屏幕，报告手里的高危工作咖啡差点洒在键盘上。ESXi是漏洞虚拟化底座，一旦被攻破，修复上面跑着的情况几十台业务虚拟机等于全部裸奔。

漏洞原理不复杂，报告但恶心。高危工作22224是漏洞VMX进程的堆溢出，攻击者只要拿到虚拟机内的修复普通权限，就能直接逃逸到宿主机。情况22225是报告HGFS模块的越界写入，配合勒索软件团伙常用的“虚拟机快照删除”手法，能把恢复路径一并堵死。22226相对温和，但也给了本地提权的机会——三个漏洞串起来，就是一条从虚拟机打到物理服务器的完整攻击链。

我们第一时间做了资产盘点。机房里有47台ESXi主机，版本横跨6.7到8.0，其中23台跑着核心业务。最棘手的是那6台6.7U3的老机器，官方补丁已经停止支持——这意味着要么升级大版本，要么得想别的办法兜底。

修复策略分了三层。第一层是应急缓解：在无法立即打补丁的主机上，通过SSH关闭HGFS服务，同时用PowerCLI脚本批量检查所有虚拟机的“已连接CD/DVD驱动器”状态，把不需要的挂载全部卸载——攻击面能砍一点是一点。第二层是补丁部署：先拿测试环境的两台低负载主机试水，确认vCenter兼容性没问题后，再按“非核心→核心”的顺序滚动更新。整个过程用了4小时17分钟，比预估的快了将近一半，因为提前准备了离线补丁包，绕开了外网下载的等待时间。

有个细节值得说。第三层防护我们做了“回滚预案”，但实际操作中发现，ESXi的补丁回滚不像Windows那样一键搞定。它需要先备份配置，再用原安装包修复模式重装，稍有不慎就会导致虚拟机注册信息丢失。所以我们额外花了40分钟，对每台主机的/etc/vmware/config文件和.vmx配置做了快照备份，这才敢动手。

到3月7日晚上，47台主机全部完成修复。vCenter的“主机状态”一栏终于齐刷刷亮着绿色。但别高兴太早——扫描日志里发现，有两台主机在漏洞曝光前48小时内，有异常的SSH登录尝试。虽然没成功，但说明扫描器已经在全网撒网了。这次是运气好，下次呢？

事后复盘，最痛的不是技术，是管理。那6台老版本主机，业务部门一直说“下季度再迁移”，结果拖到漏洞爆发才连夜开会。如果早半年做虚拟化版本标准化，今天根本不用这么狼狈。另外，我们的漏洞情报订阅居然只覆盖了NVD，没盯住VMware官方安全公告的RSS——两个漏洞的公告比NVD入库早了整整9个小时。这9小时，就是攻击者抢跑的时间窗口。

修复工作收尾了，但安全这件事永远没有“完成”一说。我把这次的补丁包和应急脚本整理成了离线仓库，每季度做一次模拟演练。下次再遇到类似漏洞，希望我们能从“熬夜救火”变成“按剧本执行”。毕竟，虚拟化平台的安全，赌不起第二次运气。