Signal RingRTC CVE-2026-113380: Hang-Up Bypass Explained and Fixed

CVE-2026-113380 is a flaw in RingRTC, the calling library inside every Signal app, where a remote peer could fill a call's event queue so a local hang-up never tore the call down, leaving the microphone and possibly the camera live. RingRTC 2.72.0 fixed it on 4 September 2026. Update Signal on every device. There is no known exploitation.

The CVE was published on 20 October 2026, about six weeks after the fix landed, together with a researcher's write-up and a conceptual proof of concept. The people who were not are the ones this post is for: users who postpone app updates, organisations that pin or stage Signal through device management, and engineering teams that embed RingRTC or a similar real-time media stack inside their own products.

This post covers what the public record says, what the fix changes in plain language, which Signal builds carry the fixed library on each platform, how to check the version on every platform with real commands, and what teams that ship real-time media libraries can learn from a bug where "hang up" was treated as a request rather than an order.

What happened

Two things stand out in that table. The fix was public in Signal's open source repositories on 4 September, six weeks before the CVE. And Signal's own release notes for the first fixed builds do not call out a security fix. The Desktop v8.29.0 notes say only "Additional small tweaks, bug fixes, and performance enhancements." We did not find a separate Signal security advisory for this CVE.

What the public record says

The CVE description in NVD is short. In our words: in RingRTC before 2.72.0, a call peer that saturates the call's state machine queue can interfere with a local hang-up, so the call, its audio track and perhaps its video track, is not torn down.

SecurityWeek's summary, published 22 October, adds the researcher's framing. The hang-up was handled as one more event in the call's finite state machine (FSM) queue rather than as a kill switch, there was no rate limit on events originating from the peer, and the hang-up had no priority. SecurityWeek quotes the write-up describing the result as the call "is never torn down". It also notes that Signal resolved the issue by making sure termination requests are no longer blocked in the queue and are detected independently.

The researcher's write-up describes the precondition plainly: the attacker first has to be in a normal Signal call with the target. This is not a way to open someone's microphone without a call. It is a way to keep an existing call alive after the other person believes they have ended it.

Where sources differ

Technical details

Identifiers and scores

Reading the vector without jargon: reachable over the network, low complexity, no special conditions, no privileges, and "passive" user interaction, which fits the need for an established call. High confidentiality impact on the vulnerable system and on a subsequent system, high integrity impact, and the Safety flag set, which reflects that a hidden live microphone can put a person at physical risk.

Fix commit

The fix is in the Rust core that all three Signal platforms share, which is why one library release covered Android, iOS and Desktop.

RingRTC releases

The compare view from v2.71.0 to v2.72.0 contains ten commits. Besides the termination fix, it includes a WebRTC update to the 7871k branch, SVC configuration validation, call link root key redaction and new stats. If you embed RingRTC and want the smallest possible change, you still have to take the whole release, because the fix was not shipped as a standalone patch release.

npm package integrity

For teams that consume the Node package, these are the registry values. Your lockfile should match them.

The package license is AGPL-3.0-only on all of these versions, which is worth knowing before you embed it in anything you distribute.

Affected and fixed Signal builds per platform

Signal has not published a per-platform list of fixed app versions for this CVE. The table below is built from the RingRTC version that each public source tag of the Signal apps pins. App store availability can lag the tag by days, and staged rollouts mean not every device gets a build on the same day.

The safe rule is simple: Signal Desktop 8.29.0 or later, Signal Android 8.27.0 or later, and Signal iOS 8.30.0 or later carry a fixed RingRTC according to the source tags. In practice, install whatever the latest build is on each device, since later builds also carry RingRTC 2.72.1 and 2.73.0.

One detail for iOS deserves attention. The iOS main branch moved to RingRTC v2.72.0 on 9 September, but the 8.29.0 release tag, cut on 15 September, still pinned v2.71.0. Release branches are cut earlier than their tags. So a version number that is later in time is not proof of a fix; the pin is.

The class of bug, conceptually

RingRTC drives each call with a state machine. Events such as "remote sent an offer", "ICE connected", "received data from the peer" and "local user hung up" go into a channel and a worker thread handles them one at a time. That design is sound for keeping the call's state consistent. The problem is what happens when one producer of events is untrusted and another producer is the user's intent to stop.

