Signal RingRTC EUVD-2026-104796

Requires an active RingRTC call (Signal) in which the attacker is an accepted peer and can push enough events to saturate the call's bounded FSM event channel; the victim must then initiate a local hangup for the impact (failed teardown) to manifest. Limiting factors: the attacker must already be a call participant (not an arbitrary remote attacker), the victim must be in a call and actively hang up (UI:P), and only RingRTC versions before 2.72.0 are affected - no non-default configuration is otherwise needed.

Signals are mixed and require careful weighting. The supplied CVSS 4.0 base score is 9.3 (critical) with AV:N/AC:L/AT:N/PR:N/UI:P and high confidentiality/integrity impact (VC:H/VI:H) plus a scope change (S:P, SC:H). However, the real-world attack surface is narrower than a 9.3 suggests: exploitation requires the attacker to already be an active peer in a RingRTC/Signal call with the victim (reflected by UI:P), not an arbitrary internet-based attacker. There is no EPSS score, no CISA KEV listing, and no public POC in the provided data - the only references are the fix commit and the v2.71.0...v2.72.0 compare, so exploitation status is 'no public exploit identified at time of analysis.' The confidentiality rating is credible: the flaw lets a malicious peer saturate the call's finite-state-machine event queue so a local hangup fails to tear the call down, leaving the microphone (and possibly camera) transmitting after the user believes the call ended - a genuine privacy exposure matching the 'Information Disclosure' tag and CWE-754 (improper check for exceptional conditions). Note a nuance worth verifying: the vector sets VA:N (no availability impact) even though the root cause is a queue-saturation/DoS of the teardown path - this is internally consistent because the call stays up rather than going down, but defenders expecting a classic availability DoS should be aware the harm is continued media exposure, not call loss. Net assessment: a real and worth-patching privacy bug for Signal deployments, but the critical score overstates mass-exploitation risk because it needs an in-call adversary and victim-initiated hangup rather than opportunistic remote exploitation.

A malicious participant in a Signal call floods the call's FSM event queue with enough events to saturate it. When the victim then presses hang up, the teardown blocks on the saturated queue and never completes, so the victim's microphone (and potentially camera) keep transmitting after they believe the call has ended. No public exploit code is available; the attacker must be an established call peer.