Signal: RingRTC flaw can keep calls open after hang-up

A vulnerability in RingRTC, the open source library Signal uses for voice and video calls, can prevent a call from actually ending when the user hangs up. The flaw is tracked as CVE-2026-113380, with a CVSS 4.0 score of 9.3 (critical), and affects every RingRTC version before 2.72.0. In practice, the person on the other end of the call can keep receiving audio, and possibly video, while the victim believes the call is over.

All four sources agree on one point: there are no reports of real-world exploitation. The CVE is not in CISA’s KEV catalog and, according to Help Net Security, the National Vulnerability Database still lists it as awaiting analysis. Signal’s end-to-end encryption is not affected: the problem lies in how the app handles call state and call termination.

What happened

MITRE published the CVE record on 20 October 2026. The fix, however, was already out: according to SecurityWeek, RingRTC 2.72.0 was released on 4 September, and The Register confirms the fixed library version arrived during September. The issue was documented on GitHub by a researcher who goes by Imahian, with a technical write-up and a proof of concept explicitly described as conceptual.

The Register notes that Signal’s release notes do not make it clear exactly when the fixed library reached the Android, iOS and desktop apps: the Signal Desktop history points to September, while dates for the other platforms are unclear.

Technical details

RingRTC is built on WebRTC and manages each call with a finite state machine (FSM) fed by an event queue. According to the researcher’s write-up, quoted by several outlets, a local hang-up was not an immediate stop command but just another event, placed at the back of the same queue. Three factors made the attack possible:

• the remote participant can also add events to that queue;
• there was no limit on events coming from the other side;
• the hang-up had no priority over other events.

The attacker places an ordinary Signal call and then floods the queue with junk events. When the victim presses the hang-up button, the request is stuck behind this traffic and the call, with its audio track and possibly its video track, is never torn down. The Register describes it as a denial of service against the event queue and reports the CWE-754 classification (improper check for unusual or exceptional conditions).

According to Help Net Security, the CVSS vector describes a network attack with low complexity and no privileges required, with high impact on confidentiality and integrity and no impact on availability. The practical precondition, however, is that the attacker is the other participant in the call.

The Python proof of concept, Security Affairs explains, is synthetic and does not use the network: it compares a queue in which the hang-up can be buried with one in which critical events take priority. It illustrates the logic and is not a working exploit.

According to The Register, comparing the versions shows that in 2.72.0 the FSM detects termination requests independently of the queue, and a timeout prevents stalled processing from holding up the hang-up indefinitely. In MITRE ATT&CK terms, the effect maps to T1123 (Audio Capture) and T1125 (Video Capture).

App versions

The vulnerability affects every Signal client that embeds a RingRTC version earlier than 2.72.0, on Android, iOS and desktop. Only Security Affairs, citing an advisory from CSIRT Toscana, gives the affected app versions: Signal for Android before 8.27.0, Signal for iOS before 8.30.0 and Signal Desktop before 8.29.0. The other sources do not confirm these figures: either way, install the latest available version.

Impact for European and Italian organisations

Signal is often used precisely for the most sensitive conversations: senior management, legal teams, security functions, contacts with partners and suppliers. A call that stays open without the knowledge of the person who hung up can expose confidential discussions or personal data captured after the apparent end of the conversation. If such an incident were confirmed, it would need to be assessed as a possible personal data breach under the GDPR.

For NIS2 entities, the case falls under vulnerability management for communication tools, including those installed on personal smartphones used for work (BYOD), which often escape the inventory. The same care applies in healthcare, where doctors and staff exchange information about patients.

What to do now

1. Update Signal on every device used for calls: smartphones, tablets and computers. The app version can be checked in the settings, under the help section.
2. Enforce a minimum version on managed devices with your MDM solution’s app compliance rules, and ask people using personal devices to update.
3. Check Signal Desktop versions on company computers using your software inventory.
4. Until you have updated, after every call check that the call indicator has disappeared, as SecurityWeek suggests, and that the operating system’s microphone and camera indicators have also turned off; if they stay on, close the app.
5. Be careful with calls from unknown contacts, especially for people handling sensitive information: the attack requires the attacker to be in the call.

The sources do not report any indicators of compromise. Since call traffic is encrypted, checking installed versions remains the most effective control.

How ARXDOME helps

On Windows, Linux and macOS computers with the ARXDOME agent, the ARX Sentry inventory lists installed software with its version, so you can find the Signal Desktop installations that need updating. ARX Shield shows the open vulnerabilities for each machine, which helps you track update progress. For smartphones, the company’s MDM solution is still required.

Last updated: 22 October 2026