Zoom 的“Zoomsday”漏洞使会议参与者面临风险

研究人员据称在不到 24 小时内、仅用不到 20 条 AI 提示词就构建出可用的接管漏洞利用程序后，Zoom 修复了这一跨平台漏洞。

Zoomsday 漏洞允许一名会议参与者攻击另一名参与者，无需点击或下载任何内容。攻击可触及 Zoom 的批注解析器、破坏内存，并形成一条通往远程代码执行的路径。

Zoomsday 报告强调了一个尤其令人不安的细节：公开可用的前沿 AI 模型帮助 A Security 在一天内从逆向工程推进到可用的漏洞利用程序。

这种速度才是核心故事。Zoom 在公开披露前修复了报告中的漏洞，但这项研究表明，进攻性开发不再需要数月的专业工作。

A Security 有商业动机强调这一结论。其关于研究速度和 AI 辅助的主张尚未获得完整的独立复现。Zoom 的公告确认了漏洞、受影响产品、研究人员以及远程代码执行影响。

这一结果让安全团队面临两个独立问题：他们既要修复 Zoom 漏洞，也必须重新评估那些建立在漏洞利用开发缓慢且昂贵这一假设之上的防御措施。

Zoom 在 Zoomsday 披露后修复了什么

Zoom 确认，会议流量可能使另一名参与者在其支持的客户端平台上面临远程代码执行风险。

主要漏洞 CVE-2026-53413 涉及 Zoom 批注功能中缺失的边界检查。批注功能允许通话参与者在共享内容上绘制、输入文字或放置形状。

根据 Zoom 的缓冲区覆盖公告，会议参与者可利用该漏洞在另一名参与者的设备上远程执行代码。Zoom 为其评定了 8.3 的 CVSS 分数，并归类为高严重性。

A Security 将实际结果描述为零点击远程代码执行。零点击意味着被攻击者无需打开文件、批准提示或点击链接。

攻击者仍需进入同一场会议。不过，攻击者无需主持会议、控制受害者账户，或说服受害者使用批注功能。

这一条件使正常的会议参与行为本身成为传递渠道。被攻陷的演示者可针对特定观众发起攻击，而恶意观众也可将同一易受攻击的解析路径导向演示者。

受影响的代码出现在 Windows、macOS、iOS 和 Android 上的原生 Zoom 客户端中。A Security 在描述更广泛的受影响产品范围时还列出了 Linux。

问题位于 Zoom 的专有批注协议中。客户端会从通过 Zoom 会议基础设施发送的消息中重建结构化绘图对象。

A Security 表示，攻击者可在文本批注对象中填入过大的字符计数。接收端解析器随后会将该计数的两倍复制到固定的 128 字节缓冲区中，而不检查目标大小。

这一操作可能会写入已分配缓冲区之外的区域，并破坏邻近内存。在易受攻击的系统上，经过精心控制的内存破坏可重定向程序执行，而非仅仅导致应用崩溃。

研究人员还报告了 CVE-2026-53414，这是另一个批注缓冲区越界读取漏洞。缓冲区越界读取发生在软件访问超出预期边界的数据时。

Zoom 的越界读取公告为该问题评定了 6.5 分，并将拒绝服务描述为其官方影响。A Security 认为，泄露的内存也可能帮助绕过地址空间布局随机化。

地址空间布局随机化，即 ASLR，会将代码和数据移动到不可预测的位置。攻击者往往需要先获取信息泄露，才能可靠地绕过这一防御机制来引导执行。

第三个问题 CVE-2026-53415 涉及同一批注组件中的释放后使用行为。释放后使用是指程序在释放内存后仍继续使用该内存。

Zoom 将该漏洞归功于其内部 Offensive Security 团队。该公司称，会议参与者可通过网络利用它实现远程代码执行。

补丁覆盖的不只是标准桌面客户端。受影响产品包括 Zoom Workplace、适用于 Windows 的 Zoom Workplace VDI Client、Zoom Rooms 和 Zoom Meeting SDK。

Zoom Workplace 用户需要在各自分支中升级至 7.1.5 或 7.0.6。VDI 客户端则视维护分支而定，需要升级至 7.0.11 或 6.6.16。

对于 CVE-2026-53415，低于 7.1.5 的 Zoom Rooms 和 Meeting SDK 版本会受到影响。Zoom 更早的公告将前两个漏洞的修复门槛列为 7.1.0。

这些区别对于受管环境很重要。若只检查主桌面客户端，会议室、虚拟桌面或嵌入式 SDK 部署仍可能暴露于风险之中。

