← Back to Feed CACHED · 2026-09-12 08:06:34 · CACHE_KEY CVE-2026-84869
CVE-2026-84869 · CWE-269 · Disclosed 2026-09-08

A condition in the ScreenConnect client may

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

Someone found the master key to every door your MSP manages, and it copies itself room to room

CVE-2026-84869 is a missing-authorization flaw in the ConnectWise ScreenConnect client (all versions prior to 26.6.5) that allows files to be transferred *and executed* through an active remote session without the host machine's confirmation or authorization. Because ScreenConnect's client agent typically runs as SYSTEM, successful exploitation yields arbitrary code execution at the highest privilege level on every managed endpoint. The flaw is client-side only — ScreenConnect servers are not directly affected, but they are the conduit through which the exploit is delivered to every connected host.

ConnectWise rated this 9.9 CRITICAL (CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H) and, unusually, that vendor score is *justified*. The PR:L requirement — needing an authenticated ScreenConnect session — might sound like meaningful friction, but Huntress documented a live worm-like campaign in August 2026 where threat actors used social-engineering lures (Quick Assist scams, phishing MSIs) to plant rogue ScreenConnect clients, then weaponized CVE-2026-84869 to auto-propagate a multi-stage VBScript loader across every newly connected host. CISA added it to KEV on September 11 with a federal remediation deadline of September 14, 2026 — a 3-day window that signals maximum urgency.

"KEV-listed RMM client flaw with worm-like propagation — patch or lose the fleet"
02 · The Attack Path

5 steps from start to impact.

STEP 01

Establish ScreenConnect session

The attacker needs operator-level access to a ScreenConnect instance or must trick a victim into installing a rogue ScreenConnect client pointing at attacker-controlled infrastructure. In the observed campaign, initial access was achieved via tech-support scams (Quick Assist abuse), phishing-delivered MSI installers, and fraudulent refund lures. Once the client is installed, a persistent session is established back to the operator.
Conditions required:
  • Victim installs ScreenConnect client or attacker has operator credentials to existing ScreenConnect server
  • ScreenConnect client version < 26.6.5
Where this breaks in practice:
  • Requires social engineering or prior compromise of ScreenConnect server credentials
Detection/coverage: EDR telemetry for unexpected ScreenConnect MSI installations; monitor for ScreenConnect.ClientService.exe spawning from unusual paths
STEP 02

Transfer malicious payload via file-transfer bypass

With an active session, the attacker uses ScreenConnect's file-transfer mechanism to push arbitrary files to the host. CVE-2026-84869 means this transfer occurs without host-side authorization or confirmation dialog. The host user sees nothing. The file lands on the managed endpoint's filesystem at a writable path.
Conditions required:
  • Active ScreenConnect session to vulnerable client
  • File transfer capability enabled (default)
Where this breaks in practice:
  • Disabling TransferFiles permission in ScreenConnect roles blocks this step
Detection/coverage: Audit logs on ScreenConnect server showing file-transfer events; EDR file-write telemetry from ScreenConnect.ClientService.exe
STEP 03

Execute payload with elevated privileges

The transferred file is executed through ScreenConnect's elevated execution actions — the client agent runs as SYSTEM on Windows, so the payload inherits SYSTEM context. The attacker achieves arbitrary code execution at the highest local privilege level without any UAC prompt or host confirmation.
Conditions required:
  • Payload successfully transferred in step 2
  • ScreenConnect client running as SYSTEM (default on Windows)
Where this breaks in practice:
  • Application allowlisting (AppLocker/WDAC) could block execution of unsigned payloads
  • EDR behavioral detection of child processes from ScreenConnect
Detection/coverage: EDR alerts for ScreenConnect.ClientService.exe spawning wscript.exe, powershell.exe, or cmd.exe; Sysmon Event ID 1 process creation chains
STEP 04

Worm-like lateral propagation

In the observed campaign, the modified ScreenConnect client monitors for newly established host sessions and automatically transfers the four-stage VBScript loader (1.vbs through 4.vbs) to every new endpoint that connects. This creates self-replicating behavior — each compromised host becomes a propagation node. The VBScript chain performs host reconnaissance, enumerates security products, stages payloads from Dropbox, and establishes persistence via a WindowsServiceHost registry Run key.
Conditions required:
  • Multiple hosts connected to the same ScreenConnect instance
  • Attacker has modified the ScreenConnect client to include worm logic
