Chrome 的 AI 辅助漏洞搜寻打破两年修复纪录

在 AI 改变其漏洞处理流程后，Google 在两个版本中修复了 1,072 个 Chrome 安全漏洞，超过此前 23 个版本的总和。

Chrome 149 和 Chrome 150 修复的已报告安全问题，超过了 Google 在此前约两年多个版本节点中解决的总数。这则 Google 新闻看起来像是自动化安全领域的一次决定性胜利。但它也引出一个不那么令人舒适的问题：当发现漏洞的速度远快于人类评估和修复它们的速度时，会发生什么？

这一激增并非来自某个自主系统悄然重写 Chrome。Google 将 AI 辅助发现、确定性测试、自动化分流和开发者审查结合起来。其中一项 AI 辅助调查还发现了一个高严重性缺陷，据报道，它与一段已存活 13 年的代码有关。

这一区别至关重要。真正的较量并不是 Google 与另一家浏览器厂商之间的竞争，而是 AI 速度的漏洞发现能力，与必须验证每项发现、判定严重性、测试补丁并安全发布的人工主导修复流程之间的竞争。

Google 新闻聚焦 1,072 项 Chrome 安全修复

这一惊人的数字确实存在，但它反映的是一次更广泛的安全清理，而非 1,072 个可被独立武器化的漏洞。

Google 表示，Chrome 149 和 Chrome 150 合计解决了 1,072 个安全漏洞。此前 23 个 Chrome 版本节点共修复了 1,036 个。因此，两个版本超过了此前近两年版本的总量。

Chrome 150 能很好地展现这一规模。最初统计显示，该版本修复了 382 个漏洞，其中包括 15 个严重和 67 个高严重性漏洞。根据已发布的 Chrome 150 统计，Google 随后将该版本的修复总数更新为 433 个。

报告中的弱点包括释放后使用错误、越界内存访问、类型混淆、使用未初始化数据，以及输入验证不足。这些类别可能带来严重后果，包括在遭攻陷的渲染器内执行代码。

部分漏洞还可能帮助攻击者跨越 Chrome 的沙盒边界。沙盒将网页内容与操作系统其余部分隔离，限制恶意页面能够访问的范围。逃逸沙盒可能会将浏览器遭入侵扩大为更广泛的设备遭入侵。

不过，原始漏洞数量并不等同于可利用零日漏洞的数量。这些版本涵盖了不同严重性级别、组件、配置和开发阶段的问题。部分发现可能涉及处于禁用功能标志后的代码，或需要罕见条件才能触发的路径。

Google 自身文档承认，AI 生成报告的质量参差不齐。有些报告的严重性评定不正确，缺少完整的概念验证，重复已有报告，或描述了工程师并不认为属于安全边界违规的行为。

因此，1,072 这一数字对于衡量处理吞吐量很有意义，但不足以完整衡量风险降低程度。它表明 Google 处理并修复了规模大得多的安全发现，但并不意味着 Chrome 突然积累了 1,072 个同样危险的漏洞。

发布数据也显示，许多工作来自 Google 内部。在 Chrome 150 最初报告的 382 个漏洞中，358 个由内部发现。外部研究人员依然很重要，特别是在高影响力报告方面，但内部工具推动了大部分工作量。

因此，这一变化远不止是一次繁忙的补丁周期。Google 已构建起一条漏洞处理管线，能够以其旧流程从未接近的速度生成、复现、分类、分派并协助修复发现的问题。

对 Chrome 用户而言，眼下的应对措施依然平常却很重要。只有在浏览器重启并进入已修正的版本后，自动更新才能降低暴露风险。受管组织还必须确认，其部署策略不会让终端长期落后多个版本。

这项纪录最好被理解为 AI 辅助安全工程的一项生产里程碑。它证明了漏洞发现能力已经扩大。该能力能否持续带来更安全的软件，取决于模型标记可疑代码后发生的一切。

一个存活 13 年的缺陷展示了 AI 能发现什么

Google Chrome AI 安全能力最有力的证明不在于总量，而在于它能够重新审视传统测试遗漏的旧代码路径。

CVE-2026-3545 说明了这一价值。Google 将这项 Chrome Navigation 漏洞定为高严重性，并在 Chrome 145.0.7632.159 和 145.0.7632.160 中修复，具体取决于操作系统。

该漏洞涉及数据验证不足。根据联邦漏洞记录，远程攻击者可能借助特制 HTML 逃逸渲染器沙盒。

