A researcher published full details and a proof-of-concept for CVE-2026-113380, rated 9.3 under CVSSv4. The flaw lives in RingRTC, the library that powers voice and video calls in Signal on Android, iOS and Desktop. Versions before 2.72.0 are affected.
The mechanism fits in one sentence. A peer that saturates a call's finite-state-machine queue can delay the local hang-up, because the hang-up sits in the same queue as ordinary events.

What the queue does

RingRTC handles each call with a finite-state machine and an event queue. A local hang-up is not a kill switch in that design. The researcher's description is that it becomes one more event placed at the back of the queue. The remote peer faces no rate limit, and the hang-up receives no priority. If the peer fills the queue with junk, the hang-up waits behind it, and the call's audio keeps flowing.
The published proof-of-concept models the flaw as a purely synthetic, offline queue simulation rather than a live exploit. Defenders reading the claim in isolation should note that the demonstration rests on the queue semantics described in the write-up rather than on recorded traffic against a live target.
The practical consequence is straightforward. A user who trusts that hanging up ends a call may still be transmitting microphone audio, and possibly camera data, to the other party. Triggering it requires only that the attacker start a normal call.

Why a control message in a data queue is a general defect

The specific bug is closed by the fix, but the design pattern recurs. Any system where a stop instruction shares a queue with content generated by an untrusted peer has the same property: the instruction's effect depends on queue depth rather than on the operator's intent.
The Signal fix addresses it in two ways, both of which are worth borrowing. It adds a termination flag that bypasses the queue, and it caps teardown waits at five seconds. The first restores control semantics. The second bounds the damage if something else keeps the queue full.

What an affected user should do

Update Signal from the app store. All RingRTC versions before 2.72.0 are affected, which includes every Signal client still bundling an older build, so the check is about the app build rather than about any setting.
After updating, verify the call indicator disappears when a call ends. That observation is the only user-visible test the reporting describes, and it is worth performing once rather than assuming.

What the reporting does not establish

No source confirms exploitation of this vulnerability in the wild, and it does not appear in CISA's known exploited vulnerabilities catalog. The EPSS figure quoted in the reporting is 0.3% for 30 days, a prediction of exploitation likelihood rather than a measure of exposure.
The reporting also does not state whether the saturating peer needs a modified client, how many events are required to fill the queue in practice, or whether any platform was affected differently from the others. Three operating systems bundle the same library, which suggests the defect is shared, but the reporting does not rank exposure by platform.

The broader lesson for anyone building a real-time client

Termination is a control-plane operation and belongs on a path the peer cannot starve. A teardown timeout that runs independently of the event queue is the minimum. The Signal approach, a bypass flag plus a bounded wait, is a compact pattern because it fails safe: if the queue never drains, the timeout still ends the session.
The case adds one more item to a client-software review that rarely gets attention. Ask of any calling or streaming application whether stopping the capture depends on the same channel that carries the incoming media. If it does, the answer is a design question, not a patch question.

References

  • SecurityOnline, "Signal Call Vulnerability Details and PoC Published, Showing Hang-Up Can Fail to End Calls", 22 October 2026: https://securityonline.info/signal-call-vulnerability-ringrtc-poc/

  • Researcher write-up and proof-of-concept for CVE-2026-113380 referenced in the reporting (published October 2026).