2026-10-24 14:06:47 网络安全文章来源：ZONE.CI 全球网 0 阅读模式

挂断后麦克风可能还亮着，Signal旧版先升级

原创

tcode
tcode

字节脉搏实验室

2026年10月23日 14:04
北京

去阅读

摘要：RingRTC 2.72.0以前存在通话终止异常，远端对端可把事件队列塞满，使本地挂断不能及时释放音频、可能还有视频。本文区分界面、状态机与媒体资源三层，并给出用户核验和开发版本检查清单。

Signal通话库RingRTC在2.72.0以前有一个终止路径缺陷：通话对端如果把有限状态机的事件队列塞满，本地用户按下挂断后，音频以及可能存在的视频媒体资源不一定能及时关闭。CVE记录给出的CVSS 4.0基础分是9.3，危险类型归为异常条件检查不当。这个结论描述的是漏洞能力，不代表已有电话被谁利用；CISA在10月20日的漏洞扩充记录中仍标为“未发现利用证据”，自动化利用条件为“否”。

最容易误解的是手机屏幕上发生了什么。用户点了红色的挂断按钮，界面可能先切回聊天页；状态机可能只收到一条排在队尾的终止事件；麦克风、摄像头和WebRTC连接又是另一层资源。三者没有同时结束，就会出现“看起来挂了，采集仍在运行”的窗口。本篇把它分成界面显示、终止请求、媒体释放三格，而不是把任何一次卡顿都叫作漏洞利用。

修复提交的时间早于CVE公开。Signal开发者在2026年9月4日提交“确保通话在边界情况下完全终止”的补丁，12个文件增加691行、删除115行。公开差异中保留了每个状态机256个事件的有界队列，同时增加终止请求标记、重复终止检查、幂等关闭和五秒终止超时。它修的是终止协调，并不能解释成“队列无上限导致内存耗尽”。原始研究者说明把问题概括成挂断事件被垃圾消息埋住，这个模型能帮助理解症状，却不等于Signal补丁的全部实现。

三条状态不能混为一谈

第一条是界面状态。挂断按钮被点击，应用切换页面或显示“通话已结束”，说明用户意图已经被界面接收。它不直接证明远端已经从通话状态中移除，也不直接证明采集设备已经关闭。

第二条是通话状态机。RingRTC用它管理来电、接通、音频连接和终止等事件。CVE描述的条件是队列被对端产生的大量事件占满，本地终止事件无法及时得到处理。队列大小为256，说明生产环境存在容量边界；本次缺陷是满队列时终止没有可靠走完，不能写成内存无限增长。

第三条是媒体资源。音频轨关闭、麦克风停止采集、摄像头指示器熄灭、RTP接收端注销、PeerConnection关闭，可能由不同代码路径完成。补丁测试特别检查了连接关闭、出站音频停止和RTP接收端清除，原因是只发出一个“关闭”请求不等于资源真的释放。普通读者无需理解这些对象，但可以据此理解为什么“屏幕已经退出”不能作为唯一判断。

这也能解释一个反例。手机在挂断后短暂卡顿，系统延迟更新状态栏，或耳机与蓝牙设备尚未完成断开，都会让用户感觉通话还在；这些现象本身不能证明远端触发了CVE。相反，如果界面已结束而系统麦克风指示持续存在，应用内又残留活动通话状态，才值得按媒体没有释放的方向检查。

普通用户先做三件事

先更新Signal客户端。受影响对象是嵌入2.72.0以前RingRTC的客户端构建，用户通常无法在手机关于页面看到一个叫RingRTC的库版本。实际动作是从官方应用商店安装当前Signal版本，再重新启动应用；不要从搜索广告、聊天转发链接或第三方下载站寻找安装包。补丁提交与CVE记录能证明上游已修复，具体商店何时完成分发仍以客户端更新状态为准。

接着养成挂断后的观察动作。挂断敏感通话后，查看系统是否仍显示麦克风或相机使用标记，Signal是否仍把该会话标为通话中，以及通话时长是否继续增加。这个检查不需要安装额外工具，也不会把正常系统动画误判为攻击，但能确认用户可见状态和采集状态是否一致。

观察应放在挂断后的短暂窗口内。若标记出现后又很快消失，记录持续时间即可；若一直不消失，才进入下一步排查。

