Signal Hang-Up Flaw Could Keep Your Microphone Open After the Call Ended

9.3 out of 10 for a Signal flaw. After hang-up, the microphone could stay live for the other side, maybe the camera too. Hanging up was the right move. A full queue of 256, there since 2020, refused it.

You pressed hang up, and as far as you knew, the call was over. You put the phone down and went on talking to whoever was in the room with you. Your phone might not have ended the call. The connection that carried your voice could still be open, if the person on the other end wanted it that way.

All that person had to do was send your phone a flood of small messages, more than the calling code could take in. While those piled up, your hang-up never got through. The sound from your microphone kept going out, and possibly the video too.

The flaw is listed as CVE-2026-113380, and the CVE record scores it 9.3 out of 10. It sat in RingRTC, the piece of Signal that runs voice and video calls, and that piece is built into the Android app, the iPhone app and the desktop app. The microphone part is certain. The camera is a maybe: the CVE record and the writeup that came with it both say possibly, and neither of them shows it happening.

Signal is the app you pick when a call has to stay private. On Android alone it has more than 100 million downloads, and its store page promises encrypted voice and video calls. That encryption held up throughout this story. The person who could abuse this flaw was already in the call with you: a contact who calls you, or someone you call yourself.

Inside the calling code, each call is run by a state machine, a piece of code that knows where the call is: ringing, connecting, connected, ending. Everything that happens during a call becomes an event, a small message that says something changed. The other side sent new data, the network shifted, the video quality dropped, someone pressed a button. Those events go into a queue and are handled one after the other, in order.

Before the fix, that queue had room for exactly 256 events. One line in Signal’s code set that limit:

1

let (fsm_sender, fsm_receiver) = std::sync::mpsc::sync_channel(256);

Your hang-up was one more event in that same queue, and it got no priority over the other events. The other person on the call could send events into it too, as many as they liked, with no limit on how fast. So the attacker kept the queue full. When you pressed hang up, Signal tried to add your hang-up to the queue, found no free place, and got an error back. The code that ended a call started with these three lines:

1
2
3

self.set_state(CallState::Terminating)?;
self.inject_event(CallEvent::Terminate)?;
self.wait_for_terminate()?;

The question mark at the end of each line is how the Rust language says: if this step fails, stop here and hand the error back. The second line failed because the queue was full, so the function stopped right there. The steps that came after it, closing the connections and shutting the call down, never ran.

So the call stayed open.

And the wait in the third line had no time limit. If the call’s processing got stuck, the code kept waiting with no end, and the call could stay half closed for as long as that lasted.

The proof of concept that came with the CVE, a small demo script, shows the problem as a model, with 5,000 junk events piling up in front of the hang-up in a queue without a limit. Signal’s own code was stricter than that model. The queue stopped at 256, and once it was full, your hang-up was refused at once.

The same thing happened one level deeper. Each call also has a connection, the link that carries the audio and video, and that connection runs its own state machine with its own queue of 256. Its shutdown code worked the same way, so a full connection queue could block the hang-up there as well.

The 9.3 comes down to how little the attacker needed. A normal Signal account and a call with you, that was it. Your phone did not have to be hacked first, and there was nothing for you to click. Being in the call was all you had to do, which is why the rating calls your part passive. The full rating line reads:

1

CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:P/VC:H/VI:H/VA:N/SC:H/SI:N/SA:N/S:P

CISA, the US cyber agency, looked at it as well. It saw no sign of attacks, it does not think this one can be automated, and it still rated the damage as total.

Signal’s calling code had a flaw of this kind once before. In September 2019, Natalie Silvanovich of Google Project Zero looked at how Signal decides when a call is connected. She found that a caller could send a message that made the call connect by itself. The caller could then hear what was going on around the person they called, before that person had answered. Signal fixed it in the app that same month.

She published her full findings in a blog post in January 2021. Her starting point was the Group FaceTime bug of January 2019. It let a caller force a call to connect and listen to the person on the other end, without that person doing anything.