Where this breaks in practice:
  • Network segmentation between managed host populations
  • Host-based script-blocking policies (constrained language mode, AMSI)
Detection/coverage: Hunt for WindowsServiceHost Run key persistence; network connections to known C2 IPs (45.13.237[.]190, 131.123.40[.]98:8041, 15.204.185[.]204); Dropbox API calls from wscript.exe
STEP 05

Post-exploitation: persistence, mining, and follow-on access

The final payload varies based on system profiling. Observed branches include: user-level ScreenConnect backdoor installation, privilege escalation with Defender exclusions and AMSI bypass, and deployment of XMRig cryptocurrency miners and wstunnel tunneling utilities. The attacker gains persistent, stealthy access across the entire managed fleet with the ability to deploy ransomware or exfiltrate data at will.
Conditions required:
  • Successful execution of VBScript chain on target hosts
Where this breaks in practice:
  • EDR with behavioral detection for AMSI bypass and Defender tampering
  • Network monitoring for mining pool connections
Detection/coverage: XMRig process detection; wstunnel binary or network signatures; Defender exclusion audit via Get-MpPreference
03 · Intelligence Metadata

The supporting signals.

In-the-Wild ExploitationConfirmed. Huntress documented a worm-like campaign exploiting this flaw across unrelated organizations starting August 2026. Modified ScreenConnect clients auto-propagate a multi-stage VBScript loader to every connected host.
CISA KEVListed September 11, 2026. Federal remediation deadline: September 14, 2026 (3-day window). KEV entry
Proof of ConceptNo standalone public PoC code identified. The worm campaign itself serves as a weaponized exploit. ConnectWise withheld technical details citing sensitivity.
EPSS0.00382 (low percentile). EPSS has not yet caught up to the active exploitation reality — do not rely on EPSS for this CVE.
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H — Scope: Changed means the vuln in the client crosses trust boundaries. The 9.9 reflects near-worst-case: network-reachable, low complexity, no user interaction, full CIA impact.
Affected VersionsAll ScreenConnect client versions prior to 26.6.5 (both Support and Access session clients). Server component is NOT affected.
Fixed Version26.6.5 (released September 8, 2026). Cloud instances auto-patched. On-prem requires server upgrade plus client reinstall/refresh — clients do not auto-update.
Exposure DataScreenConnect is a top-5 RMM platform used by thousands of MSPs worldwide. Each MSP instance manages hundreds to thousands of endpoints. Exact Shodan/GreyNoise scanning data not yet published for this CVE.
Disclosure DateSeptember 8, 2026 (coordinated disclosure with patch release)
Reporting EntityDiscovered internally by ConnectWise. No external researcher credited. Huntress independently documented the worm campaign exploiting the flaw.
04 · The Call

noisgate verdict.

Final Verdict
= UNCHANGED to CRITICAL (9.8/10)

The single most decisive factor is role multiplier — ScreenConnect is a fleet-management RMM agent running as SYSTEM on every managed host, and the documented worm-like propagation chain turns one compromised session into fleet-wide code execution. Active KEV listing with a 3-day federal deadline and confirmed in-the-wild exploitation with self-propagating behavior eliminates any basis for downgrade.

HIGH Vulnerability severity and impact
HIGH Active exploitation status
MEDIUM Exact propagation mechanism details (ConnectWise withheld specifics)

Why this verdict

  • Active exploitation with worm-like propagation. Huntress documented a live campaign where modified ScreenConnect clients auto-spread malicious payloads to every newly connected host, turning a single compromised session into fleet-wide compromise across unrelated organizations.
  • Role multiplier: RMM agent = fleet-scale blast radius. ScreenConnect clients run as SYSTEM on every managed endpoint. MSPs deploy it across hundreds or thousands of hosts. Compromising the ScreenConnect session is functionally equivalent to compromising a deployment tool or management plane — the blast radius is the entire managed fleet. ≥95% of ScreenConnect client installs occupy this fleet-management role by definition.
  • KEV-listed with 3-day federal deadline. CISA added CVE-2026-84869 to KEV on September 11, 2026 with a September 14 remediation deadline. This is the shortest deadline class CISA assigns, reserved for actively exploited vulns with severe impact.
  • Minimal friction in practice. While PR:L (authenticated session) sounds like a gate, the observed campaign demonstrates that social engineering trivially establishes rogue sessions. Once a session exists, exploitation is automatic — no user interaction, low complexity, full SYSTEM execution.
  • Scope: Changed. The CVSS S:C flag is accurate — the vulnerability in the client-side authorization logic allows the operator (one trust boundary) to execute code on the host machine (different trust boundary) without authorization, crossing the intended security model.

