Vulnerabilities

Signal has fixed a flaw in RingRTC, the open-source library behind voice and video calls in its mobile and desktop apps, that could let the other person on a call keep hearing you after you hang up. The bug is tracked as CVE-2026-113380, scored 9.3 (critical) under CVSS v4.0, and affects RingRTC versions before 2.72.0. It was published on October 20.

The attacker has to be a participant in the call, someone you already answered or dialled. Call encryption is not affected, and no exploitation in the wild has been reported. Signal has not said which app versions were vulnerable or first carried the fix, so the safe course for anyone whose staff take sensitive calls on Signal is to make sure every device runs the current release.

How it works

RingRTC runs each call, and each connection inside it, as a finite-state machine (FSM): a component that moves between fixed states such as ringing, connected and ended, driven by events it reads from a queue. According to CyberInsider and SQ Magazine, those queues are bounded at 256 entries each. Ending a call means putting a termination event on the queue and letting the FSM work through a teardown sequence that closes the peer connection and stops the media tracks.

The flaw is in that teardown. A remote peer that floods the call's queue with events can fill it, so the termination event from your hangup cannot be submitted. The old teardown sequence also returned early whenever one step failed, so later cleanup steps never ran. A failure to notify the app that the call had ended could cut the sequence short in the same way.

The result, per the vulnerability description, is that pressing end call might not tear down the call and its audio track, and perhaps its video track too. Sources do not agree on video. The advisory text flags it only as a possibility, and none of the coverage describes how video behaves, what the person who hung up would see on screen, or how long transmission could continue.

The fix in RingRTC 2.72.0 changes three things. It adds a separate termination flag that the call and connection FSMs check on their own, so a full queue can no longer hide the hangup. It caps waits for FSM shutdown at five seconds. And it lets cleanup carry on when those waits or other termination steps fail. New regression tests simulate saturated queues and failed app notifications, then check that hangup closes the peer connection, turns off outgoing audio and clears the RTP packet sink (the component that hands audio packets to the network). The RingRTC changelog lists the change for 2.72.0 as "Ensure calls terminate completely in corner cases".

How much risk this is

The 9.3 score reflects what a successful attack gives: live audio from someone who believes the call is over. The conditions are narrower than the score suggests. The attacker must already be in the call with you, and the bug does not reach your messages, account or stored history. Malwarebytes notes that no passwords, accounts or message histories are exposed, so there is nothing to reset.

Nobody has reported the bug being used, no public proof of concept has been reported, and Signal had not answered reporters' questions about affected client versions by the time of publication. The sensible response is a routine, prompt update. Nothing published so far suggests that past calls were intercepted.

What to do

Update every Signal install. On managed devices, push the current Signal release from your mobile device management (MDM) console and set it to update automatically. On personal devices used for work calls, ask staff to update from Google Play, the App Store or the desktop updater, and include desktop installs: RingRTC is used there too.

Check the version you landed on. Signal has not published which builds contain RingRTC 2.72.0. As a data point, Malwarebytes saw Android update to Signal 8.32.2 through Google Play and an iPad showing 8.32 (build 1910), and believes both are patched, while saying this is hard to confirm. Use your MDM inventory to find devices still on older builds and chase those first.

Developers embedding RingRTC. Move to version 2.72.0 or later and rebuild. If you maintain a fork or wrapper around RingRTC's call handling, compare your teardown path against the upstream change: hangup should not depend on a termination event getting through a full queue, and a failed step should not stop the rest of cleanup.

Until a device is confirmed updated, watch the indicators. After ending a sensitive call, check that Signal shows the call as ended and that the microphone indicator has gone out. On an iPhone that is the orange dot in the status bar; on Android 12 and later it is the green dot at the top right. Swiping down from the top right on an iPhone, or tapping the dot on Android, shows which app is using the microphone. If it stays on, force-close Signal.

Checking for past abuse. No indicators of compromise have been published, and there is no documented way to check a device for a call that failed to tear down. If someone recalls a call where the microphone indicator stayed on after hangup, note the date and the other party and treat that conversation as possibly overheard.

What this says about call software

People speak more freely the moment they think a call has ended, so the hangup path carries real privacy weight. This bug came from a teardown routine that gave up at the first failed step. When we test mobile apps with voice or video features, ending the session under load, with a hostile peer and with failed steps, belongs in the test plan alongside authentication and encryption.

If you build calling features into an app, our mobile penetration testing includes hostile-peer cases like this one, and safeguarding and hardening helps keep company devices on current app builds. Open the chat and Yaali, our AI agent, will pass your question to the engineer who would do the work.

---

Sources: Malwarebytes, CyberInsider, SQ Magazine, SC Media, RingRTC changelog, 9to5Mac on iOS microphone indicators, Selectra on Android and iPhone indicators.