文章总结： 微信语音通话被曝存在零点击远程代码执行漏洞,攻击者拨打语音电话即可在响铃阶段触发内存破坏漏洞,无需用户接听或点击即可接管账号,并可通过好友关系链跨平台蠕虫式传播。腾讯已发布修复版本并完成服务端缓解,公开利用方式已失效。事件警示安全防线需从用户操作前移到程序后台处理环节。 综合评分： 88 文章分类： 漏洞分析,应急响应,移动安全,漏洞预警,安全大事件

微信电话还没接，攻击就发生了

原创

messfree messfree

MessFreeSecurity

2026年9月9日 10:28 北京

在小说阅读器读本章

去阅读

在公众号小说中沉浸阅读

9 月 8 日 Calif 公开 WeWorm 演示后，做移动安全、客户端和应急的人大概都会先停一下：攻击者只要在微信好友里拨出语音电话，受害者不用接听，也不用点击，响铃阶段客户端就可能触发内存漏洞，随后账号被接管，消息可被读取、发送，通话也能被发起。

让人警觉的是，人的操作没有发生。来电显示、邀请解析、状态更新这些动作，客户端已经在处理数据。接听是人的交互点，不一定是程序的处理点。把电话理解成”只有接通后才有风险”，放到这条链路上就不成立。

这件事要把两条线分开看：Calif 已经演示并确认了什么，公开信息能支持我们推到哪一步。腾讯在 8 月发布 Android 8.0.77、iOS 8.0.76，8 月 28 日完成服务端全量缓解，目前公开利用方式已经失效。后文涉及触发细节、利用原语和传播机制的部分，会明确标注为基于公开信息和通用架构的推测。

一通没接的语音电话，为什么能进到账号里

Calif 的演示路径很直接：攻击者用一部 Android 手机拨打目标 iPhone 的微信语音，电话还在响铃，漏洞就被触发，目标设备上的微信账号被接管。随后这部被控制的 iPhone 又拨打另一部 Android 手机，以同样方式完成传播。

整个过程可以概括成三步：攻击者拨出语音电话，受害者账号被接管，受害者继续拨打下一名联系人。

攻击成功后，Calif 演示的能力包括读取和发送微信消息、发起通话，以受害者身份进行操作。这些是公开演示中已经确认的范围。若再与其他移动系统漏洞结合，影响可能从账号接管扩大到设备控制，但这一步 Calif 没有在公开材料中演示。

有一个前提不能忽略：攻击者需要出现在受害者的微信好友列表中。这确实缩小了直接攻击面，不是随便一个陌生人拨号都能成功。但在蠕虫场景下，这个门槛的意义会变。攻击者先拿下任意一个普通账号，就能依托该账号的好友关系，批量触达信任链路上的所有人。社交软件赋予联系人的高权限和免核验机制，在蠕虫面前会反向成为传播的助力。

响铃时，客户端已经在工作

要理解”零点击”，得先看响铃时客户端已经处理了什么。

微信语音通话的来电邀请到达后，客户端不会等用户按下”接听”才开始工作。它需要先解析呼叫邀请，准备来电人信息、会话参数、编解码能力和扩展字段，建立会话状态，然后才能显示来电页面并响铃。铃声响起的那一刻，程序已经走完了好几步数据处理。

Calif 公开的信息确认了两点。第一，漏洞位于微信 VoIP 语音通话组件的内存破坏缺陷。第二，演示展示了 iOS 和 Android 之间的跨平台传播。具体是哪一个字段、哪一条解析路径出了问题，Calif 没有公开，计划在后续安全会议上做更深入的分析。

这也是为什么”零点击”这个说法容易让人误判。它描述的是用户没有主动操作，不代表程序没有处理数据。用户看到的是一个响铃界面，程序在后台已经完成了邀请解析、状态初始化和部分媒体准备。漏洞就藏在这些用户看不见的步骤里。

接听是人的交互点，不一定是程序的处理点

这一节专门把”零点击”的边界说清楚。

用户没有按下”接听”，不代表客户端没有收包、没有解析邀请、没有更新状态。接听是人的交互点，不一定是程序的处理点。

但”零点击”也不等于每次呼叫都会成功。它的含义是受害者无需接听或点击，响铃处理就可能进入漏洞路径。实际传播效果受多个因素影响：

受害者拒接可以挡住当次尝试，攻击者仍可重拨。好友是否在线、客户端是否已更新到修复版本、服务端风控是否拦截，都会改变结果。Calif 演示的是在特定版本、特定条件下的利用链，不是对所有用户、所有版本都稳定生效的通用武器。