若标记持续不消失，先停止采集：在系统权限里临时撤销Signal的麦克风和相机权限，再强制结束并重启应用；桌面端可退出进程后重启。随后再次检查权限是否仍被占用。若撤销权限后系统仍显示其他程序使用麦克风，应改查该程序，而不能继续把问题归给Signal。保存应用版本、系统版本、发生时间和通话对象类型，更新后再复测；不要公开发布陌生来电号码或私人通话信息。

第四件事是针对高风险场景设边界。更新后再进行一次普通测试通话，确认挂断后采集标记按时退出。若更新前已经讨论过验证码、财务指令或工作秘密，单凭本次升级不能判断是否被录音，也不能反推对端就是攻击者。需要核实时应看通话记录、设备权限日志和操作系统隐私指示，而不是靠“当时感觉挂断了”作结论。

开发者怎样确认修到哪一层

维护自有通话功能或打包Signal组件的团队，先做版本清单。只知道应用主版本号不够，应查明依赖树中的RingRTC是否达到2.72.0，并把移动端、桌面端和测试构建分别列出。若二进制来自供应商，要求其提供可追溯的组件清单或构建元数据；无法确认版本时，不能因商店页面写着“最新”就假定内部库已经升级。

再核对终止设计。公开补丁新增终止请求标记并多次检查，在等待状态机静默五秒后仍继续拆除，这比单纯给挂断事件更高优先级更完整。代码审查应关注终止是否幂等、队列满时是否仍能释放媒体、超时后是否真正关闭连接，以及重复终止会不会造成崩溃或资源泄漏。研究者文档里的简化优先队列适合解释，不应被当作现成补丁。

最后做资源级测试。构造事件队列接近上限、正常结束、远端结束和重复挂断等状态，断言麦克风采集停止、视频轨关闭、RTP接收端注销、PeerConnection关闭。只看界面回调和单元测试通过不够，因为CVE的后果落在媒体资源；只有资源状态也满足，才能说明终止异常已被覆盖。

这份漏洞说明没有证明什么

CVE把攻击向量写成网络、无需权限、受害者被动参与，影响涉及机密性和完整性，同时CISA扩充记录把总体技术影响标为全损。这些是评分与威胁建模字段，不等于现实中已经有成功攻击。公开记录中的“未发现利用证据”有更新时间，未来可能变化；同样，“自动化条件为否”也不等于漏洞永远不能被人工利用。

目前没有公开材料证明某个Signal用户因本漏洞被窃听，也没有给出实际利用样本、受影响用户数或中国境内案例。报告描述的是对端能够塞满事件队列这一技术前提；普通卡顿、运营商通话质量、蓝牙断开和应用旧缓存都不是同义证据。把任何挂断延迟都说成“Signal被黑客控制”会越过现有证据。

还有一个现实限制：用户通常看不到RingRTC版本，商店审核和灰度更新也可能不同步。安全团队能控制的是更新渠道和终端验证，不能看到所有供应商的分发状态。对于合规敏感的通话环境，应在升级后做一次资源释放实测，并把测试版本、系统、结果和失败截图留在内部记录中。

一个便于转述的问题是：通话结束后，是屏幕先退出，还是麦克风采集也真的停了？如果只能回答前者，就继续检查系统采集标记和应用状态；若更新且采集按时停止，暂时没有理由把正常偶发卡顿写成漏洞利用。

来源

CVE Program（GitHub CVE List V5）：CVE-2026-113380，发布日期2026-10-20 04:25:10 UTC，更新2026-10-20 14:38:10 UTC，2026-10-23复核：https://raw.githubusercontent.com/CVEProject/cvelistV5/main/cves/2026/113xxx/CVE-2026-113380.json

OSV漏洞数据库：CVE-2026-113380，2026-10-23复核入口：https://api.osv.dev/v1/vulns/CVE-2026-113380

Signal RingRTC修复提交：Ensure calls terminate completely in corner cases，提交时间2026-09-04 13:15:36 -0700，12个文件、+691/-115，2026-10-23复核：https://github.com/signalapp/ringrtc/commit/4b1b6fa53c9f30c87c8ea78e44675d4a13e1e4d3