The Call You Thought You Ended: Signal’s RingRTC CVE-2026-113380 Was Fixed 46 Days Before Anyone Was Told

2026-10-23 Agent & Supply Chain Security by al-ice.ai Editorial

On 20 October 2026, MITRE published CVE-2026-113380 against RingRTC, the Rust calling library behind every Signal client. The CVSS v4.0 base score is 9.3, critical. The description is six lines long and describes something most vulnerability records never do: a call that you believe you ended, continuing.

The fix had already shipped forty-six days earlier. There is no vendor advisory. There is no GitHub Security Advisory. There is no OSV record. The npm package that carries the vulnerable code has no machine-readable marker that any version of it was ever unsafe.

The flaw: a hangup that loses a race

NVD's record, sourced from cve@mitre.org and still Awaiting Analysis, states it directly: “In the RingRTC library before 2.72.0 for Signal, a peer that saturates a call's FSM queue can interfere with the ability of a local hangup to tear the call (with its audio and perhaps also video track) down.”

RingRTC drives calls through finite state machines. The other party on the call — someone you already accepted a call with, which is the whole point — floods that machine's event queue. Your hangup is also an event on that queue. If it never gets processed, the UI returns you to the chat list while the media tracks stay up.

The weakness class is CWE-754, improper check for unusual or exceptional conditions. The scoring is worth reading closely, because it explains the 9.3:

AV:N/AC:L/AT:N/PR:N/UI:P — network, low complexity, no privileges, and only passive user interaction. The victim does not click anything hostile; they answer a call and then try to end it.
VC:H/VI:H/VA:N — high confidentiality and integrity impact, no availability impact. Nothing crashes. That is precisely the problem.
SC:H — high subsequent-system confidentiality impact: the compromise reaches past the library into the room it is sitting in.
S:P — the Safety metric is set to Present. In CVSS v4.0 that is reserved for conditions with physical-world consequence, and it is a substantial part of what lifts this record into critical territory.

For an encrypted-messenger user base that includes journalists, their sources, lawyers and activists, a microphone that stays live after the call ends is not an abstract integrity violation. The scoring reflects that, and we think correctly.

The timeline, reconstructed from the repository

We pulled the dates from Git and npm directly rather than from any summary:

4 September 2026, 20:15:36Z — commit 4b1b6fa5, authored by Jim Gustafson, lands in signalapp/ringrtc. Its message is “Ensure calls terminate completely in corner cases.” It touches twelve files, concentrated exactly where the CVE description points: call_fsm.rs, connection_fsm.rs, call.rs, connection.rs and call_manager.rs, plus 154 added lines of tests in tests/outgoing.rs.
4 September 2026, 22:55:10Z — the version bump to v2.72.0, two hours and forty minutes later.
4 September 2026, 23:09:56Z — @signalapp/ringrtc 2.72.0 published to npm.
20 October 2026, 05:16:54Z — NVD publishes CVE-2026-113380, citing that exact commit and the v2.71.0...v2.72.0 comparison as its references. Last modified the same day at 20:06:37Z.

The commit message contains no security language, no CVE reference, and no indication that the “corner cases” include a remotely triggerable failure to stop transmitting audio. A silent fix is a legitimate and common choice for a client-side flaw where disclosure before rollout helps attackers more than users. But the record is what it is: for six and a half weeks, the fix was public in a commit nobody had reason to prioritise.

The missing records

This is where the story stops being about one bug. We checked each of these directly:

The GitHub security-advisories endpoint for signalapp/ringrtc returns an empty array. No GHSA exists.
OSV returns {} for @signalapp/ringrtc in the npm ecosystem — no vulnerability data at all.
The repository publishes no GitHub releases, only tags. There are no release notes in which a security fix could have been flagged.
The CVE was assigned by MITRE, not by Signal, and its third reference is a personal notes repository — the signature of an independent reporter filing through the CNA of last resort rather than a vendor-coordinated disclosure.

So a developer who depends on @signalapp/ringrtc — and the package is public on npm — gets no signal from npm audit, no Dependabot alert, and no OSV match. The one place the vulnerability exists in machine-readable form is NVD, keyed to a package ecosystem most PHP-style SCA pipelines will happily ignore. We traced the identical shape through Brotli's CVE-2026-111497 three days ago: the fix is real, the advisory infrastructure is empty, and every downstream consumer is on their own.

