半年拉锯：控制平面的数据库为何频频损坏

Tailscale 的工程师团队在排查中发现，公司的控制平面（control plane）数据库会间歇性地出现损坏，进而导致服务不稳定。这段时间里，客户和员工都深受其扰，而问题却像捉迷藏一样时隐时现——曾有连续六周的「虚假平静」，让团队一度以为已经修好。

真正的突破口，来自对 SQLite 预写日志（Write-Ahead Log，简称 WAL）机制的一次深入剖析。WAL 是现代 SQLite 在写入数据时采用的模式：新数据先追加到日志文件，再由「检查点」（checkpoint）操作把日志内容正式写回数据库主文件。Tailscale 团队发现，当一次写入事务与一次 WAL 重置（WAL-reset）发生在极短的时间窗口内重叠时，就会触发一个边界情况的竞态条件，进而让索引与数据不同步，最终造成数据库损坏。

漏洞藏在 WAL 重置的瞬间

问题的精确触发条件相当苛刻：一个连接正在执行检查点操作，且这次检查点必须顺利完成；紧接着第二个检查点启动，而在它运行期间，另一个数据库连接提交了一笔事务，把 WAL 文件冲刷一遍并向文件开头写入了新内容。由于数据访问发生冲突，第二个检查点没有意识到 WAL 文件已被那笔事务冲刷过，于是在 WAL 索引头里写入了错误的字段值，误以为部分事务已经提交。后续再有事务提交时，WAL 文件里的页数超过了第一次检查点时的页数，等到第三次检查点发生时，第二步写入的那部分事务被整段跳过，永远没能进入数据库主文件，损坏就此产生。

更令人意外的是，这个漏洞影响范围极广。它存在于自 SQLite 3.7.0（发布于 2010 年 7 月 21 日）起、直到 3.51.2 的所有版本。也就是说，十六年来几乎所有基于 WAL 模式的 SQLite 部署都携带这一隐患。修复先是在 3.51.3 版本（2025 年 3 月）中落地，部分较早版本也拿到了热修复补丁（3.44.6 与 3.50.7）。后续的 3.53.0 版本还新增了自动自愈的索引功能，从机制上防止过期表达式索引再次引发同类问题。

Tailscale 为何偏偏踩中：偏离了「标准路径」

值得玩味的是，绝大多数开发者从未遇到这个问题。SQLite 拥有远超代码量的测试套件，被公认为软件可靠性的标杆。Tailscale 之所以中招，是因为他们以非标准的方式使用了这项「无聊的技术」：团队手动接管了检查点过程，并按照自己激进的节奏来运行，从而踏上了常规配置之外的小径。

整个排查是一场跨职能的苦战，动用了数十人，包括 Tailscale 的工程与客服团队，以及 SQLite 的核心维护者。为了隔离这个竞态条件，Tailscale 还资助了一个开源的 SQLite VFS（虚拟文件系统）中间层工具，帮助在未来追踪类似问题。

等了两个月，才等来那声「令人愉快的警报」

为了拿到生产环境确实发生该竞态的正面证据，Tailscale 在自家的 SQLite 驱动里打了补丁：当写入事务与 WAL 重置重叠时，记录一条警告。随后便是漫长的等待——两周、一月、两月。就在团队开始怀疑补丁是否失效、理论是否出错时，那条等待已久的警报终于触发，证明这个精确条件在真实生产环境中确实会出现。此后，系统又平稳运行了四个月，再无数据库事故。

启示：成熟技术也怕「非常规用法」

这起事件给工程界提了个醒：运行成熟技术时，如果脱离常规配置、以非标准方式使用，风险会被悄然放大。常见的路径和标准配置经过了极其充分的测试，可靠性很高；而一旦为了性能或控制力手动接管底层机制，就必须为那些「几乎不可能发生」的边缘错误做好准备。对依赖 SQLite 存储关键数据的系统而言，定期执行完整性校验、保留可靠的备份与恢复流程，依旧是必要的兜底手段。

来源：Tailscale 工程博客《How we tracked down a 16-year-old SQLite bug》

变量是 AI。谷歌在 2026 年上线了一套基于 Gemini 的智能体框架，专门在整个 Chrome 代码库里翻找漏洞。最典型的战果，是一个从 2013 年就存在的沙箱逃逸漏洞——它能骗浏览器去读取本地文件，十几年里躲过了一轮又一轮测试，今年初被 AI 挖了出来。谷歌还把漏洞处理拆成四段流水线：先让智能体过滤掉重复和无效的报告，再在对应系统的虚拟环境里复现问题、补上调用栈信息，把最耗人力的环节交给机器。

Chrome 全球约有 35 亿活跃用户、七成多的浏览器份额，修得越快，风险窗口就越短，甚至可能需要一周发两次补丁。

我的判断是，这条消息真正的重点不在「谷歌很努力」，而在另一面：AI 能这么高效地找出漏洞，攻击者手里的 AI 同样能。谷歌先发现的那批，未必就是别人正在利用的那批。

