Encrypted messaging giant Signal has successfully resolved a critical-severity security vulnerability that could have allowed a malicious caller to secretly keep a target’s audio and video streams active even after the user believed they had terminated the call. The severe flaw exposed potential privacy risks by manipulating how call termination events were processed within the application’s underlying communication architecture.
The security defect has been officially tracked and cataloged under the identifier CVE-2026-113380. Security rating systems have assigned the vulnerability a critical CVSS score of 9.3 out of a possible 10, reflecting the severity of the privacy breach it enabled. The flaw specifically impacts RingRTC, the open-source library that Signal utilizes to manage both voice and video calls across its supported platforms. RingRTC itself is built upon WebRTC, a widely adopted open-source project that enables real-time communication via simple application programming interfaces and browser protocols.
According to technical breakdowns of the vulnerability, the core issue stemmed from how the application’s call state was managed during active sessions. Specifically, a remote peer participating in a call could flood the Finite State Machine event queue with a massive volume of junk data. Because of this artificial congestion, the call would systematically fail to terminate properly when the victim attempted to hang up.
The architectural vulnerability existed because the standard hang-up action was not treated as an immediate, absolute kill switch by the software. Instead, the command to end the call was processed merely as a standard event that was added directly to the Finite State Machine event queue, sitting behind whatever data was currently being processed. Compounding the risk, there was no rate-limiting mechanism in place to restrict peer-originated events, and the incoming hang-up event was not assigned any higher priority than routine communication packets.
A detailed technical write-up published on GitHub by a security researcher explained the mechanics of the exploit clearly. The researcher noted that an attacker could flood the internal event queue with enough junk data that the legitimate hang-up command would be forced to wait behind the attacker’s noise indefinitely. Consequently, the actual call infrastructure—including the device’s microphone and potentially its camera—was never properly torn down by the software.
By successfully exploiting this vulnerability, a malicious actor could effectively trick a victim into believing that a conversation had ended. While the user stared at a screen indicating that the call was closed, the underlying audio and video tracks would continue flowing silently back to the attacker’s device, capturing ambient room sounds and visual data without the user’s knowledge or explicit ongoing consent.
The security defect has been fully addressed and resolved in RingRTC version 2.72.0, which Signal officially released to the public on September 4. While the software patch was deployed to remediate the vulnerability early in the month, deeper technical details concerning the exact nature of the flaw were made public on Tuesday, alongside a conceptual proof-of-concept demonstrating how the exploit could be structured. Simultaneously, the National Institute of Standards and Technology formally added the CVE entry to the National Vulnerability Database on Tuesday to ensure proper tracking across the cybersecurity community.
Signal neutralized the security risk by altering how the internal system handles call termination requests. Developers ensured that call-ending commands are no longer blocked behind the Finite State Machine’s general event queue and can instead be detected and executed independently of incoming network noise.
In light of the severity of CVE-2026-113380, cybersecurity professionals strongly advise all Signal users to update their applications to the latest available version as soon as possible. For users who may not have immediate access to updates, security experts recommend paying close attention to device status indicators—such as hardware permission lights or operating system notifications showing active microphone or camera usage—to confirm that communication hardware has indeed powered down after ending a call.
