Signal’s end-call button could fail to fully end a call because of a critical RingRTC flaw fixed in a code change. A malicious participant could keep audio, and possibly video, running after the other person hung up.
The Brief
- CVE-2026-113380 carries a critical CVSS v4.0 score of 9.3 and affects RingRTC releases before version 2.72.0.
- A remote participant who floods a call’s event queue could stop the other side’s hangup from finishing the shutdown.
- RingRTC 2.72.0 adds a separate termination flag and five-second shutdown limits, so cleanup keeps going when steps fail.
- Signal app versions affected by the flaw remain unconfirmed, so users should install the latest update on each device.
RingRTC is the open-source library behind Signal’s voice and video calls. It supplies the calling components for Signal’s mobile and desktop apps. The bug, tracked as CVE-2026-113380, sits in how those components end a call.
Signal developer jim-signal authored the fix and described it as a change that ensures complete call termination in exceptional circumstances. The RingRTC 2.72.0 changelog lists the same improvement. As first reported by CyberInsider, Signal had not answered questions about which client versions, if any, are affected.
A full event queue could stall the hangup
Signal calls run on finite-state machines (FSMs), the components that manage each call and its underlying connection. Those machines process events through bounded queues that hold 256 entries each.
A remote peer that saturates a call’s FSM queue can interfere with a local hangup, according to the vulnerability description. In practice, pressing end call could fail to dismantle the call and its media tracks.
The patch shows why. The old termination sequence returned early whenever an operation failed, so later cleanup steps never ran. A full queue could block the termination event from being submitted at all. Other errors, such as a failed notice to the app that the call had ended, could also cut teardown short.
The disclosure establishes that audio could stay active past the intended end of a call. It flags possible video involvement but does not describe that behavior. Several basics are still unanswered:
- Which Signal app versions shipped a vulnerable RingRTC build?
- How long could audio stay live after a failed hangup?
- What would an affected screen show the person who hung up?
- Has anyone triggered the flaw outside testing?
Signal’s patch forces the call to close
RingRTC 2.72.0 adds a separate termination flag. The call and connection state machines check that flag on their own, independent of any queued termination event. The update also caps waits for FSM shutdown at five seconds and lets cleanup proceed when those waits, or other termination steps, fail.
New regression tests simulate saturated call and connection queues plus failed app notifications. They confirm that hangup closes the simulated peer connection and turns off outgoing audio. The tests also check that hangup clears the RTP (Real-time Transport Protocol) packet sink.
Why It Matters?
The bug lands months after an FBI warning about a Russian campaign targeting Signal accounts. That campaign tricked users into handing over verification codes and recovery keys. This flaw starts somewhere else. The attacker is the other party on the call, and the weak point is Signal’s own teardown code.
Signal users should install the latest available app update on every phone and computer they use. Developers who embed RingRTC should move to version 2.72.0 or later.
The fix closes a gap between what a user does and what the software does. Callers rarely second-guess the end-call button, yet the flaw made it depend on a queue another participant could fill. The next marker is Signal naming the app versions that shipped the vulnerable library. Until then, keeping every device on the latest build is the practical way to help reduce the risk.