还有一个细节容易被忽略：即使受害者接听了电话，攻击也不会因此中断。听筒里可能听不到任何声音，但底层代码的恶意执行流程已经在运行。人的接听动作，无法终止已经触发的漏洞利用。

从这里开始，涉及响铃阶段的具体触发路径和利用原语，公开材料没有给出完整实现。下面只能做推测。

从异常邀请到代码执行：公开信息之外的那段链路

先把边界说清楚：下面这段是基于 Calif 已公开的现象、移动端 VoIP 的通用架构和常见内存漏洞利用方式做的推测，不是 Calif 披露的实现细节。公开信息能确认的是，攻击者拨出微信语音电话后，受害端在响铃阶段就可能被触发；具体是哪一个字段、哪一条指令导致崩溃或执行，Calif 没有公开。

客户端收到语音电话时，需要先解析呼叫邀请，准备来电人、会话参数、编解码信息和扩展字段，才能显示来电页面并响铃。一个合理推测是，邀请消息里存在变长字段或嵌套结构，解析时对长度、数量或嵌套层级的校验没有兜住。长度计算如果发生整数溢出，程序可能按错误尺寸申请堆内存；后续复制数据时，就可能把内容写到缓冲区边界之外，形成堆越界写。

从越界写到能控制进程，通常还要经过几道利用环节。攻击者可能先通过信息泄露拿到模块地址或堆地址，削弱 ASLR 的保护。ASLR 的作用是让模块和堆地址随机化，增加利用难度；一旦地址被泄露，随机化的效果就会打折扣。随后攻击者把一次越界写扩展成任意读写，去修改函数指针、虚表指针，或者直接篡改承载会话状态的业务对象。任意读写的意思是，攻击者可以读取或改写进程中原本不该碰的地址。

iOS 和 Android 的利用路径不会完全一样。iOS 有 PAC，也就是指针签名机制，随意伪造指针通常会被拦截，利用者可能需要复用已经签名的指针，或者绕到数据层面的控制路径。Android 的 Scudo 会检查堆块元数据和部分越界行为，堆布局、对象生命周期和写入时机也要重新适配。以上都是通用利用经验推演，公开材料没有说明 WeWorm 具体采用了哪一种读写原语，也没有披露它覆盖了哪个对象。

还有一种可能：要接管当前微信会话，不一定需要把整部手机变成一个拥有系统权限的 RCE 终端。微信登录态和授权上下文如果保存在进程内存中，攻击者一旦能够改写相关业务对象，或许可以复用当前登录态调用内部的收发消息、发起通话等接口，达到会话级控制。会话级控制的意思是借用当前登录态操作微信，权限范围通常小于整机系统接管。

这个层级的结果是当前微信账号被接管。它不等于账号密码被拿走，也不等于设备系统权限已经失守；支付密码、生物识别和系统沙箱仍可能是另外几道闸门。Calif 称已经完成 Android 与 iOS 的 RCE 验证，公开材料没有披露具体读写原语、覆盖对象和权限边界。

蠕虫化还要继续调用业务链。控制一台客户端后，程序可以遍历联系人，调用微信内部的发起通话接口；信令服务器把邀请转给下一个好友，下一个客户端在响铃阶段再次解析并触发。

拿到的是微信会话，不等于拿到整台手机

Calif 公开演示中确认的能力是：读取和发送微信消息、发起通话，以受害者身份进行操作。这些能力都发生在微信应用内部。

权限边界需要分三层看。

第一层，会话被控不等于账号密码被盗。攻击者利用的是当前进程内的登录态和授权上下文，不需要知道用户的微信密码。改密码、换设备登录这些动作，可能会中断当前会话，但无法追溯攻击者用了什么密码。

第二层，账号被控不等于整台设备已经失守。Calif 的演示停留在微信应用内部的操作，没有展示获取系统权限、读取其他应用数据、安装恶意软件等行为。要从应用级控制升级到设备级控制，还需要额外的系统漏洞链，公开材料中没有这部分。

第三层，支付密码、生物识别和系统沙箱仍可能是额外闸门。即使微信会话被控制，涉及支付、转账、修改安全设置等敏感操作，微信本身可能还会要求二次验证。这些验证是否能被绕过，取决于具体实现，公开信息没有给出答案。

把这三层分清楚，才能准确评估风险。WeWorm 首先是会话级和社交图级的风险，只有补上凭据访问、持久化或提权链后，才会上升为设备级失陷。

跨平台蠕虫不是一份 payload 打遍两端

WeWorm 区别于普通 RCE 漏洞的地方，是它可以自我传播。

传播链是这样的：已控客户端遍历联系人，调用微信内部发起通话接口，信令服务器把邀请转发给目标好友，目标客户端在响铃阶段解析并触发。攻击者的好友关系是前提，拿到一台客户端后，蠕虫能遍历的也是这台客户端已有的联系人。

