CVE-2026-84869, ConnectWise ScreenConnect: a missing file-transfer authorization check lets an active remote session push and auto-run files on the Host, and Huntress traced worm-like exploitation back to 20 August, weeks before any patch existed (CVSS 9.9)
ConnectWise patches a ScreenConnect flaw Huntress had already watched turn every infected connection into the next one's launch point
Defender actions
- Upgrade every ConnectWise ScreenConnect on-premise client to 26.6.5 now; where an immediate upgrade is blocked by a change window, remove the TransferFiles role permission from every session group in the interim (Administration > Security > Roles); ScreenConnect servers themselves are not affected, only clients.
- Treat any pre-26.6.5 ScreenConnect client that shows a second, unfamiliar RMM tool (UltraViewer, Quick Assist) or an unexplained ScreenConnect connection ID as compromised, not merely vulnerable: reimage rather than patch in place; the worm mechanism means a technician's own session can already have propagated the infection to every host that client actively connected to.
Analysis
ConnectWise's own disclosure describes a client-side condition in ScreenConnect Support and Access sessions where file-transfer actions could be processed through an active remote session "without proper authorization or Host confirmation," letting files be transferred to and executed on the Host system, including through elevated execution paths (ConnectWise, 2026-09-08). ScreenConnect servers are not affected, only client versions before 26.6.5, the release that fixes CVE-2026-84869 (CWE-862 Missing Authorization, CWE-269 Improper Privilege Management, CVSS 9.9).
Huntress had been tracking the exploitation for two and a half weeks before any advisory existed. Starting 20 August 2026, its SOC found rogue ScreenConnect clients deployed via social engineering (a fake tech-support Quick Assist session in one case, a phishing-driven MSI in another) that immediately spawned four chained VBScript stagers via wscript.exe. The stagers profile the host (existing ScreenConnect install, installed security-product names, available RAM to rule out a sandbox), then pull an AES-encrypted payload bundle keyed to that profile from Dropbox. Depending on the profile, the final PowerShell stage installs a ScreenConnect backdoor client concealed as a hidden Windows service, its registry Uninstall entry removed and a restrictive service security descriptor applied, builds a UAC-bypass helper via a hijacked ms-settings: protocol handler routed through ComputerDefaults.exe, sets AmsiUtils.amsiInitFailed = true to blind AMSI, adds all of C:\Users as a Defender exclusion, and disables Defender reporting, notifications and Hypervisor-Protected Code Integrity, the last of these via a vulnerable WinRing0 kernel driver dropped alongside the payload (Huntress, 2026-09-03). The broadest observed variant then drops a wstunnel tunneling tool disguised as Themes.exe and an XMRig cryptominer disguised as SearchIndex.exe.
The installed backdoor client is what turns the bug into a worm: it continuously inspects ScreenConnect's own connection-status collection for newly established Host sessions and, on each new connection, packages the same four VBScript stagers into a ScreenConnect file-transfer message flagged to auto-run, the exact abuse path CVE-2026-84869 patches. A technician's ScreenConnect client that has been infected this way silently re-infects every subsequent host it connects to, independent of the original social-engineering vector (Huntress, 2026-09-03). No named threat-actor cluster is attributed by any source; CISA added the CVE to its Known Exploited Vulnerabilities catalog on 2026-09-11 with a three-day remediation deadline (CISA KEV, catalogue version 2026.09.11).
Cited evidence
A condition in the ScreenConnect client may allow files to be transferred and executed through an active remote session without authorization or Host confirmation in certain circumstances. ScreenConnect servers are not impacted.
This creates a worm-like behavior: propagating infections over new ScreenConnect connections. Connecting to an infected ScreenConnect client can cause the server-side Host system to receive and execute the same four-stage VBScript chain.
In late August, our Security Operations Center (SOC) sent out three critical incident reports for what looked like malicious ScreenConnect installation and unexpected process execution.
Sources4
AI-generated · no human review · this permalink is the shareable record for the finding · verify operationally critical claims against the linked primary source.