The Signal Hang-Up Bug: CVE-2026-113380 Could Keep Your Microphone Active After You End a Call

Imagine having a private conversation over Signal. You finish speaking, press the red hang-up button and put your phone down.

You assume the call has ended.

But what if the application has received your request to terminate the call without actually completing the shutdown process?

That is the privacy concern behind a critical vulnerability discovered in Signal's calling infrastructure.

Tracked as CVE-2026–113380, the vulnerability affected RingRTC, the open-source library responsible for handling real-time voice and video communication in Signal.

The interesting part is that this wasn't a traditional encryption-breaking vulnerability. It involved something much more fundamental: how an application processes events and manages the lifecycle of an active call.

Let's look at what happened from an application security and software engineering perspective.

What Is CVE-2026–113380?

CVE-2026–113380 is a critical vulnerability affecting versions of Signal's RingRTC library before version 2.72.0.

The vulnerability received a CVSS 4.0 severity score of 9.3 (Critical).

RingRTC is an open-source calling library used by Signal to support real-time audio and video communication. It is built around WebRTC technology.

According to the vulnerability description, a remote peer participating in a call could saturate the call's internal Finite State Machine (FSM) event queue.

This could interfere with the local user's ability to terminate the call properly.

In practical terms, a user could press the hang-up button while the application failed to complete the teardown of the call, potentially leaving audio and possibly video tracks active.

The vulnerability was publicly documented on 20 October 2026.

Understanding the Technical Problem: How Does a Call Actually End?

To understand this vulnerability, we need to look beyond the user interface.

When someone presses the hang-up button, the application has to do much more than simply change the screen from an active-call interface to an idle screen.

It needs to coordinate several operations:

• Stop audio capture.
• Stop video capture, where applicable.
• Terminate media tracks.
• Update the call state.
• Notify the remote participant.
• Close the relevant connections.
• Release associated resources.
• Remove the active call session.

These operations need to happen reliably, even when the application is processing a large number of events.

RingRTC uses finite state machines to manage call and connection states.

An FSM processes events and transitions between defined states according to application logic.

For example:

Incoming Call → Connected → Active Communication → Terminating → Terminated

The problem identified in this vulnerability was related to how the termination request was handled within the event-processing architecture.

How Could an Attacker Interfere With the Hang-Up Process?

The vulnerability involved event queue saturation.

Think of an event queue as a waiting line.

Every event that needs processing enters the queue, and the application processes those events according to its state machine logic.

In the vulnerable implementation, the hang-up request was also handled through this event-processing mechanism.

A malicious participant could generate enough peer-originated events to saturate the queue.

Consequently, the local termination request could remain delayed behind other queued events.

The application might receive the user's instruction to end the call, but the state machine could fail to process the request and complete the teardown as expected.

The potential result?

The user believes the call has ended, while audio and potentially video communication may remain active.

There is an important limitation: this scenario involves a malicious peer participating in the call. It does not mean that an unrelated stranger could remotely activate the microphone of any Signal user.

Breaking Down the Vulnerability From an Application Security Perspective

There are three important technical weaknesses worth examining.

1. Event Queue Saturation

The first issue involved the handling of incoming events.

The attacker could generate enough events to interfere with the processing of the call's state machine.

A secure event-processing architecture should consider:

• Queue capacity.
• Event prioritisation.
• Rate limiting.
• Input validation.
• Backpressure mechanisms.
• Handling of unexpected event volumes.

A remote participant should not be able to indefinitely delay a critical local security operation by generating excessive events.

2. No Independent Priority for Call Termination

This is arguably the most interesting design issue.

A termination request is not an ordinary application event.

When a user decides to end a call, the application should prioritise that decision over routine processing.

If termination depends entirely on a queue that can be influenced by a remote participant, the application introduces an unnecessary dependency into a security-critical operation.

The hang-up operation should have a reliable mechanism to proceed independently of the normal event backlog.

3. Incomplete Teardown Handling

Another important aspect addressed in the corrective changes was error handling during termination.

A shutdown process may involve multiple operations. If one operation fails, the application should not necessarily abandon all subsequent cleanup.

For example, an error while notifying the application layer should not automatically prevent other necessary teardown operations from proceeding.

Security-sensitive cleanup should be designed to continue as safely as possible, even when individual steps encounter errors.

What Was the Actual Impact?

The primary concern was the possibility of continued audio transmission after the user believed the call had ended.

The vulnerability description also mentions potential continued video activity.

However, the available reporting does not establish that continued video transmission was independently demonstrated in a real-world attack.

The potential impact can be understood in three areas:

Privacy: Audio could potentially remain available to the malicious participant after the victim attempted to hang up.

Confidentiality: Private conversations could be exposed beyond the point at which the user believed communication had stopped.

Application integrity: The application could fail to honour an important user-initiated state transition.

