Signal RingRTC flaw CVE-2026-113380 can delay hang-ups, keeping call audio flowing

What happened

A researcher has published full details and a proof of concept for CVE-2026-113380, a vulnerability rated 9.3 under CVSSv4 in RingRTC, the library that powers voice and video calls in Signal on Android, iOS and Desktop. According to a technical write-up published on dev.to in late October 2026, which draws on SecurityOnline's October 22 report, the flaw lets the remote party in a call keep a victim's line open after the victim has tried to hang up, so microphone audio — and possibly camera data — keeps flowing.

How the queue flaw works

RingRTC runs each call as a finite-state machine fed by an event queue. In that design, a local hang-up is not an immediate kill switch: it is appended as one more event behind whatever the queue already holds. The remote peer faces no rate limit on the events it generates, and the hang-up is given no priority over them. By filling the queue with junk, a peer pushes the hang-up back far enough that the call keeps running — audio included — while the user believes it has ended. Triggering the condition requires nothing beyond starting a normal call, according to the write-up.

What the proof of concept actually shows

The published proof of concept is worth reading carefully. The write-up describes it as a synthetic, offline simulation of the queue rather than an attack recorded against a live Signal client. The demonstration models the queue semantics laid out in the disclosure; it is not captured traffic from a real target. Defenders weighing the severity should therefore separate the described mechanism, which is well explained, from evidence of a working end-to-end exploit, which the reporting does not provide.

The fix and what users should do

The fix lands in RingRTC 2.72.0 and works on two fronts, according to the write-up. A termination flag now skips the queue entirely, restoring immediate control to the user, and teardown waits are capped at five seconds, so the session ends even if something else keeps the queue full.

Every Signal client bundling a RingRTC build older than 2.72.0 is affected, and the relevant check is the app build, not any setting. The advice is to update Signal through the app store and then verify that the call indicator disappears when a call ends — the only user-visible test the reporting describes, and one the write-up recommends performing rather than assuming.

What remains unconfirmed

Several claims around the vulnerability stop short of confirmation. No source cited in the reporting confirms exploitation in the wild, and the CVE does not appear in CISA's known exploited vulnerabilities catalog. The EPSS figure quoted is 0.3% over 30 days, which forecasts exploitation likelihood rather than measuring actual exposure.

Open questions include whether the saturating peer needs a modified client to generate the flood, how many events are required to fill the queue in practice, and whether the three platforms differ in exposure. Because Android, iOS and Desktop all bundle the same library, the write-up suggests the defect is shared, but it does not rank the platforms.

Why it matters

The flaw undermines a basic assumption of any calling app: that pressing hang-up stops the conversation and mutes the microphone. For Signal, a messenger whose reputation rests on privacy, a call that keeps transmitting after the user ends it is damaging whether or not anyone has exploited it yet.

The broader lesson is architectural. Ending media capture is a control operation, and it belongs on a path an untrusted peer cannot congest. Any real-time client where the stop instruction shares a queue with events generated by the other party inherits the same weakness: the effect of the operator's intent depends on queue depth. Signal's remedy — a bypass flag combined with a bounded teardown wait — is a compact, fail-safe pattern, because the timeout still ends the session if the queue never drains. For anyone building or reviewing calling and streaming software, the question to ask is whether hanging up depends on the same channel that carries the peer's media. If it does, the write-up argues, that is a design problem, not a patch problem.