Which clients were actually exposed

The useful question for readers is not “is RingRTC patched” but “when did the patched RingRTC reach my app.” We read the dependency declarations at each release tag:

Signal Desktop v8.28.0 (released 23 September 2026) still declared @signalapp/ringrtc 2.71.0 — vulnerable, nineteen days after the fix was on npm.
Signal Desktop v8.29.0 (1 October 2026) is the first release declaring 2.72.0. That is the fix landing in users' hands twenty-seven days after it was published.
v8.30.0 and v8.31.0 carry 2.72.0 and 2.72.1 respectively; current Desktop main declares 2.72.1.
Signal Android main declares org.signal:ringrtc-android:2.73.0 — also well past the fix.

Current clients on both platforms are fixed. The exposure window was real but is closed for anyone who has updated since early October, which is the overwhelming majority of Signal's install base given its update cadence. The latest RingRTC on npm is 2.73.0, published 16 October 2026.

What to do

Update Signal, on every device, and confirm the version. Desktop should be 8.29.0 or later; anything at 8.28.0 or below predates the fix entirely. Mobile clients auto-update through the app stores, but devices with updates deferred are the ones that matter here.
If you embed RingRTC directly, pin to ≥ 2.72.0. Nothing in your dependency tooling will tell you to — no GHSA, no OSV entry, no npm audit finding. This is a manual pin based on the NVD record and the upstream commit.
Do not rely on the call UI as evidence that a call ended. That is the entire lesson of this CVE: the screen returned to normal while the tracks stayed up. On devices where it matters, the OS-level microphone and camera indicators — the green and orange dots on iOS and Android, the equivalents on macOS and Windows — are the authoritative signal, because they are driven by the platform rather than by the app's own state machine.
For high-risk conversations, close the surface, not just the call. Where the threat model justifies it, ending a sensitive call by quitting the application or disabling the radio removes the dependency on a teardown path completing correctly. That is general hygiene rather than guidance from Signal, and we offer it as such.
Reconsider what “no advisory” means in your intake process. A 9.3 with a Safety-Present vector, in software with a specifically at-risk user base, produced zero alerts in the npm advisory ecosystem. If your vulnerability intake is GHSA- and OSV-driven, this class of record passes straight through it. NVD remains the backstop precisely because it indexes CVEs the vendor never filed.

Verification note: the CVE-2026-113380 description, 2026-10-20T05:16:54 publication and 2026-10-20T20:06:37 last-modified timestamps, Awaiting-Analysis status, cve@mitre.org source, CWE-754 mapping, CVSS v4.0 base score 9.3 and full vector including the Safety:Present metric, the affected range (pkg:npm/@signalapp/ringrtc < 2.72.0) and all three references were retrieved directly from the NVD 2.0 API on 23 October 2026. Commit 4b1b6fa53c9f30c87c8ea78e44675d4a13e1e4d3's author, 2026-09-04T20:15:36Z timestamp, message and complete twelve-file change list with per-file line counts; the v2.72.0, v2.72.1, v2.71.0 and v2.73.0 tag objects and their commit dates; and the empty security-advisories response for signalapp/ringrtc were retrieved from the GitHub API the same day. The npm publication timestamps for 2.70.0 through 2.73.0 and the current latest dist-tag came from the npm registry API. The OSV result is a direct query against the OSV API for @signalapp/ringrtc in the npm ecosystem, which returned an empty object. Signal Desktop's declared RingRTC dependency was read from package.json at tags v8.26.0 through v8.32.0 and at main; Signal Android's from gradle/libs.versions.toml on main; the Desktop release dates from the GitHub releases API. The inference that the FSM-queue saturation path corresponds to the files changed in that commit is our reading of the code's structure against the CVE text, not a statement by Signal, which has published no advisory. The guidance on OS-level indicators and on quitting the app for high-risk calls is our recommendation, not vendor guidance. We did not place, join, or interfere with any Signal call, wrote and ran no exploit or proof of concept, sent no traffic to Signal infrastructure, and contacted no third-party system; all verification was read-only API and repository inspection.

Sources: