CVE-2026-113380 is scored 9.3 on CVSS v4.0 against RingRTC, the library that runs every Signal call. A peer on the other end can saturate the call's event queue so that when you press hang up, the call does not tear down, and the audio tracks, possibly the video ones too, keep running.

That is an alarming sentence, and this week's coverage has treated it as breaking news. The primary records say something else, and the difference is the story.

The fix shipped on 4 September

RingRTC's tag list puts v2.72.0 at 4 September 2026. The CVE describes every version before 2.72.0 as affected. Two releases have shipped since: v2.72.1 on 30 September and v2.73.0 on 16 October. Signal Desktop's own package manifest pins 2.72.1.

So the patch is seven weeks old, two releases back, and already inside the clients people are running. The CVE was published on 20 October.

What the flaw is

The fix commit is titled "Ensure calls terminate completely in corner cases". It touches twelve files of RingRTC's Rust code, and reading it explains the mechanism better than any advisory would.

Calls are driven by a state machine fed from an event queue, and that queue holds 256 entries. Hanging up injects a Terminate event. If a remote peer has filled the queue first, the Terminate event waits behind the backlog, the state machine never reaches it, and the teardown that stops the media tracks never happens.

The fix does two things. It adds a termination flag that the state machine checks after every single event it handles, so a hangup is processed out of band rather than queued behind whatever the other side sent. And it caps the wait on teardown at five seconds with a new timeout error, so a call that will not terminate cleanly stops waiting and tears down anyway.

Signal has not said anything about it

RingRTC's security advisories page says "There aren't any published security advisories". Its releases page says "There aren't any releases here". Signal's blog has published nothing since 28 September, and that post is about backups.

The CVE was not assigned by Signal either. The record names MITRE as the assigning authority, and it was reserved and published inside the same second on 20 October, which is not what a coordinated embargo looks like. Of its three references, two are the fix commit and the version comparison. The third is a personal notes repository belonging to an individual.

Read together, that is the signature of somebody outside the project reading a commit, recognising what it fixed, and filing a CVE for it six weeks after the fact.

Where the 9.3 comes from

The vector is AV:N/AC:L/AT:N/PR:N/UI:P/VC:H/VI:H/VA:N/SC:H/SI:N/SA:N/S:P.

Two parts carry the score. UI:P is passive user interaction, meaning you have to be on a call with the attacker for any of this to apply. And S:P sets the CVSS v4.0 Safety metric to Present, a metric added for flaws whose consequence reaches past data into physical or personal harm. Whoever scored this judged that a microphone which does not switch off when its owner believes it has qualifies.

CISA's own enrichment of the record is more restrained: exploitation none, automatable no, technical impact total.

The proof of concept is a queue model

The third reference holds a README and a Python file, and the README describes the file without ambiguity: "The accompanying poc.py demonstrates the pattern safely: a queue model where a flood buries a hang-up event". Then, in the next line, "Purely synthetic, offline, no network, no real calls — no exploit."

The publicly available proof of concept is a simulation of a queue, not a working attack on a Signal client. Coverage implying otherwise has not opened the link.

What to do

  • Update Signal. If you are on a current build you already have this, and that is the honest answer rather than a reassuring one.
  • If you ship a product that embeds RingRTC, check the version you vendored. The notes put the affected population as "every Signal client embedding an older RingRTC build", and third parties move slower than Signal does.
  • Do not read the 9.3 as a measure of urgency by itself. The same vector says the attacker has to be in a call with you.
  • Watch the call screen rather than the score. The user-visible symptom of this class of bug is a call that does not end when you end it.

What is not established

  • Who found it, and whether Signal was told before the fix or after.
  • Why there is no advisory. Signal has not answered that publicly.
  • Whether video behaves the same way as audio. The CVE says possibly, and nobody has shown which.
  • Whether it has ever been exploited. CISA's enrichment records no known exploitation.
  • Which Signal client releases first carried 2.72.0, and therefore how long any individual was exposed.
  • Who requested the CVE from MITRE. The record names no reporter.