一个 4.3 分的中危 CVE，被研究者挖出了\"点一下链接就泄漏\"的实在路径：WhatsApp AI 富响应逆向纪实

Ots安全

2026年10月16日 17:22
广东

去阅读

威胁简报

恶意软件

漏洞攻击

2026 年 5 月 1 日，Meta 公布了 CVE-2026-23866：WhatsApp 的 AI 富响应消息（AI rich response messages）对 Instagram Reels 的校验不完整，\"可能允许用户触发在另一用户设备上处理来自任意 URL 的媒体内容，包括触发操作系统控制的自定义 URL scheme 处理器\"。官方口径是\"未见在野利用\"，CVSS 4.3 Medium——一个扔进漏洞海洋里看不见水花的中危评分。

但研究者 Numb3rs 决定只看 NVD 上的公开信息，把这个漏洞从头挖一遍。他的结论比官方描述更具体：WhatsApp 确实会从用户可控的消息里提取 URL，加载前不校验它指向哪里；点击一次 Reels 卡片，Safari 就会打开攻击者指定的地址——你的 IP、请求头、User-Agent 一并送出去。 而他没能做到的，是复现 CVE 描述里那条更致命的\"全自动\"路径。

这篇逆向纪实的价值在于过程完整：从 grep 到 openURL，每一步都能跟着走。

一、起点：只有一份 NVD 页面

Numb3rs 拿到的全部\"内部信息\"就是 NVD 页面。受影响版本写得很清楚：iOS 2.25.8.0 至 2.26.15.72，Android 2.25.8.0 至 2.26.7.10。他更熟 iOS，于是选了 WhatsApp iOS 25.9.72 做静态逆向，工具是 IDA Pro。

开局手段朴素得可爱：解开 iPA，grep \"AiRich\" -ri。三个二进制命中——SharedModules、WABloksKit 和主 WhatsApp 二进制。顺着 SharedModules 往下挖，这里看起来就是解析各类协议消息的地方。

真正引起注意的是类 WAPBAIRichResponseMessage_AIRichResponseContentItemsMetadata_AIRichResponseContentItemMetadata——名字长得多半没好事，AI 富响应里带一堆字段，正对\"处理媒体内容\"的猜想。对照 whatsmeow 项目里的 protobuf 定义，结构完全摊开：

message AIRichResponseReelItem {    optionalstring title = 1;    optional string profileIconURL = 2;   // 头像    optional string thumbnailURL = 3;     // 缩略图    optional string videoURL = 4;         // 视频}

四个字段，全部来自消息发送方。Reels 卡片要渲染，就得加载视频——如果客户端不校验这个 URL 指向Instagram 自己的服务器，攻击者把它换成自己的机器就行。

二、追踪：从提取字段到交给系统

逆向主二进制的交叉引用链，最终收敛到三个函数：

• sub\_101AF22F0

：从消息中取出 videoURL、title、profileIconURL、thumbnailURL；
* sub\_1013B30C0

：把 videoUrl 存进 RichResponseReelItem 实例；
* sub\_1013E678C

：消费这个 URL——URL.init(string:) 构造后交给 UIApplication.openURL。

整条链上没有任何一步校验 URL 是否来自可信域。作者的吐槽很实在：\"谢谢 Meta 用 -O1 编译，这体验可太愉快了\"——内联编译把函数边界抹平，IDA 连桩函数的参数都加载不出来，每个参数在哪都得手工翻。

最后找到的调用端是一个 Objective-C 方法：-[ReelCollectionViewCell handleTap]。用户点击 Reels 卡片，链路启动，Safari 打开攻击者控制的地址。

三、实测：whatsmeow 把消息发出去

光看二进制不算数。作者用 WhatsApp 第三方客户端库 whatsmeow 构造了一条 BotForwardedMessage：外层是 forward 上下文（ForwardOrigin、BotJID），内层塞 AIRichResponseMessage，ContentItemsMetadata 里放 ReelItem，四个 URL 字段全部指向自己的 VPS。

在新版 WhatsApp 上的实测结果：点击 Reels 卡片，设备直接跳转 Safari 打开指定的 videoUrl。一次点击，一次 IP 与请求头泄漏。

作者随即给这条链定了性：它需要用户交互，是 1-click；而 CVE 描述里\"触发处理来自任意 URL 的媒体内容\"暗示的 0-click 路径，他还没找到。

四、两道墙，和一个新线索

0-click 那条 sink 为什么难找？作者撞了两堵墙。

一道是动态调试：WhatsApp 后端拒绝注册旧版本客户端，想直接跑漏洞版本调试此路不通。另一道是二进制 diff：-O1 内联编译让漏洞版和补丁版的函数边界对不上，传统 diff 基本失效。他给后续留了几个思路——在二进制里硬编码一个新版本号绕过后端检查（还得改手机日期绕过应用过期）、或者写个自定义 dylib 注进去强制加载富响应消息——但都停在\"想想\"阶段。

10 月 10 日，作者更新了文章，抛出一条新线索：AiRichResponseMessage 的 unifiedData 字段可以携带 LaTeX 渲染对象，结构含 latex_expression、url、height、width。他的推测是：漏洞版本直接加载这个 url，而补丁版本引入了 latex_image 对象（含 url/height/width）——结构变了，很可能就是修复本身。

新版客户端实测：公式正常渲染，但图片不显示。可能因为域名不在可信名单，可能因为发送者不是已验证 bot，也可能这种方式已被完全废弃。作者说要找台漏洞版本的机器再验，届时再更新文章。

五、结论与边界

作者的结论克制且准确：证实了 1-click 路径，没证实 0-click 路径。 但即使只有 1-click，也暴露了一个实质问题——WhatsApp 会从用户可控的 protobuf 消息里提取 URL 并加载，且不校验目的地是否可信。他提到此前有研究者因同类 WhatsApp 深链漏洞拿过赏金，这类问题本身就可能构成漏洞。

需要说清的边界：

• CVE 描述里的\"包括触发操作系统控制的自定义 URL scheme 处理器\"意味着任意 URL 不止能泄漏 IP——还可能唤起设备上的自定义 scheme（各应用的深链）。危害上限比\"泄漏一个 IP\"高，但作者未对此路径做验证。
• 作者的实测在新版 WhatsApp 上完成，点击跳转行为在补丁版本上依然存在；CVE 对应的自动媒体处理路径未复现。
• Meta 与 WhatsApp 官方公告口径：未见在野利用。同批公告还有 CVE-2026-23863（WhatsApp for Windows 附件伪造，文件名嵌 NUL 字节）。
• 对普通用户：升级到官方修复版本（iOS ≥ 2.26.15.72，Android ≥ 2.26.7.10）即可；对研究者：这条链的剩余部分是现成的练手靶子。

参考来源

1. Numb3rs 博客原文：CVE-2026-23866: Finding a Whatsapp NDay — https://numb3rs.re/posts/cve-2026-23866-finding-a-whatsapp-nday/
2. CVE 官方记录（CNA: Meta，2026-05-01）— https://www.cve.org/CVERecord?id=CVE-2026-23866
3. WhatsApp 安全公告 2026 — https://www.whatsapp.com/security/advisories/2026/
4. Meta 安全公告 — https://www.facebook.com/security/advisories/cve-2026-23866
5. whatsmeow protobuf 定义（WAAICommonDeprecated.proto）— https://github.com/tulir/whatsmeow

END

公众号内容都来自国外等平台- 搜索的内容通过结合编写 -

公众号 | AnQuan7 (Ots安全)