Before the fix, a local hang-up set the call to "terminating", added a Terminate event to the same queue as everything else, and then waited for the worker to finish. If the queue was saturated with peer driven work, the termination request had to wait its turn, and the code that released media was behind it. The CWE label fits: the code did not check for the unusual condition where the queue never drained in a reasonable time.

The fix, as we read the commit, changes three things.

1. Out of band termination. A new terminate_requested flag is set as soon as the user hangs up. After every event the worker handles, it checks this flag and starts termination immediately if it is set. The commit comment describes this as termination "independent of queue depth". The user's intent no longer waits behind the queue.
2. Bounded waiting. A new TERMINATE_TIMEOUT constant of five seconds limits how long teardown waits for the state machine to quiesce. If it does not, teardown continues anyway and a TerminateTimeout error is logged. The commit also gives the existing queue bound a name, EVENT_QUEUE_SIZE, set to 256.
3. Teardown that keeps going. Steps such as trimming queued messages, notifying the app that the call ended, sending hang-up messages to the peer and dropping the call object used to stop at the first error. Now each step logs its error and the teardown continues, so one failure cannot leave media running.

The same approach is applied to the per-connection state machine in connection.rs and connection_fsm.rs, and the new tests use a simulation-only Pause event to hold the state machine still and prove that termination still completes.

We are not publishing reproduction steps, and the write-up's proof of concept is a synthetic offline model rather than a working exploit. Nothing in this section is needed to defend against the bug beyond updating.

Indicators of compromise

None have been published. Signal, NVD, CISA's SSVC entry and SecurityWeek report no exploitation, and no source lists network indicators, hashes or behavioural signatures. If you are worried about a specific call, the practical check is on the device: confirm the call screen and the operating system's microphone indicator are gone after hanging up.

How it works, in plain language

Think of a call as a desk clerk working through an inbox. Every message from the other caller goes into the inbox. When you press the red button, your "end the call" note goes into the same inbox, at the bottom. If the other side keeps the inbox full, the clerk is always busy with their paper, and your note does not get read in time. Meanwhile, the microphone stays on.

The fix gives your note a separate path. Pressing hang-up now raises a flag the clerk checks after every single item, no matter how full the inbox is. And if the clerk still does not finish within five seconds, the building turns the lights off anyway.

That framing explains why the CVSS score is high even though the attacker must already be in a call with you. A hang-up is a security control. People rely on it to decide when it is safe to talk. A control that a remote party can delay breaks that trust in the most personal way possible.

How this compares with WebRTC's own model

RingRTC is built on WebRTC, and the W3C WebRTC Recommendation is a useful reference for how teardown should behave. The spec gives each RTCPeerConnection an "operations chain" so that asynchronous operations such as creating offers run one at a time. But close() does not join that chain. When the method is invoked, the user agent runs the close steps right away: mark the connection closed, set the signaling state to closed, stop transceivers. The design intent is that stopping should not wait behind other work.

The W3C Media Capture and Streams specification makes a related point about devices. It describes aligning the physical camera and microphone lights with the logical privacy indicators, and it encourages authors to call stop() on capture tracks because of the effect on what the user sees. In other words, the spec treats "is the device still capturing" as something the user must be able to trust.

RFC 8826, the IETF's security considerations for WebRTC, frames consent the same way: users must understand where their camera and microphone input is going. A hang-up that does not stop media inverts that model: consent has ended and the media still flows. RingRTC implements its own call model beneath these APIs, but the shape of the right answer is the same: termination is a priority path, not a queued request.

Who is affected

Third party apps and forks that bundle RingRTC inherit the bug until they update. If you use an unofficial Signal client, check whether its maintainers have moved to RingRTC 2.72.0 or later.

What to do now

1. Update every Signal install

The fastest action for nearly everyone is to update Signal on every device, including tablets and linked desktops that you use rarely. A linked desktop that has sat closed for a month is exactly where an old build survives.

2. Check the version on each platform

Android, on the device. Open Signal, tap your profile picture, then Help. The version is shown on that screen. You can also open Android Settings, then Apps, then Signal, and scroll to the version.