沙盒逃逸并不自动构成完整攻击链，但它仍可能是至关重要的一环，因为它突破了主要的隔离层。攻击者通常会组合多个漏洞，其中一个攻陷渲染器，另一个则获取其外部的权限。

有关 Google 内部调查的报道指出，易受攻击的代码已存在约 13 年。据报道，使用 Gemini 的 AI 代理框架帮助识别出错误路径。公开漏洞记录证实了该缺陷、其影响及修复情况，但并未独立记录 Google 内部发现过程的每个细节。

相比严重性标签，这一存在时间更具启示性。成熟软件包含在较旧的架构、威胁模型和开发实践下形成的假设。代码首次发布时编写的测试，可能从未覆盖后来变得危险的组合情况。

人类安全研究人员可以检查这些路径，但时间带来了限制。Chrome 包含庞大的代码库，并在受支持平台上使用约 1,700 个第三方依赖项。工程师必须优先处理活跃开发、传入报告、回归问题、依赖项更新，以及已影响用户的事件。

AI 代理改变了重新审视旧代码的经济性。它们可以检查大量执行路径，对不安全状态转换提出假设，并将推理与模糊测试结合。模糊测试会向软件输入意外数据，以诱发崩溃或其他异常行为。

这种组合有助于解释 Google AI 如何发现旧自动化扫描器遗漏的漏洞。确定性工具可检测指定模式或测试失败；推理模型则能推断一系列有效操作会产生不安全结果，然后要求另一个系统复现这一结果。

Google 表示，由 Google DeepMind 和 Project Zero 开发的代理 Big Sleep，如今已作为全自动管线运行，用于保护 Chrome 的 V8 JavaScript 引擎。V8 尤其是一个重要目标，因为它处理网站提供的代码。

该公司还介绍了 CodeMender，这是一款基于 Gemini 的实验性代理，旨在为关键代码漏洞创建修复方案。发现与修复是不同任务，但将两者连接起来可以缩短从确认发现到候选补丁之间的时间。

这并不意味着 AI 察觉了某种人类无法理解的东西。一旦发现，漏洞仍需要可复现的解释、严重性判断、代码修改、回归测试和受控发布。

它的贡献在于大规模搜索。代理可以持续检查低可见度代码，而无需承担人类专家面临的同等机会成本。这使防御者能够以更低成本接触陈旧、被忽视的路径。

这条 13 年的时间线也挑战了关于成熟产品的一个常见假设。产品存在时间长，并不保证安全敏感组件已被彻底探索；它可能反而意味着最容易发现的漏洞已经消失，而罕见交互仍被埋藏。

Google 的结果表明，AI 可以触及这一剩余层面。但这也意味着，使用同类模型的攻击者同样可以搜索它。

漏洞发现不再是最慢的环节

Google 的新优势带来了新的瓶颈：每一份机器生成的报告仍要争夺有限的工程资源。

Chrome 安全团队在 2026 年 4 月警告工程师，AI 模型正产生大量内部和外部生成的安全漏洞。其发布的 AI 漏洞指南要求团队优先处理最严重的问题，同时像对待人类发现一样谨慎处理 AI 报告的披露事宜。

该指南设定了严格的修复预期。最紧急的 S0 漏洞应在一周内处理，S1 问题则应在四周内处理。当报告量增长快于人员配置时，实现这些目标会变得更加困难。

这正是这一纪录背后的核心张力。只有当组织能区分真实漏洞、重复报告、无效假设、不可达代码和错误严重性标签时，发现 1,072 个漏洞才真正有价值。

Google 正在自动化这一中间层。其季度安全更新描述了隔离式基础设施：它可复现报告、补充信息、分析严重性，并将其分派给合适的开发者。

V8 还增加了测试模式，以帮助区分实验性代码中的失败与生产环境问题。Google 表示，这些工具使内部代理能够在提交发现前对其进行验证。

这正是 Google AI 如何在不只是用模型生成的怀疑淹没工程师的情况下发现漏洞。模型提出或优先排序某项假设，而确定性系统则验证观察到的行为能否在受控条件下复现。

即使这种架构也无法消除人类判断。安全边界一部分是技术性的，一部分则源于有意设计。代理可能识别出看似不安全的数据移动，却不了解某个组件明确允许这种行为。

Google 的 FAQ 鼓励团队添加 SECURITY.md 文件，用于描述其安全边界。代理可以读取这些文件，并过滤与组件预期设计相冲突的发现。

这种做法将机构知识转化为机器可读的上下文。它也揭示了一项限制：AI 的表现取决于代码周围规则、文档、测试和示例的质量。

未记录的边界可能产生误报。定义不清的信任关系可能导致漏洞遗漏。自动化会放大其所接收工程环境的质量。

重复报告处理又带来一项挑战。安全问题通常在用户收到修复前保持私密，因此普通组件负责人无法看到每一份相关报告。代理可能独立重新发现某个已在其他地方调查的漏洞。

Chrome 团队告知开发者，除非拥有适当的安全访问权限，否则不要进行广泛的重复项搜索。中央分流系统必须在不提前暴露敏感细节的情况下协调这些报告。

概念验证同样带来了压力。Google 表示，如今大多数 AI 生成的问题都会附带概念验证，但有些报告可能并未提供完整演示。工程师仍需将初始提交视为一项完整的安全问题来处理。

这种谨慎的政策能够保护用户，但也会消耗注意力。如果报告质量下降而数量持续攀升，团队可能不得不投入越来越多时间来证伪模型的判断。

因此，变化后的瓶颈影响的不止 Google。采用 AI 漏洞工具的软件组织需要具备安全的复现环境、明确的组件边界、对私密报告的受控访问，以及可靠的回归测试。

购买或部署模型是容易的部分。围绕模型建立起整套系统，才决定 AI 辅助发现究竟能降低风险，还是会制造一条昂贵的待处理队列。

更快的防御也为攻击者提供了更快的工具

帮助 Google 检查 Chrome 的同类推理能力，也能帮助对手在其他软件中定位并利用弱点。

Google 的安全工作并非处于纯粹防御的真空中。其威胁情报研究人员称，他们发现一名犯罪行为者使用了他们认为由 AI 开发的零日漏洞利用程序。据报道，该组织原计划开展更大范围的攻击活动，后被 Google 阻断。

该公司的威胁情报发现还描述了与国家相关联的团体对 AI 辅助漏洞发现日益浓厚的兴趣。攻击者正在将模型用于研究、漏洞利用开发、恶意软件修改和行动支持。

这形成了一场以补丁窗口为衡量单位的竞赛。补丁窗口是指漏洞被理解到所有受影响系统获得保护之间的时间段。AI 可以压缩这条时间线中的发现环节，无论对防御者还是攻击者都是如此。

对于 Google Chrome AI 安全而言，内部访问带来了多项防御优势。Google 可以检查源代码、执行大规模测试、使用私有遥测数据、咨询组件负责人，并在公开披露前准备补丁。

攻击者并不需要具备同样的优势。Chromium 是开源项目，浏览器更新可以揭示哪些代码发生了变更。一个有能力的系统可以比较不同版本、识别与安全相关的修改，并帮助针对尚未更新的用户构建漏洞利用程序。

这也是 Google 在大量用户获得修复前限制漏洞细节访问的原因之一。该政策减少了攻击者在发布过程中最危险阶段可获取的信息。

更频繁的发布能够缩短暴露期。Chrome 目前会按周发布安全更新，并与其里程碑发布计划同步。从 2026 年 9 月的 Chrome 153 开始，Google 计划将稳定版里程碑的发布间隔从四周缩短至两周。

Google 表示，双周节奏将带来更小规模的发布，并简化调试过程。更快的里程碑发布能够更早交付修复后的代码，但也会提高企业管理员和依赖浏览器的应用的测试要求。

创纪录的补丁数量让这种权衡更加突出。只有当用户、受管设备和基于 Chromium 的产品迅速采用更新时，更小的补丁窗口才有意义。

Chrome 并不等于整个 Chromium 市场。Microsoft Edge、Brave、Opera、Vivaldi、嵌入式浏览器和应用框架都会按照各自的时间表整合 Chromium。修复进入 Google 的代码树，并不会立即保护每一个下游产品。

企业通常还会增加一层延迟。它们可能因兼容性检查而暂缓浏览器更新，使用 Extended Stable 渠道，或维护那些不会定期重启的设备。在漏洞利用开发持续推进期间，这些做法可能让已经验证的补丁一直处于等待状态。

AI 生成的补丁也带来了自身的不确定性。候选修复方案可能消除了报告中的行为，却引入回归问题、削弱另一道边界，或只处理了更深层设计问题的一种表现。

Google 并未声称模型会独立批准并部署所有这些变更。其已披露的工作流程仍使用确定性验证，并将问题转交给开发人员。这种由人工控制的结构是一项保障，而不是已经过时的环节。

因此，1,072 个漏洞的总数不应成为取消审查人员的论据。它支持围绕审查人员投资自动化能力，包括复现、分类、测试、依赖项跟踪和发布管理。