This is particularly concerning because users generally rely on the hang-up action as an explicit privacy boundary.

Did This Break Signal's End-to-End Encryption?

No demonstrated encryption break was involved.

This distinction is important.

End-to-end encryption protects communication from unauthorised interception while information is transmitted between participants.

However, encryption does not automatically protect against application-level failures.

Consider this example:

• Your device captures microphone audio.
• The application processes that audio.
• The communication library handles the media stream.
• The encrypted communication is transmitted to the other participant.

If the application fails to terminate the media session, encryption alone does not prevent the intended call participant from continuing to receive audio.

In other words, the encryption mechanism can work correctly while the application mishandles the lifecycle of the communication session.

This is why secure application development requires more than implementing strong cryptographic algorithms.

It also requires correct state management, permission handling, resource cleanup and secure communication logic.

How Was CVE-2026–113380 Fixed?

Signal addressed the vulnerability in RingRTC version 2.72.0, released on 4 September 2026.

The corrective changes are particularly interesting from a secure software engineering perspective.

The fix introduced several improvements.

1. Independent Termination Flag

A separate termination flag was introduced so that the application could recognise a termination request independently of the normal event queue.

This means that the user's request no longer has to wait indefinitely behind queued events.

2. Bounded Termination Waiting

The updated implementation introduced a five-second timeout for waiting for the state machine to become inactive before proceeding with teardown.

This helps prevent shutdown from waiting indefinitely.

3. Bounded Event Queue

The implementation also defines a bounded event queue capacity of 256 events.

This provides an explicit limit rather than allowing the queue to grow without a defined bound.

4. More Resilient Cleanup

The updated termination process also handles individual cleanup errors more carefully.

Instead of stopping the entire cleanup sequence when one operation fails, the implementation logs errors and continues with subsequent termination steps where possible.

5. Regression Testing

The corrective changes included tests designed to simulate conditions where the state machine is delayed and verify that termination can still complete.

These changes are documented in Signal's public RingRTC repository.

What Should Signal Users Do?

The vulnerability was fixed at the RingRTC library level, but users should make sure their actual Signal applications include the corrected version.

Here are my recommendations:

1. Update Signal on Android, iOS and desktop to the latest available release.
2. Do not rely on an older installation simply because it continues to function normally.
3. Review microphone and camera permissions at the operating-system level.
4. Pay attention to microphone and camera activity indicators after ending calls.
5. If an indicator remains active unexpectedly, investigate which application is using the microphone or camera.
6. Avoid assuming that every unusual microphone indicator is related to this specific vulnerability.

It is also worth remembering that the exact first Signal application releases containing the fix were not consistently established in the initial reporting. Updating to the latest available release is therefore the safest recommendation.

What Can Developers Learn From This Vulnerability?

This incident is a useful example for developers working on real-time applications, WebRTC platforms, messaging software and communication systems.

There are several engineering lessons worth considering.

AreaSecurity recommendationEvent handlingImplement bounded queues and backpressureState managementProtect critical state transitionsTermination logicGive shutdown operations independent execution pathsResource managementEnsure media tracks are properly releasedError handlingContinue cleanup despite individual failuresInput processingValidate and control peer-originated eventsTestingSimulate queue saturation and abnormal event sequencesPrivacyVerify that microphone and camera access stops after termination

One particularly important lesson is that security-critical operations should not depend entirely on resources that an untrusted remote participant can influence.

This principle applies well beyond messaging applications.

The same architectural concern can appear in:

• WebRTC conferencing platforms.
• Video streaming applications.
• Remote desktop software.
• Multiplayer communication systems.
• Real-time collaboration tools.
• IoT communication services.

Whenever a remote participant can influence the event-processing pipeline, developers need to consider what happens when that pipeline becomes overloaded.

Final Thoughts

What makes CVE-2026–113380 interesting is its simplicity.

There was no demonstrated need to break Signal's encryption, steal a password or compromise the entire device.

The issue was associated with how the application handled a fundamental operation: ending a call.

From a security engineering perspective, this reinforces an important principle.

A security feature is only as reliable as the implementation behind it.

We spend considerable time discussing encryption, authentication, secure communication protocols and vulnerability management. But application lifecycle management, event processing and resource cleanup deserve the same level of attention.

A hang-up button should do more than change the user interface. It should reliably terminate the communication session.

Because when users press that button, they are not simply closing an application screen. They are making a privacy decision.

And the software must respect it.

Accuracy note:_ This article is based on the CVE record, Signal's public RingRTC code changes and security reporting available as of 30 October 2026. The vulnerability affected RingRTC versions before 2.72.0. No confirmed in-the-wild exploitation was reported in the security coverage reviewed. Potential video exposure should be distinguished from independently demonstrated impact._

Author: Salil Sardesai