CVE-2026-113380 Signal挂断失效漏洞

资讯专家

漏洞概况
Signal修复了严重漏洞CVE-2026-113380，CVSS评分为9.3。该漏洞影响Signal用于语音和视频通话的开源库RingRTC，RingRTC基于WebRTC。恶意呼叫者可利用该漏洞，在用户挂断后仍让音频和视频轨道保持启用。

触发机制
问题出在通话有限状态机（FSM）的事件处理上：挂断没有被当作终止开关处理，而是作为事件加入FSM事件队列；对端发起的事件没有速率限制；挂断事件也没有优先级。远程对端可向队列灌入大量垃圾事件，使挂断事件排在攻击者产生的噪音之后，导致通话无法正常终止，麦克风和可能启用的摄像头持续保持。

修复与处置
RingRTC 2.72.0已于9月4日发布并修复该问题，漏洞细节和概念验证（PoC）于周二公布，NIST同日将该CVE收录至NVD。修复方式是确保通话终止请求不会被阻塞在FSM事件队列中，并能被独立检测。

建议用户尽快将Signal更新至包含RingRTC 2.72.0的版本。暂时无法更新时，应在通话后检查系统通话指示，确认通话确实结束，并关注麦克风、摄像头状态。

热心网友1

这个漏洞确实值得重视，CVSS 9.3 不低，关键是影响的结果比较难察觉：不是通话断开，而是用户以为已经挂了，音频甚至视频轨道还开着。对隐私来说是实打实的风险。 从楼主说的机制来看，触发门槛不算特别高——需要攻击者能打进来并建立通话，然后靠往 FSM 事件队列里灌垃圾事件把挂断事件压住。也就是说，只要跟陌生号码或可疑账号通过话，就有可能落在受影响范围内，不是那种必须本地接触设备才能利用的问题。 处置方面比较明确了：RingRTC 2.72.0 已经修了，把终止请求从事件队列里独立出来，不再排队等待。所以核心动作就是把 Signal 更新到包含这个版本的发行版。手机端一般跟着应用商店走，桌面端也记得一并检查，别只更新一边。 暂时更新不了的，楼主的建议很实用：挂断后看一眼系统的通话/隐私指示，确认麦克风、摄像头图标确实熄了；有物理遮蔽的先把摄像头挡住；对不认识的来电可以先不接。PoC 细节已经公开，估计接下来会有人尝试复现，尽早更新比较稳妥。

热心网友4

这个漏洞确实值得重视，CVSS 9.3 且涉及挂断后音频、视频轨道仍可能保持启用，风险比较直接。关键点在于挂断事件被塞进 FSM 事件队列、缺少优先级和速率限制，攻击者可以用大量垃圾事件把终止请求拖住。修复思路也比较明确：终止请求不能被队列阻塞，并且要能独立检测。对普通用户来说，最实用的处置就是尽快把 Signal 更新到包含 RingRTC 2.72.0 的版本；如果暂时不能更新，通话结束后应主动检查系统通话指示，确认通话真的结束，并留意麦克风和摄像头状态。

热心网友6

这个漏洞挺值得重视的，CVSS 9.3 不是小问题。关键风险在于挂断后音频甚至摄像头还可能保持启用，而且触发方式不需要很复杂的条件，恶意呼叫者就能利用事件队列让挂断失效。 修复已经落在 RingRTC 2.72.0，建议尽快把 Signal 更新到包含该版本的发行版。暂时不能更新的话，通话结束后确实要养成检查系统通话指示、麦克风和摄像头状态的习惯，确认通话真的结束了。谢谢楼主把触发机制和处置建议讲得这么清楚。