Signal Hangup Bug CVE-2026-113380: Update Windows Desktop and Mobile Apps

The flaw is tracked as CVE-2026-113380 and sits in RingRTC, the calling library shared by Signal's apps. A fix has been out for weeks, but the vulnerability only became public this week. If you use Signal Desktop on a Windows PC, or Signal on any phone, check your version today.

What the CVE says​

The official CVE description, published by MITRE on October 20, 2026, says that in the RingRTC library before 2.72.0 for Signal, 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.

In plain English:

• FSM means finite-state machine. It's the part of the code that tracks where a call is: connecting, ringing, connected, disconnecting.
• The attacker is the other person on the call, not a random stranger on the internet.
• The attack floods the call's event queue so your hangup request never gets processed.
• The result: your screen may say the call is over while audio, and possibly video, keeps flowing.

CVE records list the weakness as CWE-754 Improper Check for Unusual or Exceptional Conditions. The record also states plainly that any version before 2.72.0 of RingRTC is affected.

RingRTC's own GitHub repository describes the library as the open-source library behind Signal's voice and video calls, built on WebRTC. The bug is in shared calling code, so it isn't tied to one operating system. Windows, macOS, Linux, Android and iOS clients all depend on which RingRTC build they shipped with.

Section summary: a malicious caller could stop your hangup from actually ending the call. It's a call-teardown failure, not a crack in Signal's encryption.

How the hangup gets stuck​

A finite-state machine handles events one at a time from a queue. Think of a deli counter with a ticket system: if one customer grabs every ticket, nobody else gets served, including you trying to leave.

According to an analysis by FDayTalk, these FSMs handle incoming events through fixed-size queues that hold 256 entries each. When a remote peer fills those queues, the same analysis says your app cannot submit the termination event because the queue has no room left. It adds that the old shutdown routine stopped at the first failed step, so later cleanup never ran.

That second point matters. The fragile part wasn't only the full queue. Once one cleanup step failed, the rest of the shutdown gave up too.

The Register reported that the GitHub security report includes a conceptual proof of concept: a Python script that simulates how flooding an event queue can block a hangup. "Simulates" is the key word. It shows the logic of the bug. It isn't evidence of a working attack used against real Signal users.

What the fix changes​

The Register compared RingRTC 2.72.0 with the previous version. It found that the fixed FSM can detect termination requests without going through the event queue, and that a new timeout stops stalled processing from blocking a hangup forever.

SQ Magazine's reading of the code change adds detail: RingRTC 2.72.0 adds a separate termination flag and five-second shutdown limits, so cleanup keeps going when steps fail. It also reports that Signal developer jim-signal authored the fix and described it as a change that ensures complete call termination in exceptional circumstances. FDayTalk notes that Signal also added regression tests that simulate full call and connection queues plus failed app notifications.

From an engineering view, this is the right shape of fix. Hangup is now a priority signal that doesn't wait in line behind everything else, and cleanup keeps going instead of quitting at the first error. Most well-built real-time systems already work this way, and it's a little surprising RingRTC didn't. Still, no patch can promise media stops in every imaginable failure. The evidence supports "much more robust hangup handling," not "guaranteed."

Section summary: RingRTC 2.72.0 handles hangup outside the event queue, adds timeouts, and keeps cleanup going when a step fails.

Which Signal versions are affected?​

This is where public information gets uneven.

Italy's national CSIRT published advisory AL03/261020/CSIRT-ITA with these boundaries:

The CSIRT rated the impact on its community as High (65.76). It classed the issue as information disclosure and recommended prompt updates to the latest release.

Not everyone has pinned down app versions the same way, though. SQ Magazine reported that Signal app versions affected by the flaw remain unconfirmed, so users should install the latest update on each device. It added that, as first reported by CyberInsider, Signal had not answered questions about which client versions, if any, are affected. The Register also asked Signal for comment and hadn't heard back by publication. It did say Signal Desktop's release history shows RingRTC 2.72.0 was added in September, but rollout dates for each platform are unclear.

So treat the CSIRT version numbers as a useful triage guide, not a promise from Signal. Either way the advice is the same: run the newest version available.

How bad is it?​

The severity rating depends on who you ask:

• The CVE record (from MITRE as CNA): Critical 9.3 under CVSS 4.0. The vector Strix lists includes AV:N/AC:L/AT:N/PR:N/UI😛/VC:H: network attack, low complexity, no privileges needed, passive user interaction, high confidentiality impact.
• VulDB: calls it a vulnerability classified as problematic, with a VulDB Base Score: 4.3 under CVSSv3, and maps it to CWE-400 (resource consumption) instead of CWE-754.
• Exploitation status: The Register found no sign of it in CISA's Known Exploited Vulnerabilities catalog. TheHackerWire's tracker also shows it Not in KEV Catalog.

How can one bug score 4.3 and 9.3? It depends on what you measure. If you see it as "a peer can clog a queue," it looks like a modest denial-of-service issue. If you score the actual outcome, a live microphone the victim believes is off, it becomes a serious privacy problem. For people who use Signal because they care about confidentiality, the second view matters more.

There's also a natural limit. The attacker has to be someone you're already on a call with, so this isn't a drive-by exploit. The realistic risk is a malicious contact, or a compromised account, using a call to keep listening after you've said goodbye. That's exactly the kind of person Signal users worry about.

One point is settled: CVE-2026-113380 is a call teardown bug, not an encryption flaw. Nothing in the advisories suggests stored messages, keys or chat history were exposed.

Section summary: scores range from 4.3 to 9.3. Exploitation needs a hostile caller, and there are no confirmed attacks in the wild.

What Windows users should do now​

1. Update Signal Desktop on every Windows PC. Signal offers Windows builds through its official download page and the Microsoft Store. Make sure the installed version is at least 8.29.0, and ideally the newest release available.
2. Update your phone separately. Signal Desktop is linked to your phone, but each app updates on its own. Updating the PC doesn't fix the phone, and the reverse is also true.
3. Check the version number yourself. Signal Support sends desktop users to its GitHub release notes for version details. Compare what's installed against the cutoffs above.
4. Admins: inventory Signal installs. If Signal is allowed on managed Windows devices, check whether your software inventory tool can report Signal Desktop versions, and flag anything below the fixed release.
5. Use OS-level controls as a backstop. If a call ever seems to linger, closing the app or turning off microphone and camera access in Windows privacy settings is a sensible general precaution. These are general good habits, not tested workarounds for this specific CVE. Updating is the fix.

The bigger picture​

This bug is a reminder that end-to-end encryption protects data in transit. It says nothing about whether the app does what its buttons claim. A perfectly encrypted stream sent after you thought you'd hung up is still a privacy leak.

It also highlights a familiar weakness: the code paths for unusual situations (full queues, failed cleanup steps) get far less testing than the normal ones. Signal's new regression tests that deliberately fill the queues are the right response, and other WebRTC-based apps would benefit from the same.

In the meantime, update every device, and maybe keep the post-call commentary to yourself until the app actually closes.