← Back to Feed CACHED · 2026-10-20 14:14:37 · CACHE_KEY CVE-2026-113380
CVE-2026-113380 · CWE-754 · Disclosed 2026-10-20

Signal RingRTC call FSM queue saturation prevents local hangup teardown

ASSESSED — NOISGATE
Vendor
—
—
—
Reassessed
—
—
—
Verdict: —
Do you agree?
01 · The Real Story

Like a phone booth whose hang-up lever is jammed — annoying, but you can still walk away

CVE-2026-113380 affects the RingRTC WebRTC calling library bundled inside all Signal clients (Desktop, Android, iOS) prior to version 2.72.0. The finite-state machine (FSM) governing call lifecycle uses a bounded event queue (capacity 256). A malicious call peer can flood this queue with crafted signaling events, creating a backlog that starves the local Hangup command. Because the original design routed termination through the same saturated queue, the local user's attempt to end the call blocks indefinitely — audio and potentially video tracks remain active even after the user presses "End Call." The fix in 2.72.0 (commit 4b1b6fa) adds an out-of-band terminate_requested atomic flag that the FSM checks after every event, plus a hard 5-second TERMINATE_TIMEOUT so calls self-destruct if the queue cannot drain.

Several third-party scanners have auto-scored this at CVSS 4.0: 9.3 CRITICAL with a vector claiming High confidentiality and integrity impact — a rating that is wildly disconnected from reality. There is no code execution, no privilege escalation, no data modification, and no lateral movement. The sole impact is that audio/video already being shared during a consented call continues streaming for slightly longer than the user intended. The user can force-quit the application at any time, instantly severing all media tracks. Signal is a consumer messaging app, not enterprise infrastructure. No official vendor or NVD CVSS score exists; the 9.3 is purely algorithmic inflation from automated platforms that mapped 'continued media streaming' to 'High confidentiality breach.'

"Consumer app call-hangup DoS -- force-quit is the workaround, auto-update is the fix"
02 · The Attack Path

3 steps from start to impact.

STEP 01

Attacker establishes Signal call with victim

The attacker must be a Signal user known to (or socially engineering) the victim. The victim must actively accept an incoming voice or video call. Until the call is answered, there is no attack surface — the FSM queue only processes events for active calls.
Conditions required:
  • Attacker has a Signal account
  • Victim accepts the incoming call
Where this breaks in practice:
  • Enterprise users rarely accept Signal calls from unknown contacts
  • Many organizations block or do not deploy Signal on managed endpoints
  • On mobile, call screening (Android/iOS) may reject unknown callers
STEP 02

Attacker floods FSM event queue with signaling messages

Once the call is active, the attacker sends a burst of crafted call-signaling events (ICE candidates, offer/answer re-negotiations, or other RingRTC protocol messages) at a rate that fills the 256-slot bounded queue. No special tooling exists publicly; the attacker would need to instrument a modified Signal client or RingRTC fork to generate the flood.
Conditions required:
  • Active call session established
  • Knowledge of RingRTC signaling protocol internals
  • Modified client capable of high-rate event injection
Where this breaks in practice:
  • No public PoC or tooling exists
  • Requires reverse-engineering RingRTC's Rust-based FSM event protocol
  • Signal's server-side relay (SFU) may rate-limit or drop malformed signaling
  • WebRTC ICE/DTLS layer imposes its own flow control
STEP 03

Victim's hangup command is starved

When the victim taps 'End Call,' the local Hangup event is enqueued behind the flood. Because inject_event() on a full queue blocks the calling thread, the UI thread stalls or the hangup event is never processed. Audio (and possibly video) tracks remain open, continuing to stream to the attacker.
Conditions required:
  • Queue must be saturated at the moment hangup is attempted
  • Victim has not force-quit the application
Where this breaks in practice:
  • User can force-quit Signal at any time (swipe-kill on mobile, Alt-F4/Cmd-Q on desktop), instantly terminating all media tracks
  • OS-level audio/video indicators (green dot on iOS, mic icon on Android/Windows) alert the user that media is still active
  • Call duration timers and UI state would look anomalous, prompting the user to close the app
Detection/coverage: OS-level microphone/camera activity indicators provide real-time visual cues to the user
03 · Compensating Control