Android, from a workstation (useful for fleets and test devices):

# Signal's Android package name is org.thoughtcrime.securesms
adb shell dumpsys package org.thoughtcrime.securesms | grep -E 'versionName|versionCode'

You want versionName 8.27.0 or later, and ideally the latest available.

iOS, on the device. Open Signal, tap your profile picture to open Settings, then Help. The version is listed there. You can also open the App Store, tap your account picture and pull to refresh pending updates.

iOS, at fleet scale. Your MDM's installed application inventory reports the Signal version for each managed device. Filter for versions below 8.30.0.

Desktop on macOS:

defaults read /Applications/Signal.app/Contents/Info.plist CFBundleShortVersionString

Desktop on Windows (PowerShell; Signal installs per user by default):

(Get-Item "$env:LOCALAPPDATA\Programs\signal-desktop\Signal.exe").VersionInfo.ProductVersion

Desktop on Debian or Ubuntu (official apt repository):

dpkg -s signal-desktop | grep '^Version'
apt-cache policy signal-desktop

On any desktop platform you can also open Help, then About (on macOS, Signal, then About Signal). You want 8.29.0 or later.

3. If you manage devices, close the loop

1. Pull the installed Signal version from your MDM or endpoint inventory for every enrolled device.
2. Flag Android below 8.27.0, iOS below 8.30.0 and Desktop below 8.29.0.
3. Push the update or require it through your app update policy.
4. Recheck in 48 hours. Staged rollouts and devices that were offline will show up in the second pass.
5. For people who handle sensitive conversations, add a short note: after ending a call, confirm the call screen is gone and the system microphone indicator is off. On iOS and recent Android versions this is a small coloured dot or icon near the status bar; on macOS it is in the menu bar.

4. If you embed RingRTC, find every copy

RingRTC ships through three channels: npm for Desktop and Electron apps, Maven for Android, and a CocoaPods pod pinned to a git tag for iOS. Search all three.

# Node and Electron projects
npm ls @signalapp/ringrtc
pnpm why @signalapp/ringrtc
yarn why @signalapp/ringrtc

# Confirm the registry values for the version you are moving to
npm view @signalapp/ringrtc@2.72.1 dist.integrity dist.shasum

# Android (Gradle)
./gradlew :app:dependencies --configuration releaseRuntimeClasspath | grep -i ringrtc
grep -rn "ringrtc" gradle/libs.versions.toml build.gradle* app/build.gradle* 2>/dev/null

# iOS (CocoaPods)
grep -n "SignalRingRTC" Podfile Podfile.lock

# List upstream tags to confirm the one you pin exists
git ls-remote --tags https://github.com/signalapp/ringrtc | grep -E 'v2\.7[2-9]'

Then upgrade. We suggest 2.72.1 or later rather than exactly 2.72.0, since 2.72.1 includes a follow-up change to the termination path.

npm install @signalapp/ringrtc@2.72.1 --save-exact

For Gradle, update the version in your catalog or build file, for example org.signal:ringrtc-android:2.72.1. For CocoaPods, change the tag in your Podfile to v2.72.1 or later and run pod install. Signal's own Podfile also sets a RINGRTC_PREBUILD_CHECKSUM environment value for the prebuilt library, so update that alongside the tag if you follow the same pattern.

5. Rebuild, retest, redistribute

Updating the dependency is not the fix until the new build reaches users. For Electron apps, cut a release and confirm your auto updater picks it up. For mobile apps, submit the build and watch the staged rollout percentage. Add a test that hangs up during a busy call and asserts that media stops. The RingRTC commit's new tests in tests/outgoing.rs are a good model of the shape: pause the state machine, request termination, and assert the call still ends.

What would have helped

This section is for teams that build products with real-time media: telehealth, customer support calling, collaboration tools, in-app voice, and any Electron or mobile app that embeds a calling library. The lessons apply whether you use RingRTC, raw WebRTC or a vendor SDK.

Treat termination as a security control

Give stop a separate path. Hang-up, mute, camera off and screen share stop are user safety controls. They should never sit in the same queue as events that a remote party can generate. A flag checked between every event, a dedicated high priority channel, or a direct call into the media layer are all reasonable designs. The RingRTC fix uses the first one.