Why not higher?

A 9.9 or 10.0 would require zero prerequisites — truly unauthenticated remote code execution. This vulnerability requires an authenticated ScreenConnect session (PR:L), which is a real prerequisite even though the worm campaign shows it is easily obtained via social engineering. The 0.1-point reduction from the vendor's 9.9 reflects this single friction point.

Why not lower?

Downgrading below CRITICAL is not defensible. The affected component is canonically a fleet-management agent (100% of installs are in the high-value RMM role by definition), the blast radius is fleet-scale SYSTEM-level code execution, active exploitation with worm-like self-propagation is documented, and CISA issued a 3-day KEV deadline. The PR:L requirement is the only friction point, and it is demonstrably overcome in the wild via social engineering. No combination of friction arguments can pull below the CRITICAL floor for an actively exploited RMM agent vulnerability.

05 · Compensating Control

What to do — in priority order.

  1. Revoke TransferFiles permission from all ScreenConnect roles immediately — ConnectWise documented this as a temporary mitigation: Administration → Security → Roles → remove TransferFiles permission. This directly blocks the exploit's file-transfer step. Deploy within hours — this is your noisgate mitigation SLA emergency action (≤ 3 days for CRITICAL, but given KEV status, treat as immediate).
  2. Audit and remove unauthorized ScreenConnect installations — Hunt for ScreenConnect client installations that were not deployed by your IT team. Check for ScreenConnect.ClientService.exe running from non-standard paths, unexpected ScreenConnect relay domains, or the malicious session ID 7a4d7d66502d4260. Remove any rogue instances immediately.
  3. Block known C2 infrastructure at perimeter — Add the following to your blocklists: 45.13.237[.]190, 131.123.40[.]98:8041, 15.204.185[.]204, tele-sync.opik[.]net, borertors92.anondns[.]net. This disrupts the observed worm campaign's command-and-control channels.
  4. Deploy application allowlisting for ScreenConnect child processes — Configure AppLocker or WDAC to restrict what ScreenConnect.ClientService.exe can spawn. Block wscript.exe, cscript.exe, and unsigned executables as child processes. This breaks the observed VBScript attack chain.
  5. Upgrade to ScreenConnect 26.6.5 and reinstall all clients — The definitive fix. On-prem servers must upgrade to 26.6.5 (requires v25.4+ baseline), then reinstall host clients and update access agents — clients do not auto-update on-prem. Cloud instances are already patched server-side but clients still need refresh. Target completion within the noisgate remediation SLA of ≤ 90 days for CRITICAL, though KEV status demands you move faster — aim for days, not weeks.
What doesn't work
  • Network-level firewalling of ScreenConnect ports alone — the exploit travels over the existing ScreenConnect session channel, which must remain open for the tool to function. You cannot block the attack at the network layer without disabling ScreenConnect entirely.
  • Patching only the ScreenConnect server — the vulnerability is in the *client* component. Server upgrade is necessary but insufficient; every managed client must be reinstalled or refreshed to pick up the fix.
  • Relying on EPSS score for prioritization — EPSS is 0.00382 despite confirmed active exploitation with worm-like propagation. EPSS has not caught up to reality on this CVE.
06 · Verification

Crowdsourced verification payload.

Run on each managed Windows host where ScreenConnect client may be installed. Execute as Administrator in PowerShell. Example: powershell -ExecutionPolicy Bypass -File .\Check-CVE-2026-84869.ps1

noisgate-verify.ps1
POWERSHELLREAD-ONLYSAFE
#Requires -RunAsAdministrator
# Check-CVE-2026-84869.ps1
# Detects vulnerable ScreenConnect client installations (< 26.6.5)
# Exit codes: 1 = VULNERABLE, 0 = PATCHED, 2 = UNKNOWN

$found = $false
$vulnerable = $false
$minSafe = [version]'26.6.5'