所以最实在的动作只有一个：别再拖着那个「重启以完成更新」的提示不点。你的浏览器，多久没重启过了？

来源：ZDNET

两个版本，1072 个漏洞

Chrome 安全团队在 7 月 30 日发布的报告中给出了一组扎眼的数字：6 月发布的两个大版本 Chrome 149 与 Chrome 150，合计修复了 1072 个安全漏洞。作为对照，此前两年发布的 23 个版本加在一起，修复总数为 1036 个。换句话说，两个版本干完的活，超过了过去两年的总和。

这些漏洞中确实有一部分来自外部研究者提交，但激增的主因是 Chrome 安全团队内部流程的快速演进——他们把 AI 工具全面接入了漏洞发现、分级和补丁开发的每一个环节。

“在 Chrome，我们从 2012 年起就在用机器学习——在它还没被叫作 AI 的时候——来辅助发现漏洞、自动化模糊测试工作。这一直是我们发现漏洞、赋能开发者的重要手段。”Chrome 副总裁兼总经理帕丽萨·塔布里兹（Parisa Tabriz）表示，”但今年确实很不一样。无论进攻还是防守，都真切地到了一个拐点。”

从两周一次到每周两次

Chrome 原本已经在向”每两周一个大版本、外加每周一次安全更新”的节奏靠拢。但漏洞发现的密度实在太高，团队把新模型和新能力接入工作流后成效又太显著，最终决定试点每周推送两次安全修复。

“我们走到这一步的原因很简单：修复实在太多了。所以在这段时间里每周提供两次更新，对我们来说最合理。”Chrome 工程总监道格·特纳（Doug Turner）说，”会不会一直这样？谁知道呢。”

特纳向外界解释了这套系统为什么这么能挖。谷歌训练的模型掌握了两类关键知识：一是历史上出现过的每一个安全漏洞编号，二是 Chromium 代码库全部提交历史中每一行代码被修改的原因。

“我们训练模型，让它了解我们过去见过的每一个安全漏洞，”特纳说，”第二件很酷的事情是，Chromium 历史上的每一行代码，模型都知道它当初为什么被改。”

这套上下文让 AI 工具能在 Chrome 这个庞大复杂的代码库里精准锁定潜在弱点，包括那些早已不再活跃开发、也很少有人再去审视的功能模块——比如打印功能。

一个藏了 13 年的沙箱逃逸

公开资料显示，谷歌在 2026 年初部署了基于 Gemini 构建的智能体框架，扫描范围覆盖整个 Chrome 代码库，而不再局限于模糊测试能触达的代码路径。这套框架支持开放权重模型与闭源模型协同工作，会多轮运行以抵消模型输出的不确定性，并调用一个由 Chromium 全部版本历史和历史漏洞构成的知识库。

其中最引人注目的一项发现，是一个在代码库里静静躺了 13 年多的沙箱逃逸漏洞。该缺陷可让被攻陷的渲染进程绕过隔离机制，诱使浏览器读取用户本地的文件。它之所以能存活这么久，并非因为多么隐蔽，而是传统安全审查要么从正在变动的代码入手，要么依赖能触发崩溃的输入，要么等外部研究者上报——没有哪一种方法是为”把 13 年前的老代码重新翻一遍”设计的。

此外，谷歌 DeepMind 与 Project Zero 合作的 BigSleep 项目，以及自动修复工具 CodeMender，如今已原生嵌入 Chrome 的持续集成系统，每 24 小时对全球开发者提交的所有代码变更跑一遍。仅 2026 年 5 月一个月，这套集成就拦下了 20 多个漏洞，其中包括一个被评为最高严重级别的缺陷。

不只是谷歌

同样的趋势正在其他厂商身上出现。微软本月早些时候宣布，在例行的”补丁星期二”更新中，一次性修复了创纪录的 570 个安全漏洞，并将激增归因于内部对 AI 的使用。苹果则暂未出现类似的指数级增长——独立统计显示，苹果 2026 年至今修复了 482 个漏洞，大致与去年持平，也和 2015 年的水平相当。

这波浪潮会持续多久

特纳和其他安全研究者都认为，AI 带来的漏洞发现狂潮未必是永久状态。至少对 Chrome 这类成熟稳定的产品而言，等到 AI 能找出来的漏洞被清理得差不多之后，新漏洞数量会出现回落。原因之一在于，模型可以被训练成对软件项目的演进历史了如指掌。

除了这种”打地鼠”式的补丁工作，Chrome 安全团队同时把重心放在结构性改造上——例如把部分 C++ 代码用内存安全的 Rust 语言重写，从而让整类常见漏洞彻底不再成立。

“眼下有一个短期的高峰，但我认为会形成新的平衡，”塔布里兹说，”我觉得对整个行业而言，真正重要的是所有在做软件安全的人都把 AI 纳入自己的开发流程。我最大的期望是一切都变得更安全。但我不会假设一切都会自动变好，也不认为这是免费的。”