Put a deadline on graceful shutdown. A clean teardown is nice. A guaranteed teardown is required. Wrap the graceful path in a timeout and force media off when it expires. Log the timeout so you find out it happened.

Make teardown keep going after errors. If step two of six fails, steps three to six still need to run. The RingRTC change from "return on first error" to "log and continue" is a pattern worth copying anywhere cleanup must finish.

Stop the capture source, not only the network path. Closing a peer connection and stopping the local capture track are separate operations. Make sure the hang-up path stops the microphone and camera tracks themselves, so the operating system indicator turns off even if network teardown is slow.

Bound and meter peer driven work. RingRTC already bounded its queue at 256. Consider rate limits or budgets for peer originated events, so a misbehaving peer cannot keep a worker permanently busy, and alert when a call hits the limit.

Test adversarial peers. Most call tests use well behaved peers. Add a simulated peer that floods events, sends malformed messages or stops responding, and assert three things: the local user can always end the call, media stops within your deadline, and the operating system indicator goes off.

Know where the media library lives in your products

Inventory the library across ecosystems. RingRTC alone ships through npm, Maven and a CocoaPods git tag. A component like this can sit in a desktop app, two mobile apps and a test harness, each pinned separately. An SBOM for every shipped artifact, not just for the backend, is what lets you answer "do we ship RingRTC below 2.72.0?" in minutes. Our post on using SBOMs to find affected products fast walks through that workflow.

Watch upstream commits, not just CVE feeds. The fix here was public for six weeks before the CVE. A team that tracked RingRTC releases and upgraded within days was protected long before the news. A monthly dependency update window, plus a quick read of each upstream changelog for words like "terminate", "lifetime", "mutex" or "redaction", catches many of these quiet security fixes.

Pin by version and integrity, and check the pin, not the date. The iOS case shows a later app version can still pin the old library. Check the resolved version in the lockfile, the Gradle dependency tree or Podfile.lock, not the calendar.

Where Safeguard fits

Safeguard does not change how Signal or RingRTC behave, and nothing here would have prevented the bug. What it helps with is the embedder's problem: knowing which of your products carry a vulnerable component and moving them to the fixed version quickly.

• Inventory and matching. Safeguard scans repositories, container images and SBOM files (safeguard scan --dir ., safeguard scan --image <name>, safeguard scan --sbom <file>, with JSON results under ./output) and matches components against vulnerability databases. Its documented dependency coverage includes npm, Maven and Gradle, and Cargo, which covers the Node and Android routes for RingRTC. The platform shows which projects contain a given component and version, so "who ships @signalapp/ringrtc below 2.72.0" becomes a query. A CocoaPods pod pinned to a git tag in a Podfile is not in that documented list, so check iOS pins by hand with the grep above.
• Prioritisation. Reachability analysis helps rank findings by whether your code calls the vulnerable paths. For a calling library, any app that places calls reaches the call state machine, so expect this one near the top.
• Policies and gates. A policy can fail a build that resolves @signalapp/ringrtc below 2.72.0, so the old version cannot come back through a stale branch.
• Fixes with approval. The Safeguard CLI's assistant can edit the dependency pin, run the install and the tests, and ask before each command. Autonomous remediation can open fix pull requests, and ships switched off by default.
• License visibility. License compliance checks flag copyleft licenses such as AGPL in what you ship.

Where Safeguard does not help: it cannot update the Signal app on a user's phone, it does not see what an app store has rolled out, and it cannot tell whether a particular call was affected. Those remain jobs for device management and for the people on the call.

Zero-Day Discovery and Gold

Safeguard's Zero-Day Discovery looks for previously unknown flaws before a CVE exists, in an agentic mode and a deterministic scanner mode, and issues findings as SGZ advisories before they reach public CVE databases. It covers seven package ecosystems. RingRTC was found and fixed by its own maintainers and reported publicly by an independent researcher.

Gold Open Source at gold.safeguard.sh is free and needs no login; it shows CVSS, EPSS, KEV status, affected and fixed versions and a recommended safe version for a CVE, through the site, a free read API and a CI gate GitHub Action. We have not confirmed that it holds a record for CVE-2026-113380 at the time of writing, so check the site rather than relying on this post. Gold Registry at registry.safeguard.sh provides hardened, signed components held to zero exploitable critical or high CVEs; we make no claim that it carries a RingRTC build. The habit worth taking from both is the same one this incident rewards: pull patched, signed components from a curated source and rebuild fast.

