企业批量排查Chrome版本落地方法

CVE 通报出来那天，不少公司的安全群里都会出现同一个问题：我们到底有多少台机器还没升级？漏洞本身写得挺清楚——Windows 上低于 156.0.8078.73 的 Chrome 存在释放后使用问题，攻击者可以诱导用户打开特制 HTML 页面，在沙箱内执行任意代码。但对运维来说，真正卡住的从来不是“要不要修”，而是“先搞清楚谁需要修”。

先把排查范围固定下来

不需要排查的机器可以先排除：已升到 156.0.8078.73 或更高版本的终端不在受影响范围内。linux 和 macOS 这次同批更新，但 NVD 对这条 CVE 的平台描述只限定 Windows，其他平台是否受同一缺陷影响，看厂商公告就行，不要自行推断。托管和非托管也要分开——托管终端归分发系统管理，非托管终端往往是最容易漏掉的那批。

排查分三层，先摸清数量再扩大范围

最省事的一层是抽样人工确认。在浏览器地址栏进 chrome://settings/help，页面会显示当前版本，还会自动触发检查。这层适合快速确认“有没有问题”，但不适合用来统计数量。

第二层是批量清点。Windows 终端上可以读取 chrome.exe 的文件版本信息，比如用 PowerShell 取 VersionInfo.FileVersion；也可以读 Google 更新客户端注册表项里的 pv 值，拿它跟 156.0.8078.73 比对。挑一种顺手的做成脚本，目标是形成一份清单，不必一次就做得特别精细。

第三层是把浏览器版本写进资产台账，与操作系统补丁并列成常态检查项。否则这次查完，下次还得从头再来一遍。

处置顺序按暴露程度排：直接面向互联网的、承载客服和邮件入口的、跑高权限后台的终端优先；然后是开发与运维的工作站，这类机器往往同时登录多个系统。

分发要看进度，回滚要看代价

托管环境继续用 Chrome Browser Cloud Management、组策略或现有软件分发通道强制升级就行。灰度推送期间，同一家公司里版本不齐是正常现象，但分发系统里得能看到目标版本、已达标比例和失败原因；只看“任务已下发”没有意义。非托管终端记得提醒重启，更新下载完后不重启等于没更新。

至于回滚，要格外谨慎：降回 156.0.8078.73 以下，等于重新打开了漏洞描述的暴露面。只有在确认新版本造成业务阻断、并且已经有临时缓解措施时才考虑，同时定好回滚时限和再次升级计划。

顺带说一句，目前公开的公告和通报里都没有看到实际利用的证据。这更像一次优先级较高的常规补丁窗口，而不是需要立刻拉应急响应的事。内部通报时，把“版本范围已确认”和“利用细节未公开”分开表达，不容易给自己招来麻烦。