Hanging up on a call is one of the few security controls most people use without thinking about it. You press the red button, and the conversation ends. A newly disclosed flaw in Signal's calling code shows that this does not always happen. Under the right conditions, the other person on the call could stop your hang-up from going through, so your audio, and possibly your video, kept flowing after you thought the call was over.
The bug is tracked as CVE-2026-113380. It affects RingRTC, the open-source library that handles voice and video calls in Signal's apps, in every version before 2.72.0. The fix shipped last month, according to The Register. The public disclosure came this week.
What went wrong
According to the National Vulnerability Database record, which was published on October 20 and is still marked "Awaiting Analysis," the problem is in how RingRTC manages a call's state. The library uses a finite state machine (FSM), a common design in which a call is always in exactly one defined state, such as ringing, connected or ended. Events like "the other side answered" or "the user hung up" go into a queue, and the state machine works through them in order.
The record's description says that "a peer that saturates a call's FSM queue can interfere with the ability of a local hangup to tear the call (with its audio and perhaps also video track) down." Put simply, the other party can fill the queue with enough events that your hang-up request gets stuck behind them and is not handled. The call stays up on your end even though you have tried to end it.
Help Net Security reports that the researcher who documented the flaw, who publishes notes on GitHub as Imahian, says RingRTC trusted the remote peer with that queue, with "no rate limit on peer-originated events and no priority lane for hang-up." A hang-up waited in the same line as everything else, so a flood of other traffic could hold it back. Help Net Security notes that the researcher's proof of concept is labeled conceptual and that details on the attack are thin beyond it.
The Register notes that the flaw is classified as CWE-754, "Improper Check for Unusual or Exceptional Conditions." That category covers software that does not anticipate an abnormal situation, in this case a queue flooded on purpose, and does not handle it safely. The Register describes the underlying problem as, in essence, a denial-of-service attack on the call's event queue.
How bad is it?
The CVE carries a CVSS 4.0 base score of 9.3, rated Critical. That score was assigned by the CVE Numbering Authority ([email protected]), not by NVD's own analysts, who have not yet reviewed the record. The vector lists network attack (AV:N), low attack complexity (AC:L) and no privileges required (PR:N), and the score rates the impact on confidentiality and integrity of the vulnerable system as high. The Register also describes the attack complexity as low.
The score needs some context. The attacker has to be a party to the call. Help Net Security describes the scenario as an ordinary Signal call placed by the attacker, who then floods the call's event queue. This is not a bug that lets a stranger switch on your microphone remotely. Someone has to call you, or you have to call them, and the connection has to be established. The danger is what happens at the end of the call: you believe the conversation has stopped, and the other side may keep receiving, as Help Net Security puts it, audio and possibly video.
The Register points out that WebRTC already encrypts media traffic, and that this is not what fails here. Nothing in the sources suggests an attacker breaks Signal's cryptography or intercepts someone else's call. What fails is the hang-up: the call that should have been torn down stays up.
For most people, that is a privacy problem more than a mass-exploitation risk. For journalists, lawyers, executives, activists and anyone who uses Signal precisely because conversations with untrusted or semi-trusted contacts may be sensitive, a call that silently outlives its hang-up is a serious failure.
Is anyone exploiting it?
There is no sign of it so far. Help Net Security reports no known exploitation in the wild, and both outlets say the flaw is not in CISA's Known Exploited Vulnerabilities (KEV) catalog. The timeline helps defenders somewhat: according to The Register, RingRTC 2.72.0 was pushed out last month, before the bug was made public. The Register also says it is not clear when the fixed library reached the Android, iOS and desktop apps, though Signal Desktop's release history indicates RingRTC 2.72.0 was incorporated in September. Updating is therefore still worth checking rather than assuming.
Which apps are affected?
RingRTC is a shared component, not a separate app. The NVD record lists the affected package as the npm module @signalapp/ringrtc below version 2.72.0. Help Net Security relays the researcher's statement that the bug reaches every Signal client embedding an older RingRTC build, on Android, iOS and Desktop, until each client ships the fixed library. The sources do not list specific fixed app version numbers for each platform, so the practical rule is simple: the latest release of each Signal client is the one to be on.
Developers who have built their own projects on top of the @signalapp/ringrtc package should check their dependency trees as well. Nothing in the sources indicates widespread third-party use, but anything pinned below 2.72.0 inherits the bug.
What It Means for Defenders
Who is affected: Anyone running a Signal client built with RingRTC earlier than 2.72.0 on Android, iOS or Desktop, plus any software that depends on the npm package @signalapp/ringrtc below 2.72.0.
What to patch:
- Update Signal everywhere. Phones, tablets and linked desktop installs each update separately. A patched phone does not protect an outdated laptop that is still linked to the same account. Check every device, not just the one you use most.
- Look for stale desktop installs. Signal Desktop on shared workstations, spare laptops or rarely used machines is a likely place for an old version to linger. If you manage endpoints, inventory Signal Desktop versions the same way you would track a browser.
- Check development dependencies. If your organization builds anything on
@signalapp/ringrtc, upgrade it to 2.72.0 or later and rebuild.
Mitigations while you update: The sources do not describe a configuration workaround, so the fix is the update itself. Until every device is patched, users having sensitive calls with contacts they do not fully trust can take common-sense precautions: confirm on screen that the call has actually ended, and close the app or the device's call interface if anything looks off.
What not to worry about: None of the sources calls for credential rotation or key changes, and they report no exploitation in the wild. The reported failure is that a call does not end, not a break in Signal's encryption.
For compliance teams: If Signal is approved for use in your environment, including teams working toward CMMC, record the CVE and the fixed library version in your vulnerability tracking, and confirm that managed devices have updated. The CNA's Critical rating will likely show up in scanner output even though the real-world risk is narrower than the number suggests, since the attacker must be on the call. Note too that NVD's own analysis is still pending, so the score could change.
The broader lesson applies well beyond Signal: any control that is meant to stop something, such as a hang-up, a logout or a kill switch, needs to get through even when everything else is backed up. According to The Register's reading of the code changes, the fix lets the call's state machine detect termination requests independently of the event queue and adds a timeout so stalled processing cannot block a hang-up indefinitely. Version 2.72.0 is the fix.