跨 iOS 和 Android 传播，不代表一份二进制 payload 在两端直接通吃。结合时间线看更稳妥：7 月 30 日完成 Android RCE 验证，8 月 2 日完成 iOS RCE 验证，8 月 11 日才完成跨平台蠕虫演示。这个节奏更像是触发面接近、利用实现分成了两套平台分支，而不是同一份利用代码直接适配两端。

Android 和 iOS 的内存利用环境差异很大。Android 的 Scudo 堆分配器、iOS 的 PAC 指针签名、各自的对象生命周期和堆布局，都要求利用代码做针对性适配。Calif 用了大约一周时间从首个 RCE 走到跨平台蠕虫演示，这个周期本身也说明跨平台适配不是零成本。

传播成功率也不是 100%。好友是否在线、客户端版本是否在受影响范围内、服务端是否已经下发缓解策略，都会改变一次呼叫的结果。蠕虫的可怕之处不在于单次攻击的成功率，而在于它可以自动重拨、批量遍历，用数量弥补单次成功率的不足。

时间线里能看出风险窗口

整个事件从发现到公开，走了大约两个月。

7 月 Calif 团队发现漏洞。7 月 24 日向腾讯提交漏洞报告。7 月 30 日完成 Android 端远程代码执行验证。8 月 2 日完成 iOS 端验证。8 月 11 日完成跨 Android 与 iOS 的蠕虫演示。8 月 21 日腾讯发布 Android 8.0.77 和 iOS 8.0.76 版本修复。8 月 28 日研究团队确认服务端已对所有用户完成缓解。9 月 4 日腾讯确认该漏洞具备远程命令执行影响。9 月 8 日 Calif 公开发布研究文章。

Calif 自述借助人工智能发现漏洞，约两天完成首个远程代码执行验证，约一周完成跨平台蠕虫演示。这里要注意，这是 Calif 自己的说法，没有第三方独立核验，也没有提供无 AI 对照组。不能据此推导”AI 已把这类攻击的平均开发周期缩短到两天”，能确认的是 Calif 在这个项目中使用了 AI 辅助，且他们报告的周期很短。

从时间线能看出一个风险窗口：从 8 月 11 日蠕虫演示完成，到 8 月 21 日腾讯发布修复版本，中间有十天。再到 8 月 28 日服务端全量缓解，又过了一周。这段时间内，如果漏洞细节泄露或被其他团队复现，用户是没有防护的。好在 Calif 走的是合规披露流程，没有在修复前公开利用细节。

目前公开利用方式已经失效。腾讯通过客户端补丁和服务端缓解两道措施，挡住了 Calif 演示的利用链。普通用户应通过官方渠道将微信更新到最新版本，避免使用来源不明的客户端或修改版应用。

这起事件最值得带走的判断，不是”微信有个漏洞”，而是我们对手机安全的直觉已经跟不上程序的运行方式了。

过去我们习惯把安全边界划在用户操作上：不点陌生链接、不接可疑电话、不装来路不明的应用，似乎就能挡住大部分风险。但 WeWorm 演示的是另一种攻击：用户什么都没做，程序在后台已经替用户完成了收包、解析、初始化，漏洞就在这些看不见的步骤里被触发。接听是人的交互点，不一定是程序的处理点。

微信不是孤例。任何一个在后台预加载数据、预解析协议、预初始化会话的应用，都可能存在类似的攻击面。随着应用功能越堆越多，响铃、推送、预览、同步这些”用户还没操作，程序已经在跑”的场景只会越来越多。

熟人关系也不再是天然的安全边界。蠕虫利用的正是社交软件赋予联系人的信任权限，一个账号被拿下，整条好友链都变成攻击通道。

这起漏洞已经被修复，但它暴露的问题不会因为一次补丁消失。超级应用时代，安全防线需要从”用户不要做什么”前移到”程序在用户操作之前做了什么”。这个前移，才是 WeWorm 真正留下的功课。

免责声明：

本文所载程序、技术方法仅面向合法合规的安全研究与教学场景，旨在提升网络安全防护能力，具有明确的技术研究属性。

任何单位或个人未经授权，将本文内容用于攻击、破坏等非法用途的，由此引发的全部法律责任、民事赔偿及连带责任，均由行为人独立承担，本站不承担任何连带责任。

本站内容均为技术交流与知识分享目的发布，若存在版权侵权或其他异议，请通过邮件联系处理，具体联系方式可点击页面上方的联系我。

本文转载自：MessFreeSecurity messfree messfree《微信电话还没接，攻击就发生了》