She tested seven calling apps and found bugs of this kind in five of them. One of them, in Google Duo in September 2020, worked almost exactly like this one. She sent so many data messages that the queue the app needed to switch the video off filled up, and the video stayed on longer than it should have.

After its 2019 fix, Signal replaced its old call setup code with a new calling library, and in that same blog post she noted that the new library used a stricter state machine. That library is where this new flaw was found. The first version of its call manager, written in February 2020, already had the queue of 256. A full queue dropped the hang-up there too, and the wait had no time limit either. In that first version the hang-up was called EndCall instead of Terminate, but it went through the same queue in the same way.

The fix in September 2026 was written by Jim Gustafson, the same Signal engineer who wrote that first call manager in 2020.

The CVE number came from MITRE, the organization that hands those numbers out, at the request of someone outside Signal. It was created at 04:25 UTC on October 20 and made public less than a second later. About an hour after that, a GitHub account called Imahian put the writeup online, together with that demo script, written in Python. The script has no network code in it and does not touch Signal.

The writeup does not name the person behind it, gives no date of discovery, and does not say whether the bug was ever reported to Signal. The same account has published about 300 CVE writeups. That same morning it added another one, for a flaw in Roundcube webmail whose fix had come out the day before.

Signal itself never called this a security problem. The fix went in on September 4 with the commit message Ensure calls terminate completely in corner cases, and the library’s changelog says nothing about a vulnerability. When The Register, CyberInsider and Malwarebytes asked Signal about the flaw, none of them had an answer by the time they published. Whether the account behind the CVE found the bug itself or spotted it by reading Signal’s public fix, no source says.

Now, when you press hang up, your phone sets a separate flag, a simple yes or no value in the code. The call checks that value after each message it handles, however full the queue is. A full queue cannot hold up the hang-up anymore. The new code says it in one comment:

1

// Terminate out of band, independent of queue depth.

The waiting has a limit now too. A new value in the code, TERMINATE_TIMEOUT, gives the call five seconds to shut down cleanly. After that, the call is closed anyway.

The fix touches 12 files and adds 691 lines, and part of it is new tests. One of them is called hangup_with_saturated_call_fsm_queue. It fills the call’s queue on purpose until it refuses new events, presses hang up, and then checks that the connection is closed and that no more audio goes out. Signal tested the core of this attack in its own code on September 4, 46 days before the CVE existed.

The fixed version of the library, 2.72.0, came out on September 4, 2026. Then it still had to reach the apps. These are the first versions with the fix, and the date each one was ready in Signal’s public code:

• → Android 8.27.0 in beta on September 10, first full release 8.28.4 on September 23
• → iPhone 8.30, September 22
• → Desktop 8.29.0, released October 1

The fix was in the phone apps’ releases in September. How fast the app stores rolled it out is not public. The desktop app stayed vulnerable until October 1. The public found out on October 20. There is no public report of it being used in an attack.

To check your own version, open Signal. On your phone it is under Signal Settings > Help > Version. In the desktop app it is under Help > About on Windows and Linux, or About Signal Desktop on a Mac. You need at least:

• → Android: 8.27.0
• → iPhone: 8.30
• → Desktop: 8.29.0

If you are below that, update through the app store. On Windows or Mac, quit and reopen the desktop app so it picks up the update. On Debian or Ubuntu it updates through APT:

1

sudo apt update && sudo apt install signal-desktop

One habit from the writeup holds for other calling apps too: after you hang up, check that the call indicator on your screen is gone.

From February 2020 until September 2026, the button that ends a Signal call depended on the other side leaving room for it in a queue of 256.

On your own laptop, you can flood a small test server until its connection table is full and see for yourself what stops answering. My Ethical Hacking Complete Course Zero to Expert takes you there step by step: reconnaissance, scanning, exploitation and traffic analysis, hands-on, from your first day with no Linux or hacking background.

→ Join my complete ethical hacking course

Hacking is not a hobby but a way of life.

Sources:

CVE-2026-113380 record | RingRTC fix commit | Project Zero, The State of State Machines