Chrome 157 修复在野利用零日，管理员需核查终端版本

多家第三方报道指，Chrome 在 2026 年 11 月 9 日至 11 日连续发布安全更新：第一次修复了据称已被在野利用的零日漏洞 CVE-2026-125350，第二次修复了 83 项安全问题。现有资料未提供可核验的 Google 原始发布说明，因此漏洞利用状态、修复数量和各平台版本号仍需以厂商公告确认，不能仅凭转述关闭企业终端的更新任务。

两次更新需要分别核对

据第三方报道，11 月 9 日的更新涉及 Windows、macOS、linux 和 Android；11 月 11 日的后续更新又包含多项严重安全修复。后一次更新是否涉及已遭利用的漏洞，现有摘录不足以确认，也不能据此推断攻击目标或利用方式。

表中版本仅供排查线索，不应直接作为最终合规基线。管理员应在 Chrome 官方发布公告中分别核对平台、发布通道及最新可用版本；如果后续公告修订了信息，以官方说明为准。扩展稳定版也不应直接套用普通稳定版的版本阈值。

如何确认托管终端已完成更新

终端管理团队可先按操作系统、Chrome 通道和设备归属导出清单，将运行中的浏览器版本、已安装版本、最近上报时间及待重启状态分开记录。离线设备、长期未上报设备和更新失败设备应单列，而不是默认为合规。

桌面端可打开 chrome://settings/help 检查更新，再通过 chrome://version 查看版本。Linux 设备还应检查发行版软件包管理器或企业软件源是否已提供相应更新。Android 设备则应在应用商店或企业移动设备管理平台检查已安装版本，并与官方 Android 发布说明对照。

更新下载或安装成功不等于所有用户会话都已切换到新版本。桌面浏览器应在重新启动后再次核对；集中管理平台也应等待设备重新上报，确认实际版本达到对应通道的官方修复基线。

安排重启和兼容性回归

企业可先在代表性设备上试点，包括不同操作系统、核心业务应用和关键扩展，再分批扩大部署。重启前通知用户保存未提交内容；对长时间运行的业务会话，安排明确的维护窗口和完成期限。

回归检查应覆盖单点登录、证书与代理访问、核心业务页面，以及密码管理、身份认证和安全防护等必要扩展。若出现兼容性故障，应记录 Chrome 与扩展版本、错误现象及受影响范围，联系应用或扩展负责人处理。不应仅为恢复兼容性而长期回退到已知不安全版本；确需回退时，应经风险审批、限制适用设备并设定恢复更新的期限。

暂时无法升级时的处理

临时措施不能替代修复。对尚未升级的设备，管理员可检查自动更新策略、软件源或应用商店的可用性，排除阻止更新的配置，并持续跟踪重启状态。对高风险或长期离线终端，可依据企业政策限制其访问敏感业务，或改用已确认完成更新的受管设备。

同时，应核查终端防护、浏览器隔离或网络访问控制是否已按预期启用，并记录例外负责人、补救期限和复核结果。这些措施只能降低部分暴露或便于发现异常，现有资料不足以证明某项配置能够单独阻断该零日漏洞。其他基于 Chromium 的浏览器也应分别查阅各自厂商的公告，不能直接套用 Chrome 的版本号。