Google称Chrome两版修复1072个漏洞，AI把漏洞发现推上流水线

1072，对1036。

Google称，Chrome 149和150两个版本在2026年6月共修复1072个安全漏洞。这个月的修复量，超过此前两年23个版本合计修复的1036个。

数字很惊人，也很容易被误读成“Chrome突然烂了”。现有材料支撑不了这个结论。它更像是在说明另一件事：AI正在把漏洞发现从手工作业推向流水线，安全团队面对的清单，开始以机器速度增长。

两个版本修了1072个漏洞，但严重程度仍不清楚

Google把这轮增长归因于内部AI工具及Gemini。不过，公开材料没有拆分AI究竟做了多少工作：哪些漏洞由AI独立发现，哪些由AI协助验证，哪些补丁由AI生成，又有多少仍靠工程师完成。

几组数字可以放在一起看，但不能直接排成“谁更安全”的榜单：

目前还看不清这1072个漏洞的严重等级分布，也不清楚其中多少已经被真实攻击利用、具体覆盖哪些平台。没有这些信息，不能把1072理解成1072次紧急警报。

漏洞统计从来不是简单的产品质量分。产品规模、代码体量、统计规则、披露制度，甚至厂商是否愿意公开低危问题，都会改变最终数字。微软和苹果的数据能证明行业方向，却不足以证明谁高谁低。

“指数增长”也只能当趋势描述。两个版本的异常高点，还不能证明漏洞修复数量会长期按数学意义持续指数上升。

Gemini改变了成本，机器开始批量翻旧账

AI安全工具真正改变的，是寻找相似漏洞的成本。

在软件安全工作中，大模型和自动化工具可以协助扫描代码、生成测试用例、寻找已知漏洞的变体、归纳崩溃原因，也能给出补丁建议。过去需要研究人员逐段排查的任务，现在可以批量执行。

这会带来一个看似反常的结果：工具越强，短期披露的漏洞越多。

其中一部分可能早已潜伏在代码里，只是过去没人找到；一部分可能来自更广泛的变体搜索；还有一部分，则可能因为验证和修复成本下降，终于进入正式补丁清单。它们不能被统称为“新出现的漏洞”。

工业生产引入自动检测设备时，缺陷记录往往先上升。不是工厂一夜之间变差，而是过去漏掉的问题终于被看见。这个类比并不完全相同——软件漏洞会被攻击者利用，处置窗口更短——但背后的测量逻辑很接近。

Google这次做对了一件事：把AI放进真实的安全工程流程，而不是只让Gemini写演示代码。微软同期修复570个漏洞，也说明这条路线已经从个别实验走向大厂竞速。

我不太买账的，是把全部增长笼统归功于AI。没有发现、验证、修复和人工复核的占比，就无法判断Gemini究竟是主力工具，还是整套内部系统中的一个环节。厂商叙事跑得很快，审计颗粒度还没跟上。

攻防两端也在使用同类能力。防守方能批量找漏洞，攻击者同样可以生成变体、筛选目标、分析补丁差异。安全竞争正在进入机器对机器的阶段，速度优势不会永久只属于一边。

漏洞清单变长，真正承压的是处置队列

AI把发现环节提速后，瓶颈会转移到验证、排序、修复、回归测试和版本发布。

模型一天找出几百条线索，不代表工程团队一天能安全地合入几百个补丁。误报需要排除，补丁可能引入兼容性问题，高危漏洞还要在公开前协调修复。AI能制造一张更长的安全债务清单，却不能自动替组织承担全部债务。

这对两类人最现实。

Chrome用户不必被1072这个数字吓住，但应确认浏览器已经更新并重启。可以进入Chrome菜单中的“帮助—关于Google Chrome”检查版本；企业托管设备则按内部策略执行。补丁只有真正安装，才算完成防守。由于目前缺少严重等级和在野利用信息，也没必要把每个漏洞都当成同等紧急。

软件工程和企业安全团队需要调整的不是口号，而是队列管理。补丁优先级应继续看严重程度、是否已被利用、暴露面和业务影响；部署时保留分批发布与回归监控。若团队准备引入AI找漏洞，还得同步增加人工复核、测试和持续集成资源，否则发现能力越强，积压反而越快。

接下来更有价值的指标有四个：

• 1072个漏洞中，高危和已被利用的比例；
• AI在发现、验证、修复各环节的实际贡献；
• 从发现到发布补丁的平均周期；
• 大规模修复是否推高回归错误和补丁重开率。

漏洞总数适合做新闻标题，却不是最好的安全指标。发现得多、修得快、上线稳，三件事缺一不可。

锐评

AI善攻亦善守。发现已上流水线，处置能力才见真章。