来源：WIRED《Chrome Needs Twice-a-Week Patching Thanks to AI Bug Hunting》（作者 Lily Hay Newman）；补充资料参考 TechCrunch 与谷歌安全博客公开报告

图片来源：WIRED

推动这一变化的不是突然涌入的大量人工报告，而是谷歌内部 AI 工具在漏洞发现领域的规模化应用。

从六年一周到一周两次

回顾 Chrome 的安全更新历史，节奏一直在加快。

十年前，Chrome 率先引入自动更新机制时，每六周发布一次安全补丁的做法还颇具争议。如今这已成为主流软件的标配。但进入 2026 年后，连这个频率也跟不上了。

Chrome 安全团队负责人帕丽萨·塔布里兹（Parisa Tabriz）在接受 Wired 采访时表示，谷歌至少从 2012 年起就开始在安全领域使用机器学习（当时还不叫”AI”），主要用于自动化模糊测试和漏洞发现。”但今年真的很不一样，”她说，”无论对攻方还是防方来说，这都是一个拐点。”

工程总监道格·特纳（Doug Turner）透露，由于漏洞修复数量激增，Chrome 团队目前正在试点每周发布两次安全更新的新节奏。”我们走到这一步是因为漏洞修复实在太多了，每周两次是目前最合理的方案，”特纳说，”这是否会永远持续？谁也不知道。”

AI 如何改变了漏洞发现

谷歌在 7 月 30 日发布的白皮书中详细介绍了这套 AI 驱动的安全系统：

发现端：团队利用 Gemini 等大语言模型构建了代理覆盖系统，能够理解 Chromium 代码库中每一行代码的历史变更原因、每一个已知 CVE（通用漏洞披露）的细节。这让 AI 工具可以精准定位潜在弱点——包括那些已经不再活跃开发的功能（比如打印模块），这些区域通常不再吸引人类安全研究者的目光。

一个典型案例是：AI 系统在 Chromium 代码库中发现了一个潜伏了 13 年的沙箱逃逸漏洞。攻击者可利用该漏洞绕过沙箱机制读取用户本地文件。这种”沉睡”多年的老漏洞，靠传统人工审计很难被发现。

排序与验证端：AI 发现漏洞后会立即介入优先级排序——过滤重复或描述不清的报告、自动生成概念验证代码并在多个操作系统上复现问题、评估严重程度并分配给对应的开发人员。这套自动化流程每月为开发者节省数百小时。

修复端：系统采用”修复代理”生成多个候选补丁，再由”批评代理”从中筛选最优方案。整个流水线已在最近的版本中大规模运转。

不只是 Chrome 的问题

Chrome 并非唯一一家因 AI 而大幅提升漏洞修复数量的公司。

微软在本月早些时候宣布，在例行的”补丁星期二”更新中一次性修复了创纪录的 570 个安全漏洞，微软同样将数量激增归因于内部 AI 工具的使用。独立统计显示，苹果 2026 年至今已修复约 482 个产品漏洞，尚未呈现同样的指数级增长。

网络安全行业此前已多次警告：AI 将以越来越快的速度发现海量软件漏洞，数量甚至可能呈指数增长。面对同样使用 AI 的恶意黑客，防御方也必须依靠 AI 来跑在对手前面。

补丁疲劳与新平衡

更频繁的补丁意味着用户需要更频繁地重启浏览器。为了缓解这个问题，谷歌正在探索多项技术：

• 缩短主版本周期：从传统的 4 周缩短至 2 周
• macOS “零窗口重启”：Chrome 150 引入了新机制——当用户关闭窗口但未退出应用时（macOS 应用在此状态下仍在后台运行），Chrome 利用这段时间自动完成更新安装
• 动态补丁技术：正在研发中的底层改进，目标是让补丁在浏览器运行时直接安装，无需任何形式的重启

塔布里兹认为，当前的高频修补是一个”近期的峰值”，行业最终会达到一个新的平衡点。”对于像 Chrome 这样成熟稳定的产品，一旦 AI 能发现的漏洞大部分被修复完毕，新发现的数量应该会出现下降，”她解释说，”因为 AI 模型可以被训练成对软件项目的演化历史有百科全书般的理解。”

但她同时强调：”我不会假设一切都会自动变好。安全不会免费到来。”

对开发者的启示

Chrome 的经验对整个软件行业具有参考意义。当 AI 将漏洞发现从”手工作业”变成”工业化流水线”后，安全团队的工作重心将从”找漏洞”转向”管理漏洞修复节奏”和”构建纵深防御”。

谷歌也在同步推进结构性安全改进——将部分 C++ 代码用内存安全的 Rust 语言重写，从架构层面消除整类常见漏洞。这种”发现+根治”双管齐下的策略，可能是 AI 时代软件安全的标准答案。

来源：Wired，原文链接 https://www.wired.com/story/chrome-needs-twice-a-week-patching-thanks-to-ai-bug-hunting-for-now/