2026 年 10 月 20 日，MITRE 公开 CVE-2026-113380，CVSS 评分 9.3。Signal 自研通话库 RingRTC 在 2.72.0 之前的版本中，对端可以灌满通话状态机的事件队列，使本地「挂断」操作排到队尾而永远不被处理——用户以为通话已结束，麦克风（部分场景下还有摄像头）仍在向对方推流。
事件概述
RingRTC 是 Signal 基于 WebRTC 构建的通话库，承载 Android、iOS 与桌面端全部语音视频通话。2.72.0 版本已于 2026 年 9 月 4 日发布并修复该缺陷，但漏洞细节与技术分析直到 10 月 20 日才随 CVE 记录一同公开。研究者 Ahian 同期发布了说明与概念性 PoC。
技术细节
根因出在通话生命周期控制上。RingRTC 用有限状态机（FSM）管理每一通电话，外部事件进入一条队列按序处理。问题有三层：
- 挂断不是「终止开关」，只是又一个普通事件，被追加到队尾；
- 对端发来的事件没有任何速率限制；
- 终止请求不带优先级。
三者叠加后，攻击者只需发起一通正常通话，然后持续灌入垃圾事件，受害者的挂断请求就永远排在噪音之后。呼叫保持建立，音频轨继续发送，视频轨视通话类型也可能保持开启。而受害者一侧界面显示已挂断，听不到异常，也没有任何提示。
该缺陷归类为 CWE-754（对异常或例外情况检查不当），攻击复杂度评为低。GitHub 报告中的 poc.py 是纯离线队列模型：一边模拟洪泛淹没挂断、一边模拟挂断优先入队，不涉及真实通话，也不是可直接使用的利用代码。
影响评估
这不是加密被攻破，而是「会话终止保证」失效，某种意义上更麻烦：端到端加密让用户默认通话内容是私密的，而挂断后仍在收音直接摧毁了这个前提。CVSS 9.3，EPSS 30 天约 0.3%，未进 CISA KEV，无在野利用报告。
受影响范围是所有内置 2.72.0 之前 RingRTC 的 Signal 客户端。由于各平台打包节奏不同，官方发布说明未逐一标注修复版本进入 Android、iOS、桌面端的具体时间，最稳妥的判断方式是直接看应用商店的最新版本。
修复建议
- 手机与桌面端都更新到应用商店最新版本。移动端与桌面端是两套独立构建，只更新一端不够。
- 挂断后确认通话指示器确实消失。Android 可看状态栏的麦克风与摄像头绿点，iOS 可看状态栏的橙色或绿色指示。
- 高风险用户在不预期使用语音时，直接撤销 Signal 的麦克风权限（系统设置 → 隐私 → 麦克风）。
- 开发者侧：把本地控制事件做成不可排队的特权操作，对端事件强制限速，并为拆除流程加超时上限。
对比 RingRTC 2.71.0 与 2.72.0 的改动可见两处修复：状态机能够绕过事件流独立识别终止请求，同时为拆除等待加上 5 秒上限，避免卡住的处理无限期阻塞挂断。
更普遍的教训是：远端对端不应拥有会话终止的优先权。任何基于 WebRTC 的自研通信工具都应检查同一模式——控制事件是否与不可信输入共享同一条队列。