微信移动端接管账号漏洞，一场无公开exp和时间的赛跑，在护网期间，究竟能翻出多大的浪花

原创 67626d 2026-09-10 14:28 北京

微信零点击漏洞，一场无公开exp和时间的赛跑，在护网期间，究竟能翻出多大的浪花。

微信零点击漏洞与利用工具溯源，一次风险极高但已被拦下的移动 IM 零点击攻击，以及一次对"网上到底有没有 EXP"这个问题的逐源核查。

目录

一、先划边界：哪些是证实，哪些是脑补

二、为什么"响铃"就意味着一切都结束了

三、好友列表不是门槛，是攻击拓扑

四、从内存破坏到蠕虫：攻击链还原

五、全网核查：为什么你找不到WeWorm 的 EXP

六、替代样本：唯一真实可复现的同类攻击面PoC

七、横向对比：零点击攻击的四次迭代

八、AI 叙事的虚与实

九、防护与检测：现在还能做什么

十、结论

附录A：本次核查的证据链

附录B：核心参考来源

附录C：元信息

阅读提示：本文的价值不在于报道新闻——市面上已有几十篇转述稿——而在于做三件别人没做的事：划清官方证实与技术臆测的边界；给出「找不到 EXP」的完整可复现核查证据链；提供唯一真实存在且可复现的同类替代样本。文中每一处推断均已显式标注。

一、先划边界：哪些是证实，哪些是脑补

安全圈这次的传播质量参差不齐。中文媒体转载时普遍把大量工程细节当成了官方结论在写，先把这条线划清楚。

（一）官方（Calif Research）确认的事实

以下来自 Calif Research 官网原文，逐条可核：

（二）中文转载中常见的技术臆测

下面这些内容没有出现在 Calif 的公开材料里，属于转述过程中的加工，请勿当作事实引用：

·× "Shellcode 注入后被截获 Session Token、本地聊天数据库解密密钥、通信 API 钩子"——根因与载荷行为均未公开，这是想象。

·× "内存越界破坏导致的注入点位置"——官方只定性为 memory corruption，具体子类（堆溢出／UAF／类型混淆／整数溢出）一概未提。

·× "构造特定畸形信令包经由腾讯中继节点推送"——信令传输路径的具体措辞是转述者对 VoIP 架构的一般性描述，不是官方对本漏洞的说明。

·△ "十亿台设备受影响"——这是基于微信 14.39 亿月活（腾讯 2026-06-30 口径）的推算，不是实测感染规模。Calif 自己的措辞是"if exploited, could compromise over a billion phones (or accounts)"——注意是条件句。

把推断当事实传播，是安全圈最大的污染来源。这篇稿子的其余部分会严格标注每一处推断。

（三）一个容易被忽略的时间线瑕疵

注意 8-21（补丁已发布）与 8-26（腾讯才开始"评估"）的顺序错位，以及 RCE 属性直到 9-04 才被确认。加上报告后账号被封 4 天这段插曲，围绕漏洞奖励与披露体验的争议大概率还会继续发酵。这些不构成本次漏洞的技术结论，但对理解整件事很重要。

二、为什么"响铃"就意味着一切都结束了

这是整件事里最反直觉的一点，也是工程上最值得吃透的一点。

（一）触发窗口：用户交互之前

一通 VoIP 电话从呼叫方发起，到受害者按下接听键，中间客户端已经完成了一整套工作：

1.接收呼叫信令（被叫方需要知道"有人打给你"）

2.完成媒体协商（双方要用什么编解码、什么码率、什么端口）

3.初始化解码器与音频通路

4.拉取来电者头像、昵称等信息用于振铃 UI

5.触发系统级响铃

第 2 步在振铃 UI 出现之前就已经做完了。这意味着攻击者构造的不可信数据，在受害者看到屏幕上任何东西之前，就已经被完整解析并写进了微信进程的内存里。

内存破坏若发生在这一段，利用窗口就与用户操作彻底脱钩。这就是"零点击"成立的全部前提——不是什么魔法，是协议栈的必然时序。

（二）三个致命的组合条件

VoIP 媒体处理模块天然具备三样东西，它们叠加在一起就是零点击的温床：

这也是为什么微信历史上反复在媒体处理组件上出洞——"自研协议栈 + 不可信输入 + 内存密集"是这条产品线上明确存在的漏洞富集区。

（三）跨平台传播说明了什么

WeWorm 第一跳 Android → iOS，第二跳 iOS → Android，同一块攻击面在两个平台上被同样打通。这一点在工程上给出的信息量很大：