1
LOW 3.1→IGNORE 0.0
SEVERITY REDUCED
Ensure Signal auto-updates are not blocked by endpoint policy — Signal Desktop, Android, and iOS all auto-update by default. The most common enterprise failure mode is a proxy, firewall, or software restriction policy that blocks updates2.signal.org. Verify that auto-update endpoints are allowlisted. No mitigation SLA applies at LOW severity — this is backlog hygiene. If your org actively manages Signal, confirm the update has landed within the next routine audit cycle.
2
LOW 3.1→IGNORE 0.0
SEVERITY REDUCED
Educate users: force-quit Signal if a call won't end — A one-line addition to your security awareness channel: 'If a Signal call won't hang up, force-close the app.' This eliminates the entire attack impact by severing media tracks at the OS level. On iOS, swipe up from the app switcher. On Android, force-stop from Settings or swipe. On Desktop, Ctrl+Q / Cmd+Q / Alt+F4. This costs nothing and is effective immediately.
3
LOW 3.1→IGNORE 0.0
SEVERITY REDUCED
Use MDM to enforce minimum Signal version if Signal is in your managed catalog — If your organization distributes Signal via MDM (Intune, Jamf, Workspace ONE), set a minimum required version that ships RingRTC ≥ 2.72.0. This ensures stragglers on older versions are prompted or forced to update. Only relevant if Signal is in your managed app catalog — most enterprises do not manage Signal centrally.
What doesn't work
  • Network-level blocking of Signal calling (TURN/STUN): While blocking Signal's relay servers would prevent calls entirely, it also breaks all legitimate Signal voice/video functionality. This is a business decision, not a compensating control for this specific CVE.
  • WAF / IDS / IPS rules: This is a client-side vulnerability in a peer-to-peer call. There is no server-side attack surface, no HTTP request to inspect, and no network signature to detect. Network security tools have zero visibility into this attack path.
  • EDR behavioral detection: The 'attack' is normal-looking WebRTC signaling traffic processed by Signal's own library. No malicious process spawning, no file writes, no registry changes, no anomalous system calls. EDR has nothing to alert on.
04 · Intelligence Metadata

The supporting signals.

In-the-wild exploitationNone observed. Not listed in CISA KEV. No campaigns, no threat actor attribution, no vendor emergency advisory.
Proof-of-concept availabilityNone public. Checked pocindex.io, GitHub (CVE-2026-113380), ExploitDB, and Nuclei templates — zero results. Exploitation requires a custom-instrumented RingRTC client; no off-the-shelf tooling exists.
EPSS scoreNot yet scored — CVE disclosed 2026-10-20 (today). FIRST EPSS model has not ingested this CVE. Given the consumer-app context and DoS-only impact, expect a low percentile once scored.
CISA KEV statusNot listed as of 2026-10-20.
Third-party CVSS (automated)CVSS 4.0: 9.3 via strix.ai — vector CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:P/VC:H/VI:H/VA:N/SC:H/SI:N/SA:N. This is an automated score, not a vendor or NVD assessment. The C:H and I:H ratings are unsupported by the actual impact (no data theft, no data modification).
Realistic CVSS 3.1 estimate~4.0 — CVSS:3.1/AV:N/AC:H/PR:N/UI:R/S:U/C:L/I:N/A:L. AC:H because active call + queue saturation timing is required. C:L for continued audio leakage of already-shared content. A:L for hangup disruption with trivial workaround.
Affected versionsRingRTC < 2.72.0 (all prior versions). Bundled in Signal Desktop, Signal Android, Signal iOS.
Fixed versionRingRTC 2.72.0 — commit 4b1b6fa. Fix adds out-of-band termination flag + 5-second hard timeout.
Scanning / exposure surfaceNot externally scannable. RingRTC is a client-side library embedded in Signal apps. No server, no listening port, no Shodan/Censys/GreyNoise footprint. Attack requires an active call session, not a network scan.
Signal install base~70–100M monthly active users globally (Business of Apps). Overwhelmingly consumer/BYOD. Enterprise-managed Signal deployments are rare; most organizations do not include Signal in their managed software catalog.

Sources.

  1. NVD / CVE Record — CVE-2026-113380
  2. VulDB Advisory — RingRTC FSM queue resource consumption
  3. Strix.ai — CVE-2026-113380 CVSS 4.0 scoring detail
  4. GitHub — RingRTC fix commit 4b1b6fa ("Ensure calls terminate completely in corner cases")
  5. GitHub — RingRTC v2.71.0…v2.72.0 comparison
  6. GitHub — RingRTC CHANGELOG.md
  7. Signal Desktop auto-update issue discussion
  8. OffSeq Radar — CVE-2026-113380 threat analysis
05 · The Call

Final Verdict
= UNCHANGED to LOW (3.1/10)

Why this verdict

  • Trivial user workaround eliminates the impact: Force-quitting Signal (swipe-kill, Alt-F4, task kill) instantly severs all media tracks. The vulnerability only delays termination through the in-app UI — it does not prevent the user from ending media transmission. This caps real-world impact well below any 'High' threshold.
  • Consumer app, not enterprise infrastructure: Signal is an end-user messaging application. It is not a network edge appliance, identity provider, hypervisor, CI/CD system, database, backup tool, or kernel-mode agent. It runs in user-space with no elevated privileges. A bug in Signal's call state machine has zero blast radius beyond the Signal process itself.
  • Role multiplier: no high-value role applies. RingRTC is a client-side WebRTC library inside a consumer chat app. It does not run on domain controllers, does not process fleet-wide authentication, does not store secrets, and does not sit on network perimeters. Even if Signal is installed on a high-value host, this CVE cannot escalate beyond Signal's own process — no RCE, no privilege escalation, no lateral movement. The deployment-role floor check finds no applicable high-value role that would raise the floor above LOW.
  • Attack requires active victim participation: The victim must answer a call from the attacker. In enterprise contexts, this implies social engineering of a specific user on a specific app that most enterprises don't manage or mandate. This is not a spray-and-pray vulnerability.
  • No PoC, no exploitation, no tooling: Zero public exploit code. Weaponization requires reverse-engineering RingRTC's Rust FSM protocol and building a custom flooding client. The effort-to-impact ratio is extremely unfavorable for attackers when the payoff is 'victim's mic stays on a few seconds longer.'
  • Auto-update neutralizes the risk at scale: Signal Desktop, Android, and iOS clients auto-update by default. Most of the ~100M install base will receive the fix without any manual intervention, and certainly without enterprise patch management involvement.

