"Make sure you don’t say anything mean or secret after hanging up a call on Signal," The Register warned — and with good reason: a critical bug in Signal’s calling library can leave audio and potentially video channels open after a user thinks a call has ended.
CVE-2026-113380 and RingRTC's finite state machine event queue
MITRE published CVE-2026-113380 on Tuesday, assigning it a CVSS score of 9.3 and classifying it as a critical vulnerability in Signal’s open-source RingRTC library for every version before 2.72.0. RingRTC is Signal’s calling library built on top of WebRTC — a technology the report notes was introduced in 2011 and is widely used for internet voice and video communication. The underlying weakness is reported as CWE-754: improper checking for unusual or exceptional conditions.
How queue saturation can prevent a hangup from being processed
The technical root of the problem is straightforward: RingRTC’s finite state machine (FSM) relies on an event queue to manage call-related events. If an endpoint on the call floods that queue with requests, the FSM can become saturated and fail to process a termination (hangup) request. The practical result described in the advisory is that the user who thinks a call has ended may still have their audio — and possibly video — channels open to the other party.
Audit-ready is a season. It shouldn't be.
Evidence in spreadsheets, controls drifting between audits, frameworks multiplying on flat headcount. Nubivance runs continuous compliance on Rapid7 Cyber GRC - SOC 2, HIPAA, ISO 27001, PCI, CMMC.
End the scrambleProof-of-concept, exploitability, and observed usage
The public write-up linked from the advisory includes a conceptual proof-of-concept on GitHub: a Python script simulates flooding the event queue and demonstrates how a hangup request can be prevented from processing. The CVE record characterizes the attack complexity as low. The U.S. Cybersecurity and Infrastructure Security Agency’s known exploited vulnerabilities catalog does not list this vulnerability as seen in the wild.
What RingRTC 2.72.0 changes — and rollout uncertainty
Comparing RingRTC 2.72.0 with previous releases shows two specific mitigations. First, the FSM was changed so termination requests can be detected independently of the event queue. Second, the update adds a timeout to prevent stalled processing from indefinitely blocking a hangup. The Register reports the fixed RingRTC 2.72.0 was pushed out last month, and that Signal Desktop’s release history indicates the build was incorporated in September. Precise rollout dates for Android and iOS remain unclear; The Register says requests for clarification to Signal were unanswered at time of publication.
What this means for technologists, Signal users, and enterprises
- Technologists and security teams: verify that deployed Signal clients — both mobile and desktop — include RingRTC 2.72.0 or later. Where possible, check application release histories and ensure update policies capture the desktop client as well as mobile apps.
- End users and the general public: update your Signal installations to the latest versions and be mindful that a hangup may not always mean media channels have closed if you are still running an affected version.
- Enterprises and procurement leaders: confirm which Signal builds are approved and deployed in managed environments and, where needed, require proof of the RingRTC 2.72.0 inclusion in vendor change logs before allowing use in sensitive contexts.
The vulnerability is a reminder that even end-to-end encrypted media channels can be undermined by application-layer flaws. Signal’s fix — making termination detectable outside the event queue and adding a timeout — addresses the immediate failure mode, but the staggered and partially documented rollout means some users could remain exposed. Until every client in use is on a fixed release, the simplest mitigations are administrative: update widely, verify releases where possible, and err on the side of caution about what you say after a call ends.
