AI让Chrome单月清掉两年漏洞

Google用一个月，处理了过去两年的漏洞量

Google近日披露，Chrome团队在2026年6月借助AI工具修复的软件缺陷数量，超过此前两年、23个Chrome版本修复量的总和。截至7月31日，这组数据已经成为AI进入大型软件工程核心流程后，最有冲击力的一次公开展示。

安全漏洞是可能破坏软件机密性、完整性或可用性，并可能被攻击者利用的程序缺陷。 Google此前23个Chrome版本累计修复约1036个问题，这意味着6月单月处理量至少高于1036个；换句话说，团队在一个月内完成了过去约两年才能完成的工作量。

这并不等于Chrome突然在一个月里新增了上千个高危漏洞。更准确的理解是，AI把长期埋在代码库中的历史缺陷集中挖了出来，并帮助工程师更快完成定位、修补和验证。Chrome拥有数千万行代码，还要同时处理C++内存安全、JavaScript引擎、图形栈、网络协议、扩展系统和多平台兼容性，任何依赖人工逐行审查的方案都不可能覆盖全部路径。

这组数字也需要避免一个常见误读：Google所说的“bugs”不能全部直接等同于已分配CVE编号、可被远程利用的安全漏洞。软件缺陷中可能包括崩溃、越界访问、未定义行为、逻辑错误和测试失败，只有经过安全影响评估并满足披露条件的部分问题，才会进入公开漏洞统计。

AI不是替工程师写补丁，而是把排雷变成流水线

AI辅助漏洞修复是利用模型完成缺陷发现、影响分析、补丁生成和测试验证，再由安全工程师决定是否合入代码的工程流程。 它的价值不在于某一次对话能写出多漂亮的代码，而在于可以不间断地阅读海量崩溃日志、比较相似代码路径，并批量提出可验证的修复候选。

Google没有把6月全部内部工具和模型配置完整公开，但从Chrome及Google既有安全工程体系看，AI主要可以进入四个环节：

1. 发现异常路径。 模型结合静态分析、动态执行和历史漏洞模式，寻找人工审查容易忽略的边界条件。
2. 归并重复问题。 同一个根因可能产生数百份不同崩溃日志，AI可以将它们聚类，避免工程师重复排查。
3. 生成补丁候选。 模型根据调用关系和测试结果提出修改方案，但补丁仍需代码审查和自动化测试。
4. 扩大回归测试。 AI可以围绕修改点生成更多输入，检查补丁是否只堵住一个触发样例，而没有解决根因。

模糊测试是向程序持续输入随机、变异或结构化数据，以触发崩溃和异常行为的自动化测试方法。 Google长期维护的OSS-Fuzz已经证明，机器可以持续替开源项目寻找崩溃；生成式AI进一步补上的，是理解代码语义、构造更深层输入以及协助修复的能力。

传统模糊测试更像不停试钥匙的机器：速度很快，但不一定知道门后面是什么。引入模型后，系统可以先阅读协议格式、数据结构和调用链，再有针对性地生成输入，因而更容易进入过去难以覆盖的代码分支。对于浏览器这种输入面极其复杂的软件，网页内容、字体、图片、视频、WebAssembly和网络响应都可能成为测试入口。

AI在这里最重要的贡献其实是“吞吐量”。一名资深安全工程师可能需要数小时甚至数天确认一个复杂崩溃的根因，而自动化系统可以并行分析成千上万个样本，把人的注意力集中到高风险、可利用或跨组件的问题上。

433个公开问题，只是更大规模清理的一部分

7月披露的另一组数据进一步说明了变化幅度：Chrome最近一次更新发现并修复433个漏洞，而一年前同类更新只有11个，数量达到约39.4倍；其中401个来自内部报告，占433个问题的92.6%。

这两个数字与“6月超过过去两年总和”并不矛盾。前者更接近某个公开更新周期的漏洞披露统计，后者描述的是Chrome团队在6月完成的整体缺陷修复工作；两者的统计范围、披露时间和安全评级可能不同，不能简单相加。