# Check installed programs (both 32-bit and 64-bit registry hives)
$regPaths = @(
    'HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\*',
    'HKLM:\SOFTWARE\WOW6432Node\Microsoft\Windows\CurrentVersion\Uninstall\*'
)

foreach ($path in $regPaths) {
    Get-ItemProperty -Path $path -ErrorAction SilentlyContinue |
        Where-Object { $_.DisplayName -match 'ScreenConnect' } |
        ForEach-Object {
            $found = $true
            $ver = $null
            try { $ver = [version]$_.DisplayVersion } catch {}
            if ($ver -and $ver -lt $minSafe) {
                Write-Host "VULNERABLE - ScreenConnect client $($_.DisplayVersion) found: $($_.DisplayName)" -ForegroundColor Red
                $vulnerable = $true
            } elseif ($ver) {
                Write-Host "PATCHED - ScreenConnect client $($_.DisplayVersion) found: $($_.DisplayName)" -ForegroundColor Green
            }
        }
}

# Also check running service
$svc = Get-Service -Name 'ScreenConnect Client*' -ErrorAction SilentlyContinue
if ($svc) {
    $proc = Get-Process -Name 'ScreenConnect.ClientService' -ErrorAction SilentlyContinue
    if ($proc) {
        $fileVer = $proc.MainModule.FileVersionInfo.FileVersion
        try {
            $fv = [version]$fileVer
            if ($fv -lt $minSafe) {
                Write-Host "VULNERABLE - Running ScreenConnect client service version $fileVer" -ForegroundColor Red
                $vulnerable = $true
                $found = $true
            } else {
                Write-Host "PATCHED - Running ScreenConnect client service version $fileVer" -ForegroundColor Green
                $found = $true
            }
        } catch {}
    }
}

# Check for rogue indicators (IOCs from Huntress campaign)
$rogueKey = Get-ItemProperty -Path 'HKCU:\SOFTWARE\Microsoft\Windows\CurrentVersion\Run' -Name 'WindowsServiceHost' -ErrorAction SilentlyContinue
if ($rogueKey) {
    Write-Host "WARNING - Rogue persistence key 'WindowsServiceHost' detected in HKCU Run. Possible worm campaign IOC!" -ForegroundColor Yellow
}

if (-not $found) {
    Write-Host "UNKNOWN - No ScreenConnect client installation detected on this host."
    exit 2
} elseif ($vulnerable) {
    exit 1
} else {
    exit 0
}
07 · Bottom Line

If you remember one thing.

TL;DR
This is a drop-everything patch. CVE-2026-84869 is actively exploited with worm-like self-propagation across ScreenConnect-managed fleets, CISA has set a federal deadline of September 14 (Sunday), and the blast radius is SYSTEM-level code execution on every managed host. Monday morning is too late — act today. Per the noisgate mitigation SLA for CRITICAL (≤ 3 days), immediately revoke TransferFiles permissions on all ScreenConnect roles and block known campaign C2 IPs as an emergency brake. Then begin the upgrade to 26.6.5 and — critically — reinstall every client agent, since clients do not auto-update on-prem. Cloud customers: your server is patched, but you still need to refresh host clients. Per the noisgate remediation SLA (≤ 90 days), full client rollout must complete within that window, but given active exploitation you should target 100% client refresh within 7 days. Hunt for the WindowsServiceHost Run key and rogue ScreenConnect session ID 7a4d7d66502d4260 across your fleet immediately — if you find them, you are already compromised and need IR, not just patching.

Sources

  1. ConnectWise Security Bulletin (2026-09-08)
  2. Huntress — Rogue ScreenConnect Installations / Worm-Like Activity
  3. AiCybr — ScreenConnect 26.6.5 Mitigation Guide
  4. SecurityOnline — CVE-2026-84869 Exploitation Analysis
  5. TheHackerWire — ScreenConnect Client RCE via Unauthorized File Transfer
  6. Field Effect — ScreenConnect Worm-Like Malware Campaign
  7. NHS England Digital — Cyber Alert CC-4848
  8. SecurityWeek — Modified ScreenConnect Clients in Worm-Like Campaign
Peer Review

What defenders are saying.

Submit a review attribution: handle + country only
0 flags selected · stored anonymously
Validation Results

Crowdsourced verification outputs.

Results submitted by users who ran the verification payload against their environment.