披露时间线还显示，公开报告并非在修复前发布。A Security 表示，它于 2026 年 6 月 8 日发现初始漏洞，并在一天后确认了远程执行。

研究人员于 6 月 10 日向 Zoom 报告该问题。Zoom 于 6 月 11 日确认收到报告，并于 6 月 22 日发布首批客户端修复。

7 月 15 日，服务端缓解措施随之推出。Zoom 在 8 月 11 日协调披露前，于 7 月 20 日发布了针对 CVE-2026-53415 的后续客户端修复。

因此，tom hardware 的报道描述的是已修复漏洞，而不是尚未修补、正在传播的零日漏洞。当前的紧迫风险在于仍低于修复版本的客户端。

为什么一条批注消息可能演变为接管

攻击将协作绘图格式转化为一条从会议流量通向可执行控制权的路径。

Zoom 并不会将每一条批注都作为完成的图像传输。其客户端会将绘图元素序列化为结构化对象，发送这些对象，并在接收端设备上重建它们。

自由手绘标记、文本框、箭头或形状均有各自的数据结构。每个对象包含类型、几何信息、标志和文本格式等属性。

这种设计减少了每次更改后传输完整图像的需求。但它也要求每个接收端客户端解析由另一名会议参与者选择的大量数值。

Zoom AI 漏洞利用的起点正是这一信任边界。A Security 聚焦于处理可由远程参与者触及数据的代码，而不是同等审查每一个危险函数。

研究人员从 Zoom Android 客户端 7.0.4 版入手。据称，该软件包除应用的 Java 组件外，还包含 121 个原生共享库。

AI 辅助的排序流程在 70 个库中识别出 3,762 个函数，并优先处理涉及内存复制和计算大小分配等操作的代码路径。

最初的方法产生了误导性的优先级。若干排名靠前的函数处理的是本地摄像头或渲染活动，而非由他人控制的数据。

随后，团队反转了问题：他们不再询问危险操作位于何处，而是询问另一名参与者能通过实际会议流量触及哪些操作。

在实时通话中进行动态追踪后，他们识别出 Zoom 的批注库 libannotate.so。据称，该库在早先的静态分析中仅排在第 45 位。

这一转变很重要，因为漏洞研究依赖可达性。当攻击者无法提供输入或远程触发某个函数时，即使它看起来危险，也几乎没有进攻价值。

批注同时满足这两个条件：它处理来自其他参与者的复杂消息，而且即使被攻击用户没有绘图，功能的解析器仍处于活动状态。

该协议使用带计数字段和带长度字段。这意味着发送者提供数字，告知接收者需要处理多少元素或字节。

一个文本格式结构包含四个固定的 128 字节缓冲区。解析器从网络接受一个 32 位字符计数，并为每个字符复制两个字节。

易受攻击的函数会检查计数是否非零。A Security 表示，它没有将该计数与 128 字节的目标缓冲区进行比较。

因此，恶意数据包可以声明超过 64 个 UTF-16 字符。解析器会继续复制，越过缓冲区并写入相邻的栈或堆内存。

研究人员报告称，他们通过一条 745 字节的批注消息触及了易受攻击路径。Zoom 的常规加密传输负责传递该数据包，而受害者未经修改的客户端执行了危险解析。

在 macOS 上，A Security 发现相关批注组件缺少栈金丝雀和指针认证。这两种保护措施都可能使内存破坏更难转化为代码执行。

团队表示，溢出使其能够控制程序计数器和多个寄存器。随后，他们利用现有指令序列从 Zoom 进程启动 Safari。

启动浏览器只是一个可见的演示，并非报告所称的能力上限。在 Zoom 内执行的代码可能继承与应用及已登录用户相关的访问权限。

对于会议软件而言，这类访问权限尤其敏感。用户通常会授予其摄像头、麦克风、屏幕录制、联系人和本地文件权限。

Android 则需要不同的方法。研究人员描述了安排大小相近的堆对象、溢出至相邻对象，并部分修改其虚函数指针的过程。

这种被称为堆布局塑形的技术，旨在使内存布局足够可预测，从而实现可控的内存破坏。后续的对象操作便可能触发被修改的指针。

这些细节来自 A Security 自身的技术披露。Zoom 的公告确认了漏洞，但对完整利用链提供的信息较少。

这一区别很重要。Zoom 在 CVSS 向量中正式将用户交互描述为必需条件，而 A Security 则将实际攻击定性为对受害者零点击。

这并不一定意味着事实冲突。根据评分规则，加入攻击者的会议可能被视为交互，即便漏洞利用无需进一步操作。

