Chrome潜伏13年漏洞被AI揪出 两版修复1072个超之前23次总和

Chrome浏览器近两次更新修复的安全漏洞总数达到1072个，这个数字一举超过了此前23次更新的累计修复量。导致这一变化的并不是浏览器突然冒出同等规模的新缺陷，而是谷歌内部一支由AI模型驱动的扫描系统，开始在这个全球使用最广泛的浏览器代码库里，挖出了大量遗存多年的老问题。

这套系统由谷歌自研的大模型Gemini担任核心，专门在Chrome的全量源代码中寻找可利用的薄弱点。在例行扫描中，它标记出一个潜伏时间超过13年的沙箱逃逸漏洞。按照谷歌工程师给出的描述，该漏洞能让浏览器中一个已经被攻破的组件欺骗Chrome，使其读取本不应被访问的本地文件。令人不安的不只是漏洞本身，而是这样一个能直通本地数据的通道，在十几年间的多次人工代码审查和安全审计里，一直没有被察觉。

除了溯源这些深埋在历史版本中的隐患，这个AI代理如今还要处理一项过去极度耗费人力的工作——对每天涌入的漏洞报告进行预审。在传统的流程中，每个提交给Chrome的bug报告都需要安全人员手动判定有效性、过滤掉垃圾提交，再搭建环境尝试复现，最后根据影响面和可利用性附上严重等级。单个报告平均要花掉五到三十分钟不等，一旦报告量激增，整个团队就被拖入大量重复操作里。现在，这套自动化流程会先一步完成分类和初筛，只把需要人工深度介入的部分留出来，相当于为安全团队撤掉了一道由重复劳动筑起的高墙。

当某个漏洞被确认后，随即启动的是一套几乎全自动的修复流水线。第一个角色是“修复代理”，它会对漏洞生成若干候选补丁；紧随其后的“评审代理”逐一审查这些补丁的合理性和安全性，任何可能引入新问题的修复都会被拦截并打回；然后“测试编写代理”针对待选补丁生成测试用例，并在Chrome所支持的所有平台上验证功能正常。一整轮跑下来，在真正的开发者动手之前，相当一部分漏洞已经拥有了可落地的方案。谷歌方面给出的反馈是，这套流程每个月节省了数百小时的开发时间，让安全工程师从重复的鉴别和修补工作中被释放出来。

不过，当1072个修复量这个数字首次被摆上台面时，一个很自然的疑问也随之浮出：这到底意味着Chrome的代码质量在变差，还是它的安全防线终于开始真正发力了？这种质疑并不难理解，一个浏览器在仅仅两次版本更新中打上的补丁，比过去二十多次加起来还多，难免让外界以为谷歌正在仓促“还债”，或者浏览器底层出了某种系统性的退化。

但谷歌对这件事的解释，连同它们在技术路线上的动作，都指向了完全相反的方向。那些已经有十几年历史却从未被发现的漏洞，并不等于它们从来不存在。相当一部分老旧缺陷因为触发条件极为苛刻或涉及的模块过于冷僻，长时间被埋没在浩瀚的代码海洋里。人工审查一方面受到工程师个人精力、经验和工具覆盖面的限制，另一方面也难以持续追踪不同模块间随着版本迭代而新生成的交互风险。AI代理则不受这些因素的约束，它能够以机器的耐心一遍遍遍历代码路径，把过去所有代码审计遗漏的脆弱节点逐一翻找出来。因此，修复量的突然上升不是漏洞数量本身在膨胀，而是发现能力的代际提升，把一直隐藏在暗处的存量风险暴露在了统计口径里。

沿着这个逻辑继续看，谷歌还在做的另一件事，是把防线从“发现”进一步推到“送达”。在传统更新模式下，安全补丁从在内部被开发出来，到最终推送至用户浏览器之间存在一个窗口期，这个窗口在安全场景里被称为“补丁间隙”。它既是供应商测试和分发的必要时间，也可能成为攻击者利用已知漏洞实施攻击的黄金时段。为了把这个间隙压到最短，谷歌已经在试点将Chrome的安全更新频率从每周一次提升到每周两次，同时测试一项称为“动态补丁”的技术。一旦动态补丁成熟并大规模部署，大部分安全更新将不再需要用户主动重启浏览器就能直接生效，以往的更新提示弹窗和等待时间都可能被大幅削减。

把这些环节串起来再看，就不难理解为什么谷歌会把这次AI驱动的安全流程重塑看作一次基础设施级的变动。从人工肉眼完全漏掉的沙箱逃逸旧洞，到每个月节省数百小时的自动化修复管线，再到意图消除补丁间隙的更频繁更新和静默修补技术，每一个节点都不是孤立的小修小补，而是在把过去以人力和日历为节奏的安全响应，替换成以模型和自动化流水线为心跳的持续防御。

对普通Chrome用户来说，这个变化在体感上或许只是浏览器版本号跳动得更勤了，或者更新提示的出现比以往更频繁了一些。但每一个这样的提示背后，很可能都是一个刚刚被关闭、而且已经被核实不会真正威胁到终端机器的入口。不是浏览器变危险了，而是它终于有能力在攻击者发现之前，把那些藏了十几年甚至更久的老问题先一步处理