| 指标 | 过去或对照数据 | 2026年最新数据 | 变化幅度 | 应如何理解 | | --- | ---: | ---: | ---: | --- | | Chrome两年与6月修复量 | 23个版本共约1036个 | 6月单月超过1036个 | 单月超过两年总和 | 包含Google口径下的软件缺陷，不等于全部都是高危CVE | | Chrome同类更新披露量 | 2025年同期11个 | 2026年433个 | 约39.4倍 | 反映发现和处理能力跃升，也可能包含历史积压问题 | | Chrome内部报告占比 | 未披露可比数字 | 401/433 | 92.6% | 主要增量来自内部安全流程，而非外部集中提交 | | 美国NVD收录量 | 2025年全年创纪录 | 2026年1月至7月27日约45207个 | 已接近去年全年 | AI可能是驱动力之一，但不能解释全部增长 | | 攻击者平均利用时间 | 2025年约72小时 | 2026年约24小时 | 缩短48小时，降幅66.7% | 企业留给测试和部署补丁的时间明显减少 |

CVE是用于唯一标识公开安全漏洞的标准编号体系。 CVE数量适合观察披露趋势，却不适合直接衡量一款产品是否更不安全，因为统计增加既可能来自代码质量下降，也可能来自检测能力增强、披露政策变化或旧漏洞集中清理。

因此，“Chrome漏洞暴增”不应被解读为Chrome在2026年突然变得更差。恰恰相反，在实际遭利用数量没有同步上升的情况下，内部发现占比达到92.6%，说明Google正在攻击者之前主动扩大排查范围。对一款覆盖数十亿用户的浏览器来说，主动暴露并修复隐藏问题，通常比维持一个好看的低漏洞数字更重要。

行业已经进入漏洞发现通胀期

Chrome并不是孤例，2026年的大型软件供应商正在同时经历漏洞披露量上涨。甲骨文7月例行更新修复1449个安全漏洞，创公司49年来单次更新纪录；去年同期为309个，今年约为去年的4.69倍，增量达到1140个。

微软7月披露642个漏洞，也接近2025年同期的5倍。美国国家漏洞数据库在2026年1月至7月27日已经收录45207个漏洞，接近2025年全年总量，而2025年本身已经创下历史纪录。

| 厂商或数据库 | 2025年对照数据 | 2026年最新数据 | 变化情况 | | --- | ---: | ---: | ---: | | Google Chrome同类更新 | 11个 | 433个 | 增至约39.4倍 | | Oracle 7月更新 | 309个 | 1449个 | 增长约368.9% | | Microsoft 7月披露 | 约为今年五分之一 | 642个 | 接近5倍 | | 美国国家漏洞数据库 | 全年创历史纪录 | 前7个月约45207个 | 已接近上一年全年 |

这些数字共同指向一个变化：AI正在降低发现漏洞的边际成本。过去需要顶尖研究员手工逆向数天的问题，现在可能先由模型筛出可疑路径，再交给人确认；过去没有经济价值的低概率边界条件，现在也能被自动化系统反复测试。

但把全部增长归因于AI仍然过于乐观。软件供应链持续扩大、开源依赖数量增加、云服务更新加快，以及厂商披露规则变化，都会推高漏洞数量。VulnCheck此前也提醒，2026年Chrome相关CVE披露量一度同比增长563.2%，这一趋势与AI辅助工具成熟相符，但现有证据不足以证明每一个新增漏洞都是由AI发现。

真正的瓶颈正在从发现转向验证和发布

AI可以更快地产生漏洞报告，却不能自动消除软件发布的工程约束。Chrome补丁需要覆盖Windows、macOS、Linux、Android和ChromeOS，还可能影响Chromium下游浏览器；一个看似简单的边界检查，也可能造成网页兼容性下降、性能回退或新的内存生命周期问题。

这意味着Google面对的下一个瓶颈不是“模型还能找到多少”，而是“团队每周能安全合入多少”。如果AI每天提交数千个候选问题，人工审查、漏洞评级、补丁测试、版本分支回合和稳定版发布都会排队。发现能力提升10倍，并不代表修复系统的总体吞吐量也会自动提升10倍。

补丁质量同样比补丁数量更关键。模型可能针对触发崩溃的样例增加一个条件判断，却遗漏共享组件中的根本缺陷；它也可能生成能够通过现有测试、但破坏其他平台行为的修改。对浏览器安全团队而言，真正可用的AI系统必须证明补丁覆盖了根因，而不是仅让测试样例停止崩溃。