缺陷几乎肯定位于微信自研的、两端复用的 VoIP 协议／编解码核心里（历史上公开研究可见随包分发的libvoipCodec系列动态库），而不是某个平台的系统层 API。这种跨端复用 C/C++ 核心的做法在工程上很常见——一套代码两个平台——代价是一处缺陷，两端同时失守。

三、好友列表不是门槛，是攻击拓扑

"攻击者必须在受害者好友列表里"听起来像一道防线。它不是。

（一）信任跳板：单点突破即可到达任意节点

这条链只要成立一处就够了：A 是 B 的好友。而 A 可以通过任意其他方式先被拿下——其他 App 的漏洞、恶意 App，或者 Calif 自己 8 月 31 日公开的 OEMpocalypse（一条从 Android untrusted_app 到 root 的通用策略）。

换句话说，传播图就是微信好友关系图。社交网络越大的人，传播半径越大；好友关系既是传染途径，也是易感人群索引。

（二）传统防守在这里为什么失效

更麻烦的是宿主流量本身就是合法的。服务端想在信令层拦截，必须先能识别出"畸形信令"，这是腾讯 8-28 那条服务端缓解的技术难点所在（具体机制腾讯未公开）。

四、从内存破坏到蠕虫：攻击链还原

基于公开材料，还原出完整链条如下（第 3 步之后的细节官方未公开，属合理推断）：

权限边界要讲清楚：WeWorm 拿到的是微信进程内的执行权 + 账号控制权，不是 root / kernel 权限。Calif 明确表示这一步无法突破 Android / iOS 系统沙箱。想实现整机控制，得再补一环。

五、全网核查：为什么你找不到 WeWorm 的 EXP

这一节是本文的核心工作量。不是在搜索引擎里随便搜一遍说"没找到"，而是把每一个可能出现 EXP 的地方都实际敲过点。

（一）核查方法与结果

（二）结论：不存在公开 PoC

五条独立证据指向同一个答案：截至 2026-09-10，WeWorm 不存在公开可用的利用代码。

这不是偶然。推理很简单：一个理论影响面达十亿级的武器，披露方自己都在厂商修复完成后才敢公开演示，并且特意压着技术细节等会议发表——它不可能在修复之前就已经在外流通。Calif 团队甚至故意等到 8-28 服务端缓解确认之后才公开披露，这是负责任披露的标准动作。

（三）红线：如何识别假资源

任何声称携带"WeWorm 利用工具""微信零点击蠕虫 PoC""一键接管源码"的：

·网盘链接／Telegram 频道／私聊渠道出售的

·GitHub 上突然冒出的无名仓库

·附带 .exe／.apk、需要关闭杀软运行的

一律先当作钓鱼或带毒样本处置，不要运行、不要解压执行。判别标准很简单：真东西的发布者会同时给出根因分析、受影响版本矩阵和 CVE 编号；假货只会给一个压缩包和一句"亲测可用"。

六、替代样本：唯一真实可复现的同类攻击面 PoC

没有 WeWorm，不代表这块攻击面无从着手。ExploitDB 上现存两条微信 VoIP／媒体栈相关的公开记录，其中一条是完整、真实、可复现的——而且恰好落在同样的信任边界上。

（一）两条记录对比

（二）EDB-47920 成因拆解

这条的价值远超它的 DoS 评级——它是理解 WeWorm 那一层最好的入口。官方描述的成因：

通话过程中处理 RTP 包时会调用 UnpacketRTP。该函数无条件将包长度减 12，却没有检查包是否至少有 12 字节，导致包长度变为负数。随后CAudioJBM::InputAudioFrameToJBM在 memcpy 前只检查"包尺寸小于缓冲区大小"（n < 300），没有考虑到长度可能是负数，于是产生了越界拷贝。

这是一个教科书级的整数处理缺陷，攻击链条清晰：

三个要素和 WeWorm 高度同构：微信通话的媒体报文处理、用户交互前已完成不可信数据解析、缺陷位于自研 libvoipCodec 系列动态库。差别在于它是 DoS 而非 RCE，且需要通话已建立（不是严格零点击）。

（三）复现步骤

仅在自己拥有、且使用测试微信账号的隔离设备上操作。以他人为目标实施即违法。

PoC 包内容：

验证建议：先确认设备 Frida 连通（frida-ps -U能看到com.tencent.mm），再确认 hook 注入后 READY 正常打印，最后才拨号。崩溃与否用 logaudio.txt 里的堆栈做比对，不要凭"卡了一下"下结论。

