RingRTC before 2.72.0. That covers every Signal client embedding an older RingRTC build — Android, iOS, and Desktop — until the client ships the fixed library.
A local hang-up is not a kill switch: it is just one more event placed at the back of the call's finite-state-machine event queue. The remote peer is trusted with that queue — there is no rate limit on peer-originated events and no priority lane for hang-up. Flood the queue with junk and the hang-up waits behind attacker noise forever, so the call (microphone, possibly camera) is never torn down.
Proof of concept (conceptual)
The attacker starts a normal Signal call with the victim.
From their side they saturate the call's FSM event queue with junk events.
The victim taps hang-up; the event lands at the back of a full queue and is never processed.
The call's audio track — and possibly the video track — keeps flowing to the attacker while the victim believes the call ended.
The accompanying poc.py demonstrates the pattern safely: a queue model where a flood buries a hang-up event versus a model where hang-up always jumps the queue. Purely synthetic, offline, no network, no real calls — no exploit.
Update now : RingRTC 2.72.0 or later fixes the queue handling; on the Signal app, install the latest update from your app store.
Verify calls end : after hanging up, double-check the call indicator is gone before discussing anything sensitive.
For developers : critical control events must never a queue with untrusted input — give them a priority lane and rate-limit peer-originated events.
Watch the explainer Short
NVD:
RingRTC fix commit:
RingRTC v2.71.0 → v2.72.0:
Educational material only. Do not use against systems you do not own or have explicit permission to test.
Educational material only. Do not use against systems you do not own or have explicit permission to test.
The full story
This article is one source in a clustered incident — the cluster page carries the summary, timeline and every other outlet covering it.
