A flaw in Signal’s RingRTC calling library can leave a user’s microphone and camera active after they hang up, according to a CVE published on October 21. The vulnerability, tracked as CVE-2026-113380, carries a CVSS score of 9.3, and a fix has been available since September.
How CVE-2026-113380 Keeps Calls Alive After Hangup
The flaw is a denial-of-service issue in RingRTC, the library behind calling in the Signal apps. An attacker can saturate the event queue of the call state machine. When the queue is flooded, hangup commands are not processed, so the microphone and camera stay live even though the user believes the call has ended.
The weakness is classified as CWE-754, improper checking for unusual or exceptional conditions. The CVE lists low attack complexity.
RingRTC Versions Before 2.72.0 Across Android, iOS and Desktop
All RingRTC versions before 2.72.0 are affected. The library is used across the Android, iOS and desktop Signal apps, so the exposure is not limited to a single platform.
The Fix in RingRTC 2.72.0
RingRTC 2.72.0 was released in September 2026. In the patched version, the state machine detects termination requests independently of the event queue, and a timeout was added. The change means a hangup no longer depends on the queue that an attacker could flood.
CVE-2026-113380 Published Through MITRE on October 21
The CVE was published through MITRE on October 21, roughly a month after the fix shipped. Details of the vulnerability became public with that entry.
Proof of Concept and Exploitation Status
A proof of concept written as a Python simulation is available on GitHub. No in-the-wild exploitation has been confirmed. Coverage of the CVE advises Signal users to update the app.
Why the State Machine Design Mattered
Before the fix, termination requests passed through the same event queue as every other call event. Once an attacker filled that queue, a user’s hangup sat unprocessed behind the flood. The 2.72.0 change decouples the two: the state machine now looks for termination requests on its own path, and the added timeout bounds how long a call can remain open if the queue is saturated. The CVE entry describes the weakness as a failure to check for unusual or exceptional conditions, which matches the flooded-queue scenario.
Affected Clients and Known Gaps
Because RingRTC sits underneath the Android, iOS and desktop apps, the vulnerable code path is shared across platforms. The reporting does not break out which app builds bundle which RingRTC release, and it does not say how many users were still running a pre-2.72.0 build when the CVE was published. It also does not say whether an attacker needs to be a participant in the call. The proof of concept on GitHub is a simulation written in Python, and the available coverage does not describe a working exploit against live Signal clients.
Timeline
The fix was released in RingRTC 2.72.0 in September. The CVE and technical details were published on October 21.
The gap between the two dates means the patched library was available before the vulnerability was described publicly. Clients that updated Signal after the September release already carry the fix; those that did not remain exposed to the behavior described in the CVE.
Impact
The potential result is covert audio and video capture on unpatched clients during or after calls. The attack does not need the call to continue in a visible state: because the hangup command is dropped, the interface may indicate the call ended while capture continues.
The CVSS score of 9.3 places the flaw in the critical range. The attack is a denial-of-service condition in the call state machine, and the CVE lists low attack complexity.
Signal users who run versions built on a RingRTC release older than 2.72.0 are the affected population. The report does not provide figures on how many installations fall into that group, and it does not describe any victim of the flaw.