Why not higher?

Upgrading this to MEDIUM or above would require either (a) code execution or privilege escalation, (b) impact on enterprise-critical infrastructure, or (c) a realistic path to data exfiltration beyond what the call already shares. None of these apply. The vulnerability is a localized DoS against a single UI function in a consumer app, with a trivial out-of-band workaround. The third-party CVSS 4.0 score of 9.3 is an artifact of automated scoring that incorrectly mapped 'continued audio streaming' to 'High confidentiality impact' — the audio was already being shared consensually during the call.

Why not lower?

IGNORE would be appropriate if there were zero security-relevant impact. The privacy angle — that a user who believes they've hung up may continue transmitting audio/video — is a genuine, if bounded, concern. For high-risk Signal users (journalists, government officials, activists), even a brief period of unintended audio transmission could matter. The vulnerability is also mechanically real and required a non-trivial code fix (out-of-band termination + timeout). It earns LOW rather than IGNORE on the basis of this residual privacy risk.

06 · Verification

Crowdsourced verification payload.

Run on each Windows endpoint where Signal Desktop may be installed. Requires no elevation — reads from the current user's %LOCALAPPDATA% path. Invoke as: powershell -ExecutionPolicy Bypass -File .\Check-RingRTC-CVE2026113380.ps1

noisgate-verify.ps1
POWERSHELLREAD-ONLYSAFE
#!/usr/bin/env pwsh
# Check-RingRTC-CVE2026113380.ps1
# Checks whether Signal Desktop is installed and whether its version
# is likely to bundle a patched RingRTC (>= 2.72.0).
# Exit codes: 1 = VULNERABLE, 0 = PATCHED, 2 = UNKNOWN

$ErrorActionPreference = 'SilentlyContinue'

# Signal Desktop default install paths
$candidates = @(
    "$env:LOCALAPPDATA\Programs\signal-desktop\Signal.exe",
    "$env:LOCALAPPDATA\signal-desktop\Signal.exe",
    "${env:ProgramFiles}\Signal\Signal.exe",
    "${env:ProgramFiles(x86)}\Signal\Signal.exe"
)

$signalExe = $null
foreach ($p in $candidates) {
    if (Test-Path $p) { $signalExe = $p; break }
}

if (-not $signalExe) {
    Write-Host "UNKNOWN - Signal Desktop not found on this host."
    exit 2
}

$version = (Get-Item $signalExe).VersionInfo.ProductVersion
if (-not $version) {
    Write-Host "UNKNOWN - Signal Desktop found at $signalExe but could not read version."
    exit 2
}

Write-Host "Signal Desktop version: $version (at $signalExe)"

# RingRTC 2.72.0 shipped with Signal Desktop ~7.30+.
# We check for the ringrtc native module timestamp as a secondary signal.
$resourceBase = Split-Path $signalExe
$ringrtcPaths = @(
    (Join-Path $resourceBase 'resources\app.asar.unpacked\node_modules\@aspect\ringrtc'),
    (Join-Path $resourceBase 'resources\app.asar.unpacked\node_modules\@aspect\signal-ringrtc-node'),
    (Join-Path $resourceBase 'resources\app.asar.unpacked\node_modules\ringrtc')
)

$foundRingrtc = $false
foreach ($rp in $ringrtcPaths) {
    if (Test-Path $rp) {
        $foundRingrtc = $true
        $pkgJson = Join-Path $rp 'package.json'
        if (Test-Path $pkgJson) {
            $pkg = Get-Content $pkgJson -Raw | ConvertFrom-Json
            $rtcVer = $pkg.version
            if ($rtcVer) {
                Write-Host "RingRTC version: $rtcVer"
                $parts = $rtcVer.Split('.')
                $major = [int]$parts[0]
                $minor = [int]$parts[1]
                if (($major -gt 2) -or ($major -eq 2 -and $minor -ge 72)) {
                    Write-Host "PATCHED - RingRTC $rtcVer >= 2.72.0. CVE-2026-113380 is fixed."
                    exit 0
                } else {
                    Write-Host "VULNERABLE - RingRTC $rtcVer < 2.72.0. CVE-2026-113380 applies."
                    exit 1
                }
            }
        }
        break
    }
}

if (-not $foundRingrtc) {
    # Fallback: report Signal version and let the operator decide
    Write-Host "UNKNOWN - Could not locate RingRTC module to confirm version."
    Write-Host "Signal Desktop $version is installed. Verify manually that it bundles RingRTC >= 2.72.0."
    exit 2
}