Google的优势在于Chrome拥有成熟的持续集成、沙箱隔离、站点兼容测试和分阶段发布机制。开发者可以在Chromium公开代码仓库中看到其庞大的代码与测试体系，这类基础设施决定了AI输出能否快速转化为可靠更新，而不是停留在演示阶段。

防守效率上升，也让攻击窗口缩短

AI发现漏洞是一把典型的双刃剑。防守方可以用模型审查代码，攻击者同样可以用模型分析补丁差异、定位被修复的函数，并推测旧版本中的可利用路径。

Recorded Future披露的趋势显示，攻击者将漏洞转化为可实际利用代码的平均时间，已经从2025年的72小时缩短至2026年的24小时，时间窗口减少48小时，降幅为66.7%。这意味着企业过去“先观察一周再更新”的做法正在失效。

不过，漏洞披露量上升尚未对应到实际攻击量同步增长。美国政府维护的已知被利用漏洞目录显示，2026年新发现漏洞明显增加，但确认遭到实际利用的漏洞数量没有同幅上涨。这说明AI目前更明显地提升了发现能力，而不是让所有缺陷都立刻变成有效攻击工具。

对攻击者而言，从崩溃样例到稳定利用仍然存在距离。浏览器通常部署沙箱、站点隔离、控制流保护和内存缓解机制，攻击者往往需要组合多个漏洞才能逃逸沙箱并执行代码。AI可以加速分析，却不能消除现代浏览器利用链中的全部工程难题。

对开发者和企业，更新速度比漏洞总数更重要

企业不应因为“一个版本修了433个漏洞”而恐慌，更不应把漏洞数字低当成安全采购指标。更有意义的问题是：厂商是否能在内部发现问题、是否及时发布补丁、是否明确标注已被利用漏洞，以及终端能否在24小时级别完成升级。

开发团队需要为漏洞数量长期处于高位做好准备。随着AI首次系统性扫描大型代码库，未来一到两年可能出现类似“清库存”的披露高峰；当旧代码中的历史问题被逐步处理完，增长速度才可能趋于稳定。

企业侧至少需要调整三项策略：

• 将浏览器和互联网暴露软件的更新周期从按周压缩到按天，高危且已利用漏洞应进入紧急发布流程。
• 不再按CVE总数平均分配资源，而是结合可利用性、网络暴露面、权限影响和已知攻击情报排序。
• 监控自动更新覆盖率和版本滞后终端，避免补丁已经发布、实际设备却长期停留在旧版本。
• 为AI生成的漏洞报告建立去重和验证流程，防止安全团队被大量低质量结果淹没。

Chrome这次真正证明了什么

Chrome单月修复量超过过去两年总和，证明AI安全工具已经跨过“能不能用”的阶段，开始影响世界级软件项目的实际产能。这不是聊天机器人写几段代码的展示，而是模型、模糊测试、持续集成和人工审查共同组成的工业化流程。

这件事的积极面很明确：过去可能隐藏数年甚至十几年的缺陷，现在能更早暴露在厂商内部，并在成为攻击工具前被修补。Chrome内部报告占最新433个问题的92.6%，也是防守方暂时领先的重要信号。

这件事的隐忧也同样明确：漏洞发现速度可以由算力快速扩张，补丁验证、软件发布和用户更新却受制于组织流程。AI把漏洞发现从稀缺能力变成规模化能力之后，安全竞争的决定因素将不再是“谁先找到问题”，而是“谁能在24小时窗口内确认、修复并完成部署”。

对Google而言，6月超过1036个修复只是开端。对整个软件行业而言，一个漏洞数量看起来越来越吓人、但实际安全能力可能正在变强的时代，已经到来。

参考来源

• IT之家：综合报道2026年全球漏洞披露增长、Chrome修复433个漏洞及美国国家漏洞数据库统计。
• VulnCheck趋势报道（iThome）：整理2026年多家软件供应商CVE披露变化，并讨论AI辅助漏洞发现的影响。
• Google OSS-Fuzz GitHub仓库：Google面向开源软件维护的持续模糊测试基础设施，可用于理解自动化漏洞发现流程。
• Chromium GitHub镜像仓库：Chrome上游开源代码库，可用于了解浏览器代码规模、组件结构与测试体系。