只庆祝数量本身还存在另一种风险。安全团队可能会为易于传达的发现数量进行优化。攻击者优化的则是可利用性、影响范围、持久性以及对高价值系统的访问。

一个微妙的沙箱逃逸漏洞，可能比数百个低影响缺陷更重要。因此，成熟的 AI 安全计划必须优先关注攻击链和暴露在外的生产路径，而不只是最大化提交率。

Google 的经验提供了令人鼓舞的证据，表明 AI 可以改善防御能力。但它自身的情报工作也显示，任何领先优势都将持续受到争夺。

Chrome 用户和安全团队接下来应关注什么

下一项考验在于，Google 能否在维持这一发现速度的同时，保持分诊质量、补丁稳定性和快速采用。

第一个信号是未来 Chrome 版本的构成。若再次出现大规模总数，将证明 6 月的激增是持久管线的一部分，而非一次性清理。

严重性分布比标题中的总数更重要。读者应关注其中有多少发现属于严重或高严重性、多少影响已发布代码，以及多少获得了 CVE 标识符。

外部报告仍将十分重要。独立研究人员可以检验内部代理从 Google 文档、代码结构和训练示例中继承的假设。健康的计划应在内部发现扩展的同时，保留这种外部压力。

Google 已调整其漏洞奖励计划，以反映 AI 辅助报告数量的增长。该公司表示，自动化系统如今可帮助复现和分诊提交内容，而不合规的报告将更频繁地遭到拒绝。

这一变化可以理解，但需要仔细监测。严格筛选能够控制低质量报告的数量，但也可能打击那些不符合自动化模板、却发现了真实安全边界失效的非常规报告。

第二个信号是修复延迟。Google 针对严重漏洞公布的目标提供了基准，但整体表现将显示审查管线能否跟上节奏。

不断增长的私密积压会削弱对此次 google news 事件的乐观解读。AI 将以更快速度暴露风险，却没有缩短用户处于脆弱状态的时间。

稳定或缩小的积压则会强化这种解读。这将表明，自动化复现、分类和路由能力能够与发现能力同步扩展。

发布质量提供了间接衡量指标。应关注紧急回滚、浏览器回归、失效的企业策略，或用于修正不完整修复的后续补丁。只有当变更经受住生产环境使用的检验时，大规模数量才有价值。

转向双周里程碑发布计划将提高风险。更小的发布可以使缺陷更容易被隔离，但企业和下游 Chromium 厂商必须调整其测试与部署流程。

第三个信号是来自对抗性使用的证据。Google 已报告一名犯罪行为者疑似使用 AI 辅助开发零日漏洞。更多有记录的案例将证实，这场发现竞赛已从研究演示进入日常行动。

这将增加每一家大型软件供应商的压力，而不仅仅是浏览器制造商。供应商需要假设，攻击者可以利用低成本、持续运行的代理重新审视旧代码。

开发人员应通过改善代码周边环境来应对。清晰的安全边界、可复现的构建、强大的测试、内存安全组件和及时的依赖项更新，都能让人工与 AI 审查更加有效。

安全负责人还应将发现指标与结果指标区分开来。有用的衡量标准包括验证时间、修复时间、补丁采用率、重新打开的问题、逃逸的回归问题，以及在活跃利用期间发现的漏洞。

对于个人用户而言，结论没那么复杂。请保持 Chrome 或其他基于 Chromium 的浏览器处于最新状态，在更新就绪时重启浏览器，并在重大安全公告后核实已安装的版本。

自动更新是一种交付机制，并不能证明补丁已经生效。等待重启的浏览器可能仍在运行易受攻击的代码。

组织应盘点嵌入 Chromium 的应用，而不要假设 Chrome 桌面版的部署覆盖了每一个实例。嵌入式运行时和次级浏览器可能遵循不同的更新渠道。

更广泛的意义超越了浏览器。AI 现在能够足够深入地搜索成熟软件，从而发现大量常见缺陷，以及隐藏了十多年之久的罕见漏洞。

当这种能力与严谨的工程实践和快速分发相结合时，它有利于防御者。当组织让旧代码缺乏文档、未经测试或更新缓慢时，它则有利于攻击者。

决定性问题已不再是 AI 能否发现有意义的漏洞。Google 的结果提供了充分证据，表明它可以。

问题在于，安全组织能否在对手利用同样能力之前，将机器速度的发现转化为可信赖的人工修复。关注接下来的 Chrome 版本、其修复质量和实际更新采用率。这些信号将揭示这一 google news 里程碑究竟代表持久的安全优势，还是一场速度更快竞赛的开始。