Zoomsday 漏洞也挑战了关于封闭软件的一项常见假设。专有协议会使防御者无法访问源代码，但并不能阻止坚定的研究人员重建其行为。

AI 通过提出排序、映射字段和建议利用步骤，加快了这一重建过程。当最初的自动化排序追逐了错误攻击面时，人工判断仍重新引导了调查方向。

真正的压力来自 AI 辅助漏洞利用的速度

据称仅 20 条提示词的工作流程压缩了专家工作，但这并不意味着任何新手都能复现这次攻击。

A Security 表示，一名研究人员在不到 20 条提示词和不足 24 小时内，便从调查推进到可用的漏洞利用程序。所使用的模型是公开可用的，而非受限的政府系统。

这一说法赋予了这起事件更广泛的意义。传统上，漏洞利用的稀缺性取决于稀缺的专业能力、高昂的人力成本、有限的目标知识以及漫长的测试过程。

AI 可以减少其中一些限制。它可以总结反编译函数、提出攻击面优先级排序、还原消息格式，并生成有针对性的审计指引。

研究人员仍然需要 IDA、动态插桩、逆向工程知识和实际测试。IDA 是一种反汇编工具，用于在没有原始源代码的情况下检查已编译的软件。

该工作流程还使用了 Frida，这是一种可观察或修改运行中程序的动态插桩工具。并非模型能生成文本，这两种工具就会自动变得有用。

披露中展示的提示词反映出深厚的领域知识。它们要求进行 JNI 入口点映射、危险汇点评分、协议操作码恢复和内存安全分析。

初学者会难以评估这些回答，也难以发现结构上存在缺陷的排序。在这一案例中，首批自动生成的工作队列集中在远程参与者无法触及的代码上。

人类研究人员识别出这一失败，并改变了问题定义。下一阶段追踪了可经网络访问的会议功能，并发现标注功能才是有价值的目标。

这种协作说明了为什么“AI 找到了漏洞”这一说法并不完整。模型协助完成了分析，但由研究人员选择工具、构建问题、排除死胡同并验证结果。

即便如此，更快速的辅助仍改变了高级研究的经济性。熟练的操作人员可以测试更多假设、覆盖更多代码，并更快地将崩溃转化为漏洞利用。

学术研究已经指向这一方向。一项 2024 年关于 LLM exploit agents 的研究发现，在获得漏洞描述后，GPT-4 能够利用许多已知的一日漏洞。

一日漏洞不同于零日漏洞，因为前者已有公开信息。Zoomsday 针对的是没有公开协议规范的封闭软件，因此据称取得的结果要求更高。

这项研究并未建立未知漏洞的通用成功率。A Security 发布的是一个成功案例，而非涵盖大量失败目标的受控基准测试。

这会产生选择偏差。安全公司自然会公开其最强的发现，而失败的实验则较少受到关注。

“少于 20 个提示词”这一表述同样缺乏标准化的测量方式。一个提示词可能要求进行规模庞大、分多个阶段的分析，并依赖大量由工具生成的上下文。

提示词数量无法衡量模型 token、工具调用、研究人员准备工作、计算资源使用或既有专业能力。它不应被视为直接的人力指标。

Tom's Hardware 的报道框架捕捉到了令人震惊的速度，但读者应将已验证的产品影响与研究人员更广泛的经济结论区分开来。

Zoom 的公告独立验证了受影响组件、远程攻击路径、产品覆盖范围和代码执行风险。它们并未独立认证完整的 20 提示词工作流程。

A Security 详细列出的提示词摘录使这一说法更便于审视。不过，尚无独立团队在相同条件下公开复现完整的研究过程。

这种审慎解读并不意味着该结果不重要。它界定了现有证据能够支持什么，以及哪些内容仍属于公司主张。

有证据支持的结论是：AI 在一次快速且成功的漏洞调查中协助了一名经验丰富的研究人员。缺乏支持的推论是，如今任何人都能在没有协助的情况下制作出同样的漏洞利用。

防御方应为能力更强、速度更快的攻击者做好规划，但不应假定每个犯罪分子突然都具备国家级能力。在专业能力变得无关紧要之前，合格操作人员的数量就可能增长。

这一变化首先给软件供应商带来压力。他们的修补、内部测试和披露流程必须应对更短的漏洞利用开发周期。

它也给企业安全团队带来压力。当复杂武器化可能在数天甚至数小时内发生时，按月进行补丁更新将更难以辩护。

最后，它也给 AI 提供商带来压力。能够改进合法漏洞研究的模型，也可能转移知识，从而降低进攻性开发成本。

仅靠限制无法消除风险。同样的能力可以帮助供应商在发布前发现缺陷、生成测试、分析崩溃并确定修复优先级。