（四）它能给你什么

·一个真实的工作流：Frida hook 微信进程 → 替换媒体报文 → 观察崩溃，这套方法是通用的

·微信 VoIP 栈内部的函数命名与调用关系

·如何判断一次内存破坏是崩溃还是可利用——这是从 DoS 走向 RCE 的分水岭

七、横向对比：零点击攻击的四次迭代

把 WeWorm 放进历史坐标里看，它的"新"在于自传播，而非零点击本身。

真正的分水岭是最后一行：前三个都需要攻击者自己持续投递（一个个打），WeWorm 不需要——被感染者自动成为投送者。传统蠕虫模型（Conficker、WannaCry）和最新的零点击能力在这里合流了。

八、AI 叙事的虚与实

Calif 公开宣称 AI 参与带来的效率跃迁：约 2 天写出第一个 RCE 利用，1 周完成蠕虫 demo，过去这需要大团队干几个月。

实的部分：即便把这个速度打个折，也足以说明 AI 把"发现 → 利用 → 武器化"的周期压缩了至少一个数量级。

虚的部分：这个叙事目前无法独立验证。德国安全媒体 Blogspan 的质疑很克制但很到位——用的什么模型没说，流水线不清楚，人工介入占比查不了，"两天出利用"目前只能是披露方的一面之词。

该信的部分：上面那些虚的不重要。即便 AI 只承担了其中 30% 的工作，结论也不变——攻击侧的武器化成本在断崖式下降。防御侧如果还按季度做 SRC 响应、按月发补丁，节奏是对不上的。

Calif 自己的警告值得抄下来："这些能力早就存在于资金充足的高级攻击者手中，AI 改变的只是发现和修复它们的速度。"以及："半成品工具一旦泄露，就是下一个 WannaCry。"

九、防护与检测：现在还能做什么

漏洞已修，但这扇门没关。给两份可直接落地的清单。

（一）个人用户：一条硬标准

升级微信至Android ≥ 8.0.77 / iOS ≥ 8.0.76或更新，并开启自动更新。服务端 8-28 的缓解已经兜底了未升级的终端，但客户端本地的解析缺陷仍在——升级是消掉它，不是补救这次。

其他几条：定期清理不认识、长期无互动的可疑好友；关闭"允许通过手机号／群聊直接添加好友"等过宽入口。

一个具体的识别信号：如果频繁接到好友发起的、短促即挂断的音视频呼叫，随后该好友账号发来索要资金或未知链接——这不是巧合，大概率是该账号已被接管。务必通过电话或短信等外部渠道二次核验。

（二）企业安全团队

最后一个容易被漏掉的点：把"社交关系链横向移动"纳入威胁模型。传统网关隔离对这类蠕虫无效，本质是信任边界的问题，得用信任层的手段去解。

十、结论

三句话：

1.漏洞本身已经结束。客户端补丁 + 服务端双轨都已生效，无在野利用证据。这次是好人先找到的。

2.EXP 的答案是确定的"没有"。CVE 未分配、官方 withholding、GitHub / ExploitDB 全空——五条独立证据。市面上出现的所谓工具，按恶意样本处置。

3.这门还开着。下一个躺在哪个 VoIP 栈里的洞，可能已经有人在看。Calif 明确表示这是系列研究的第一篇，他们正在其他 IM 上做同类攻击面研究。

最后一个判断：这件事的压力不该只算在微信头上。"用户交互前就完成不可信数据解析"是行业级问题，部分环节还需要操作系统平台方配合收敛。所有带实时音视频能力的通讯软件，都在这份名单上。

附录 A：本次核查的证据链

便于读者自行复验，完整列出核查过程：

附录 B：核心参考来源

附录 C：元信息

·目标读者：中高级安全研究者、移动安全／漏洞挖掘从业者、企业安全运营团队

·前置知识：内存破坏基础（堆溢出／UAF／整数溢出）、VoIP 信令与媒体协商基本概念、Frida hook 基础

·核查日期：2026-09-10（所有"是否存在 EXP"的结论均以此日期为准）

·证据分级：本文严格区分「官方确认」「公开报道」「工程推断」三类，凡推断均在正文显式标注

免责声明：本文基于公开资料整理，仅供安全研究参考。文中提及的所有复现操作均应在自己拥有并明确授权的隔离设备上进行。漏洞的最终技术细节以 Calif 后续会议披露与腾讯官方公告为准。

跳转微信打开