Common mistakes

Assuming a version that came out later is fixed. The iOS 8.29.0 tag was cut after RingRTC 2.72.0 existed and still pinned 2.71.0. Check the pinned library, or use the per-platform minimums above.

Updating the phone and forgetting the desktop. Linked Signal Desktop installs update on their own schedule. A laptop that was closed for weeks may still be on a build from August.

Treating the CVE date as the exposure window. Builds older than early September were vulnerable for as long as they were in use. The 20 October date is when the bug became public, not when it began.

Reading 9.3 as an NVD verdict. The score shown on NVD comes from the assigner. NVD's own analysis is pending. The score may change.

Open questions

• NVD has not completed its own analysis. Its score and CWE may differ from the assigner's when it does.
• Signal has not published an advisory or per-platform fixed version list. The minimum versions above come from public source tags, not a Signal statement.
• How long a hang-up could be delayed in practice, and whether the video track stayed live in video calls, are not documented in a primary source we could read.
• App store release dates for the first fixed iOS and Android builds are not public in the sources we used; the dates above are tag and GitHub release dates.

FAQ

Is CVE-2026-113380 being exploited?

No exploitation is known. CISA's SSVC enrichment on the NVD record lists exploitation as "none" as of 20 October 2026, and neither Signal nor SecurityWeek reports attacks. The published proof of concept is described by its author as a synthetic, offline model rather than a working exploit.

Could someone turn on my microphone without calling me?

Not with this bug. The researcher's write-up says the attacker must first be in a normal Signal call with you. The flaw is about a call that should have ended staying alive, not about starting a call silently.

Which Signal version do I need?

Based on the RingRTC version each public source tag pins: Desktop 8.29.0 or later, Android 8.27.0 or later, iOS 8.30.0 or later. The simplest answer is to install the latest version on every device.

Is CVSS 9.3 the official NVD score?

It is the CVSS 4.0 score supplied by the CVE's assigner and displayed on NVD. NVD's own analysis status is "Awaiting Analysis", so NVD has not produced a separate score yet.

Why did the CVE appear six weeks after the fix?

The fix shipped in RingRTC 2.72.0 on 4 September and moved into Signal builds in September and early October. The CVE and the write-up came on 20 October. Signal did not label the fix as a security change in its release notes, which is common when a maintainer fixes a bug quietly before a CVE is assigned.

I build an app on RingRTC. What exactly should I change?

Upgrade @signalapp/ringrtc, org.signal:ringrtc-android or the SignalRingRTC pod to 2.72.0 or later; we suggest 2.72.1 or later for the follow-up termination change. Rebuild, run your call tests, and ship. Then add a test that ends a call while the peer is busy.

I use WebRTC directly, not RingRTC. Am I affected?

Not by this CVE. But the class of bug is general. If your app's hang-up goes through the same queue as peer events, a busy or hostile peer can delay it. Review your teardown path against the checklist in "What would have helped".

Did Safeguard find this vulnerability?

No. RingRTC's maintainers fixed it, and an independent researcher published the details. Safeguard's role for embedders is finding which products carry the vulnerable version and helping move them to the fixed one.

Fix it without waiting for upstream

In this case upstream moved fast, and the fix was public six weeks before the CVE. The gap that remained was on the embedder side: getting a fixed library into every shipped build. The same thinking applies to any component you ship.

Whatever the vulnerability, most of the risk sits in two gaps. The first is the time between a fix being published and that fix actually running in your production builds. The second, and worse, is the time before any fix exists at all, while a maintainer works out a patch and a release schedule. Waiting through both gaps is a habit, not a requirement. Safeguard gives teams three ways to close them.

1. Autonomous remediation: pull requests, not tickets