由此形成的竞赛并非人类与 AI 的对抗，而是 AI 辅助的防御者与 AI 辅助的研究人员和攻击者，在同一片不断扩大的软件攻击面上竞速。

加密保护了隐私，却使 Zoom 的缓解措施更复杂

端到端加密阻止 Zoom 检查恶意标注流量，同时让已在会议中的攻击者保有有效加密密钥。

Zoom 同时采取了客户端补丁和服务器端过滤措施。该过滤器可以在危险标注消息抵达易受攻击的客户端之前将其检测并阻止。

这一缓解措施覆盖使用 Zoom 默认增强加密的会议。在这些会话中，Zoom 的基础设施可以检查足够的消息内容，从而应用其过滤规则。

端到端加密会议带来了权衡。E2EE 阻止 Zoom 的服务器读取受保护的会议内容，这限制了服务器识别恶意标注对象的能力。

已在会议中的攻击者仍持有发送有效加密流量所需的密钥。因此，加密在数据包传输至易受攻击的解析器时保护了该数据包。

这并不意味着 E2EE 未能实现其预期目的。它保护了加密会话外部各方（包括服务提供商）无法获取内容机密性。

它只是不会验证经授权参与者放入加密通道中的内容。机密性与内存安全解决的是不同问题。

A Security 表示，在服务器端缓解措施部署后，较旧的易受攻击客户端在 E2EE 会议中仍然面临风险。持久的修正措施要求安装具有安全解析行为的客户端版本。

这一差异解释了为什么组织不能将 Zoom 7 月 15 日的服务器端缓解措施视为端点更新的替代品。该缓解措施在补丁逐步覆盖期间降低了暴露风险。

管理员应清点所有受影响的部署，包括 VDI 客户端、Rooms 系统以及嵌入 Meeting SDK 的产品。个人设备和外部访客可能使这项工作更复杂。

Zoom 允许管理员强制执行最低客户端版本。这项控制措施可以阻止过时的内部用户和访客加入受保护的会议。

运营上的挑战在于，在紧急强制执行与会议可用性之间取得平衡。不受支持的设备可能干扰客户通话、面试、医疗咨询和紧急协调。

安全团队应明确传达截止日期和修正后的版本。随后应阻止过时客户端，而不是无限期依赖用户自愿重启。

受管设备可通过端点管理系统接收更新。验证应在安装后确认实际运行的版本，因为已下载的软件包并不保证运行中的进程已经更新。

在团队完成修补期间，会议控制措施可提供额外防护层。等候室、密码、已认证用户要求和受限会议链接可减少能够触及易受攻击攻击面的人员。

这些控制措施无法修正解析器。但它们仍可阻止未知参与者获得实施利用所需的会议内位置。

限制可选功能也可减少攻击面。不需要标注、白板、文件传输或远程控制的组织，可以在账户层面禁用这些功能。

浏览器客户端可能为敏感通话提供另一种临时选择。A Security 指出，它在浏览器沙箱内运行时不具备原生标注和白板功能。

通过浏览器参会会带来功能和可用性方面的权衡。在未测试音频、视频、身份和无障碍要求之前，它不应成为普遍建议。

修补后，端点检测仍然具有相关性。会议应用程序意外启动 shell、浏览器或脚本解释器时，应触发警报。

集中式崩溃报告也能揭示失败的利用尝试。在操作人员实现可靠执行之前，内存损坏攻击常会反复导致目标应用程序崩溃。

组织应审查 Zoom 进程在无法解释的崩溃发生前后的活动。它们也应保留相关端点遥测数据，而不是假定每次崩溃都反映普通的不稳定情况。

没有任何被引用的来源确认已在现实环境中出现大规模利用。这一缺失应避免人们声称数亿台设备实际上已经遭到入侵。

由于 Zoom 服务于大型组织和个人用户，其潜在覆盖范围很广。潜在暴露、已确认的利用和成功入侵是三种不同的衡量指标。

A Security 表示，Zoom 被 70% 的《财富》100 强企业使用。该统计来自研究人员，描述的是组织采用情况，而非易受攻击客户端的数量。

在披露时，Zoom 和研究人员均未发布经验证的、运行受影响版本的设备数量。有关数亿人的标题描述的是理论覆盖范围。

Zoom 的 AI 漏洞利用很严重，无需夸大其受害者数量。跨主流操作系统、同一会议内的代码执行路径本身就足以构成紧迫性。

Tom's Hardware 报道后，安全团队应关注什么

补丁采用情况、漏洞利用复现，以及 AI 辅助研究的变化，将决定 Zoomsday 是成为受控案例，还是持久的安全标志。

第一个信号是已修正客户端的采用情况。企业应衡量自身部署数据，而不是等待 Zoom 发布全球比例。

低于 7.1.5 和 7.0.6 版本的客户端数量下降，将削弱即时风险。持续存在的旧版客户端会让实际暴露窗口继续敞开。

VDI 分支应单独报告，因为其版本号不同。Zoom Rooms 和 Meeting SDK 安装也应作为独立资产类别出现。

第二个信号是独立的漏洞利用分析。A Security 私下演示了代码执行并发布了大量技术细节，但公开复现将使威胁评估更为明确。

可靠的第三方概念验证将确认哪些操作系统和配置仍最容易被利用。它也会加速犯罪分子针对未修补设备的适应。

相反，未成功的独立尝试可能揭示被省略的前提条件或可靠性限制。这将在不改变安装修复措施必要性的前提下，缩小实际威胁范围。

安全供应商很可能会将已发布的细节转化为检测能力。有用的指标可能包括格式异常的标注流量、异常的 Zoom 子进程或可识别的崩溃特征。

这些检测必须考虑 E2EE 的可见性限制。网络工具无法检查 Zoom 服务器和企业网关无法解密的内容。

因此，端点遥测对 E2EE 通话更为重要。防御者应关注 Zoom 启动了什么、访问了哪些资源，以及其崩溃频率。

第三个信号是，AI 辅助的进攻性研究是否会在其他封闭企业应用中产生可比结果。单一成功案例本身并不能定义一种趋势。

有力证据应包括可重复的发现、披露的方法、独立验证，以及与传统研究工作流程的明确比较。

薄弱的证据往往只是惊人的提示词数量，却没有技术记录。安全采购方应询问研究人员如何衡量时间、人类投入、工具使用情况以及失败尝试。

模型提供商也将塑造下一阶段。能力更强的网络安全模型可帮助防御方审计代码、分类报告并更快产出补丁。

同样的模型也可能在补丁暴露漏洞位置后，缩短漏洞利用开发的时间。这种双重用途使严格的访问控制与监控尤为重要。

供应商应假设，已发布的补丁会成为对手分析的地图。因此，披露后延迟部署会带来日益增加的风险。

他们还应在公开研究人员之前测试协议解析器。模糊测试会发送意外输入以发现崩溃，对于基于计数的二进制格式尤其相关。

内存安全语言可以减少某些类别的漏洞，但替换原生组件需要时间。现有的 C 和 C++ 解析器仍需要边界检查、加固措施和持续的对抗性测试。

Zoom 的响应提供了一个令人鼓舞的信号。据 A Security 报道，该公司在一天内确认了该报告，并在 12 天后发布了首个客户端修复。

Zoom 还在公开披露前加入了服务器端缓解措施，并与 CVE 编号分配协调发布。这一响应缩短了技术披露与公开漏洞利用指导之间的时间窗口。

然而，供应商的快速响应无法更新每一台客户设备。资产可见性和强制执行的客户端基线仍是客户自身的责任。

即使雇主管理着主力笔记本电脑，知识工作者也应更新个人设备。通过手机或家用电脑加入的会议，仍会处理由参会者控制的流量。

主持人应避免公开分发可重复使用的会议链接。当会议内容或参与者较为敏感时，应使用等候室和经过身份验证的访问方式。

嵌入 Zoom Meeting SDK 的开发者必须检查其发布版本。更新个人 Zoom 应用并不会更新捆绑在其他产品中的独立 SDK。

安全负责人也应修订事件假设。即使无人共享文件或点击链接，视频通话也可能成为攻击面。

这一教训不止适用于 Zoom。协作客户端会解析来自其他用户的聊天内容、媒体流、共享文档、表情回应、绘图和远程控制消息。

每项功能都会形成一个协议攻击面。最安全的会议策略无法弥补不安全的解析，但可被触达的功能更少，攻击者的选择也更少。

Zoomsday 漏洞之后的核心问题，并不是 AI 是否独立取代了一名漏洞利用研究员。现有证据并不支持这一说法。

问题在于，经验丰富的研究人员如今是否能够以超越普通企业补丁部署速度的节奏工作。这个案例为肯定回答提供了可信理由。

组织现在应核查每一个 Zoom 客户端和嵌入式组件，然后衡量完成全面部署所需的时间。这段时间才是它们真正的暴露窗口。

如果防御方能在另一位 AI 辅助研究人员找到类似路径之前缩短这一窗口，下一条 tom hardware 的头条就不再那么重要。