Signal Vulnerability Lets Malicious Callers Block Hang-Ups

What it is

CVE-2026-113380 (CVSS 9.3) is a flaw in RingRTC, the open source WebRTC-based library Signal uses for voice and video calls. A remote peer can keep a target's microphone, and possibly camera, streaming after the target has hung up, while the target believes the call ended.

How it works

The page gives three design defects that combine:

• Hang-up is an ordinary event in the call's finite state machine (FSM) event queue, not a kill switch.
• Peer-originated events have no rate limit.
• The hang-up event has no priority.

An attacker floods the queue with junk events. The hang-up waits behind them, so the call is never torn down. The researcher's GitHub write-up puts it this way: "Flood the queue with junk and the hang-up waits behind attacker noise forever, so the call (microphone, possibly camera) is never torn down."

flowchart LR
    A[Peer floods FSM queue] --> B[Hang-up queued behind junk]
    B --> C[Call never torn down]
    C --> D[Audio/video tracks stay live]
    E[Fix: hang-up detected outside queue] -.cuts.-> B

Preconditions / Affected

• The affected component is RingRTC in Signal voice and video calls, in versions before 2.72.0.
• The attacker must be the remote peer on the call.

What to do

• Update Signal to a build that includes RingRTC 2.72.0 (released September 4) or later.
• Until then, check the call indicator after hanging up to confirm the call actually ended.

The fix makes call termination requests independent of the FSM event queue, so they are detected and handled without waiting behind queued events.

Caveats

• Details and a conceptual PoC were published on a Tuesday after the fix, and NIST added the CVE to the NVD the same day. The page does not report exploitation in the wild.
• The page says the camera is only "possibly" affected.
• The page does not say which Signal app versions bundle RingRTC 2.72.0, so check the app's release notes.