When a fixed version exists, Safeguard's Griffin models open a tested, policy gated pull request that moves the affected dependency to the safe version. You can run it on one repository or in bulk across every project that carries the vulnerable version. Remediation covers eight categories, including dependencies, licenses, security posture and findings. Reachability analysis ranks the vulnerable code paths your application actually calls first, so the first pull requests you merge are the ones that matter most. Autonomous remediation ships switched off, with every category set to Manual, so your team decides how much runs on its own and what still needs a human approval.

2. Gold Open Source: the safe version in seconds, free

gold.safeguard.sh is free and needs no login. Search any CVE or package to see affected and fixed versions, CVSS, EPSS, CISA KEV status and a recommended safe version, or use the "Am I affected?" checker. The same data is available through a free read API, README status badges and RSS threat feeds. The safeguard-sh/gold-scan-action GitHub Action can fail a build on a known exploited vulnerability, on any known vulnerability, or never, so a version you have just removed cannot quietly come back in next week's merge.

3. Gold Registry: start from components that are already fixed

registry.safeguard.sh provides hardened, drop in replacements for upstream packages and container images. Every Gold artifact is held continuously to zero exploitable critical or high CVEs, zero malware and a completed license check, with SLSA L3 or higher provenance, a Sigstore signature and a public evidence page you can hand to an auditor. An artifact loses its Gold badge if it regresses. Teams can point their own package directory at the registry so hardened equivalents resolve without changing how developers install anything.

When upstream has no fix yet, or will not ship one, Safeguard first works to get the fix accepted upstream. If the issue is severe or upstream will not move, Safeguard builds a fork, fixes the vulnerability there and publishes a hardened Gold build, so you are not stuck on a maintainer's release schedule. You can also request a hardened, compatibility tested build of a specific package. This fork and patch flow is in early access today, so ask which packages it covers before you plan around it.

One honest limit: when the vulnerable code lives in a vendor appliance, a hosted service or an operating system runtime you do not build yourself, the fix still has to come from that vendor or distribution. The steps above apply to the open source dependencies and container images you build and ship, which is where most teams carry the largest and least tracked share of their exposure.

See how Safeguard would have helped

These are real product sessions on other examples; none of them shows this RingRTC incident.

The CLI demo shows the assistant fixing a lodash CVE: it reads the finding and advisory, asks before each command, edits package.json to lodash 4.17.21, runs npm install and npm test with approval, and pushes nothing. For CVE-2026-113380 in an Electron app, the same flow applies: ask it to move @signalapp/ringrtc to 2.72.1 or later, approve the install, then approve your call tests before anything is committed.

Click through it at your own pace, or open it full screen.

The desktop app demo shows a CLI session in the conversation list, a request for work on the computer, a folder choice, and Approve or Deny on each command and file edit, ending with an upgrade done and tests passing. Here you would pick your Android app's folder, ask for the org.signal:ringrtc-android bump in the version catalog, and approve the Gradle build and test commands one by one.

Click through it at your own pace, or open it full screen.

The mobile app demo shows a real Android session sending work to a computer running the CLI and approving a command on the phone with Allow once, Allow for turn or Deny. For a library bump like this one, that means the engineer on call can approve the dependency install and test run from a phone, without waiting to get back to a laptop.

Click through it at your own pace, or open it full screen.

To try it on your own projects, download Safeguard and read the CLI documentation. For more on how the assistant asks before acting, see the Safeguard CLI as a security aware coding assistant, and for other incidents this month, our October 2026 roundup.

Quick check

Sources

• NVD: CVE-2026-113380
• NVD API record for CVE-2026-113380
• RingRTC fix commit 4b1b6fa
• RingRTC compare v2.71.0 to v2.72.0
• RingRTC tags
• RingRTC CHANGELOG.md at v2.73.0
• npm: @signalapp/ringrtc
• Signal Desktop releases
• Signal Desktop v8.29.0 release
• Signal Desktop package.json at v8.29.0
• Signal Android releases
• Signal Android libs.versions.toml at v8.27.0
• Signal iOS tags
• Signal iOS Podfile at 8.30.0.1882
• W3C: WebRTC: Real-Time Communication in Browsers
• W3C: Media Capture and Streams
• IETF RFC 8826: Security Considerations for WebRTC
• SecurityWeek: Signal vulnerability lets malicious callers block hang-ups

Last reviewed: 23 October 2026. This is a developing story; check the linked advisories for the latest status.