漏洞出在哪里

Click2Shell 与 WordPress 的“主题预览”功能处理 URL 参数的方式有关。同一个主题预览链接中的参数，会先后被 WordPress.org 主题 API 和管理员浏览器中的 JavaScript 代码分别解析：主题 API 将其视作普通的主题名称（Slug），而浏览器端则保留了原始字符，并将其进一步插入 jQuery 选择器。在特定条件下，这种解析差异可以形成一条可被利用的攻击链。

攻击者只需构造一条特殊的主题预览链接，诱导已登录的管理员打开，即可在目标站点上安装攻击者指定的主题，进而加载恶意 PHP 代码。

实际危害有多大

根据 pwn.ai 的分析，单独的“强制安装主题”漏洞被评为 CVSS 7.1（高危）。但研究人员演示了更危险的一环：若将该漏洞与所安装主题中的二次缺陷（例如官方目录中的 Mobile Repair Zone 主题存在一个无需权限校验的后台处理程序）相结合，攻击者就能在服务器上执行自己的代码，整条攻击链的评级高达 CVSS 9.6（严重）。

不过，这一攻击链存在前置条件：潜在受害者需要登录 WordPress 后台，并且在此前的同一浏览器会话中访问过攻击者准备的恶意网站。因此，并非任意未登录用户都能直接利用该漏洞。目前尚无证据表明 Click2Shell 已在真实环境中被利用。

哪些版本受影响，如何修复

该漏洞影响 WordPress 6.0 至 7.1.1 发布前的所有版本，修复已回溯到 4.7 在内的所有受支持分支。WordPress 官方没有给出变通方案，升级核心程序是唯一有效的缓解手段。运行 7.1 系列的管理员应尽快升级至 7.1.1；开启了自动更新的站点会自动接收补丁。

pwn.ai 近期已两度披露 WordPress 核心的同类缺陷：8 月的一起位于登录界面，同样可链式触发代码执行；而 7 月披露的“wp2shell”漏洞则无需登录与交互，已被美国网络安全和基础设施安全局（CISA）列入已知被利用漏洞目录，与本次 Click2Shell 无关。

Fleet Device Management 近日宣布加入 Anthropic 发起的 Project Glasswing 计划，成为首批借助 Claude Mythos Preview 模型探索终端安全管理自动化的企业之一。Fleet 是一家以开源方式提供跨平台终端管理工具的厂商，其产品覆盖 macOS、Windows 与 Linux 设备的统一纳管。

Project Glasswing 是 Anthropic 于 2026 年 4 月启动的网络安全倡议，参与方包括亚马逊云科技、苹果、博通、思科、CrowdStrike、谷歌、摩根大通、Linux 基金会、微软、英伟达与 Palo Alto Networks 等十余家科技与安全企业。该计划的核心，是使用一款名为 Claude Mythos Preview 的未发布前沿模型，在受控环境下开展防御性漏洞挖掘与软件加固。

补丁速度追不上攻击速度

Fleet 发起的“IT 中的 AI 之路”研究显示，79% 的组织部署关键安全补丁需要超过一天时间，而攻击者往往在漏洞曝光后数小时内便开始利用。这一时间差，正是 Fleet 希望借助前沿 AI 缩小的核心问题。

“当今 AI 驱动的攻击速度，已经从根本上改变了企业对技术供应商的期待。”Abridge 高级 IT 工程师 Gabe Chan 表示，“漏洞几乎在被恶意利用者瞬间操纵。供应商必须持续改进识别、评估和响应风险的方式。”

Fleet 首席执行官兼联合创始人 Mike McNeil 称，在公司成立纪念日之际重申对产品安全的投入“恰如其分”。由于 Fleet 采用开源模式，这次与 Anthropic 的合作成果也将向客户与更广泛的安全社区公开，帮助外界理解前沿 AI 能在哪些环节切实提升终端管理工作流的安全性。

Claude Mythos 的漏洞发现能力

根据 Anthropic 公开资料，Claude Mythos Preview 在主流操作系统与浏览器中已发现数千个高危漏洞，其定位效率约为以往 AI 模型的 10 倍。在 Firefox 的实际应用中，该模型曾在一个月内协助修复 423 个安全漏洞，其中 271 个由其直接发现，包含 180 个高危漏洞以及多个潜伏 15 至 20 年的历史遗留漏洞。

在多组网络安全基准上，Mythos Preview 显著领先于上一代模型：

Anthropic 表示不会将 Mythos Preview 公开发布，而是在完善安全护栏后，先将其能力用于防御目的，并向行业公开研究报告与建议。

对国内企业的启示

终端安全是企业信息安全的基础环节。Fleet 的尝试说明，前沿 AI 正在从“辅助写代码”走向“辅助守安全”——自动理解终端状态、为修复排定优先级、加快内部安全运营响应。对中国市场的企业而言，补丁延迟与攻击时效之间的缺口同样普遍，将 AI 用于漏洞分诊与补丁自动化，有望缩短从发现到修复的平均周期。

由于 Fleet 承诺以开源方式公开实验结论，这次合作产出的方法论，也将为终端管理与安全社区提供可复用的参考。在 AI 能力快速扩散的背景下，让防御方率先获得可持续的优势，正成为头部厂商的共识。

苹果于 8 月 18 日发布 Safari 26.6.1，面向 macOS Sonoma 与 macOS Sequoia 用户。此次更新共修复 22 个与 WebKit 相关的漏洞，建议相关 Mac 用户尽快升级。

22 个漏洞全部来自 WebKit

根据苹果”安全发布”页面的说明，Safari 26.6.1 包含的 22 个漏洞均与 WebKit 引擎有关。其中部分漏洞在描述中明确指出：处理恶意构造的网页内容可能导致内存损坏；另一些则会引发 Safari 意外崩溃或进程异常终止。

还有一个涉及”WebKit 历史记录”的漏洞（编号 CVE-2026-64778）指出，访问被恶意构造的网站可能导致敏感数据泄露。整体来看，这些问题大多与网页内容解析过程中的内存处理、边界检查与状态管理有关。

AI 工具成为漏洞发现主力

一个有意思的细节是：在漏洞致谢名单中，OpenAI 的 Codex Security 团队被列出了 9 次，进一步凸显 AI 工具在发现苹果软件安全漏洞方面日益重要的作用。

例如，在 CVE-2026-64784（一个越界访问问题，通过改进边界检查修复）的致谢中，就出现了 OpenAI Codex Security 的 Amy Burnett；多个其他 CVE 同样将她或该团队列为发现者。这与近期多次安全更新中 AI 工具频频登上致谢榜的趋势一致。

建议尽快更新

由于这些漏洞均可通过特制网页触发，使用 Safari 浏览网页的用户面临实际风险。运行 macOS Sonoma 或 macOS Sequoia 的 Mac 用户，可在系统更新中检查并安装 Safari 26.6.1。保持浏览器及时更新，仍是最基础也最有效的安全习惯。

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

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/