Most critical vulnerabilities start with someone getting in. This one starts with someone you already let in.
CVE-2026-84869 is a client-side flaw in ConnectWise ScreenConnect, scored 9.9 on CVSS. In Support and Access sessions, file-transfer actions could be processed during an active remote session without proper authorisation or confirmation from the Host — and under certain circumstances files could be transferred to and executed on the Host client system, including through elevated execution actions. The underlying weaknesses are missing authorisation (CWE-862) and improper privilege management (CWE-269).
ConnectWise published temporary mitigation guidance on 3 September 2026, then a fix on 8 September in ScreenConnect 26.6.5. All versions before 26.6.5 are affected. ScreenConnect servers are not impacted — this is the client. CISA added the CVE to the Known Exploited Vulnerabilities catalogue on 11 September and gave federal agencies until 14 September: three days, the shortest tier under Binding Operational Directive 26-04, and flagged as requiring forensic triage rather than patching alone.
The direction is the story
Everyone's mental model of a remote-support tool runs one way: the technician drives, the remote machine obeys. Files go out from the helpdesk to the user.
This flaw runs the other way. In ScreenConnect's terms the Host is the operator side — the technician who initiates and controls the session — and the Guest is the machine being supported. A file transfer initiated from the Guest end could land on the Host and run there, without the confirmation prompt the Host operator expects to see.
That inverts who is at risk. The exposed party is not the customer being helped. It is the engineer connecting in, on a workstation that very likely has credentials, tooling and access to every other customer in the book.
What Huntress actually observed
In late August 2026, the Huntress SOC raised three critical incident reports across unrelated organisations. All three started with social engineering, not with an exploit:
- 20 August: a Quick Assist tech-support scam — the user was talked into opening Windows' built-in remote support tool and sharing the access code. A rogue ScreenConnect client followed, talking to a command-and-control server at
45.13.237[.]190. - 20 August, a separate organisation:
ScreenConnect.ClientSetup.msiexecuted from a Microsoft Edge download directory, likely delivered by phishing, configured to reach131.123.40[.]98on port 8041. UltraViewer was installed alongside it. - 24 August: a user searching for a Geek Squad refund form was persuaded to download and run
ScreenConnect.Client.exe, which called back toborertors92.anondns[.]net.
The detection that caught all three was behavioural and unglamorous: ScreenConnect.WindowsClient.exe repeatedly spawning wscript.exe. The rogue clients were running four VBScripts — 1.vbs through 4.vbs — delivered inside a RAR archive with an .exe extension.
The four-stage chain
1.vbs profiles the machine and writes a three-bit state value to %TEMP%\value.txt. It checks whether ScreenConnect is already installed — writing abort if it finds one — enumerates security products by service and process name, including Huntress, Cisco AMP, CrowdStrike, SentinelOne, Sophos and Malwarebytes, and sets a bit when Microsoft Defender appears to be the only endpoint protection present. It also checks whether the machine has more than 5 GB of RAM, most likely to avoid running inside an analyst's minimally-provisioned virtual machine.
2.vbs waits for value.txt, and if it does not say abort, downloads a file from Dropbox using a hardcoded User-Agent so the request looks like a person fetching a document. It base64-decodes the content, XORs it with a single-byte key of 90, and writes %TEMP%\map.txt. That file is a catalogue, not a payload: each line maps one of the three-bit state values to a download URL with an AES key appended after a pipe character.
3.vbs reads the state back, finds the matching line, and downloads the corresponding package — user.enc for states 000 and 001, a user-level ScreenConnect backdoor; acc.enc for 010, persistence and privilege escalation tooling; combo.enc for 011, tunnelling utilities and a cryptocurrency miner.
4.vbs extracts the AES key from map.txt, deletes value.txt and map.txt, then builds a PowerShell script inline, stages it as %TEMP%\runner.ps1 and launches it with an execution-policy bypass. That script decrypts the payload using AES-CBC with PKCS#7 padding, taking the first 16 bytes of the encrypted file as the IV, writes the result to %APPDATA%\Microsoft\Windows\Templates\Classic\sys_cache.zip, executes a second PowerShell script named PyTorchFix.ps1, kills every wscript.exe and cscript.exe process and removes the staging directory.
The 010 "access" variant of PyTorchFix.ps1 compiles a Password.exe from inline C# and uses a hijacked ms-settings: protocol handler with the built-in ComputerDefaults.exe for a UAC bypass. Elevated, it attempts an AMSI bypass, adds all of C:\Users as a Microsoft Defender exclusion path, disables sleep and hibernation, then installs a ScreenConnect client, removes its Windows Registry uninstall entry and applies a restrictive service security descriptor so the service is hidden. The 011 branch adds wstunnel disguised as Themes.exe tunnelling to homehub.opik[.]net:443, XMRig renamed SearchIndex.exe, and the vulnerable WinRing0 driver as svcdrv64.sys.
Persistence in all of this is mundane: an HKCU\Software\Microsoft\Windows\CurrentVersion\Run entry named WindowsServiceHost, pointing at WindowsServiceHost.vbs in the user's AppData directory.
The worm-like part, stated precisely
The backdoored clients Huntress recovered span nine ScreenConnect versions. Each one watches ScreenConnect's EndPointStatusMessage.Connections collection for newly observed Host sessions. When a new Host connects, the client reads 1.vbs through 4.vbs from C:\Users\Public\Libraries\Default\Lib\Lib1, registers them with ScreenConnect's virtual file-transfer system, sets the action to Run, and queues the message for the connected Host. Huntress: "Connecting to an infected ScreenConnect client can cause the server-side Host system to receive and execute the same four-stage VBScript chain."
Two clarifications the headlines have blurred. First, Huntress derived this capability from analysing the recovered modified client — it does not claim to have confirmed a Host-side infection in the three incidents it describes, and it does not tie the propagation to CVE-2026-84869 in its own voice. Second, the de-duplication is weaker than it looks: the client records each ConnectionID to avoid hitting the same live session twice, then drops the identifier on disconnect, so a later reconnection triggers the whole thing again.
The update has to reach the clients
This is a client-side defect, so the update has to reach the clients. Upgrade to ScreenConnect 26.6.5 — on-premises deployments need to be on 25.4 or later first — and then reinstall host clients and update access agents so endpoints actually pick up the fixed client. Until that is done, ConnectWise's interim advice is to check the TransferFiles permission (TransferFilesInSession in legacy versions) and disable it where enabled.
Then go looking, because CISA flagged this one for forensic triage for a reason. In ScreenConnect server audit logs, RunFiles or RanFiles entries executed from Process: Guest are the signal — Huntress recommends treating any such device as one to reformat. Filenames change, so treat any Windows Script Host or PowerShell execution originating from the Guest side as suspect. On endpoints, check for the WindowsServiceHost Run key, for %TEMP%\value.txt, and for ScreenConnect clients you did not deploy. Huntress recommended reimaging affected hosts from known-good media rather than cleaning them.
The question underneath the CVE
Remote-access agents are the awkward case in every asset inventory. They are installed deliberately, they are signed, they are supposed to talk to the internet, and they are frequently excluded from the scrutiny applied to everything else — this campaign went one better and added C:\Users to Defender's exclusion list itself. The incidents above also stacked Quick Assist and UltraViewer on top of ScreenConnect, which is what "we only use one RMM" usually means in practice.
Shadowserver was still tracking over 1,000 unpatched ScreenConnect instances exposed online after the patch shipped, 758 in North America and 180 in Europe. Every one of those belongs to someone who either did not know it was reachable or did not know it was theirs.
That is the check worth running whether or not you use ScreenConnect: enumerate what your own perimeter answers on, and work out which of those services still has an owner. ClickScan maps exposed services, ports and management interfaces on a domain from the outside, the same way an attacker enumerates them — see how it works, the MSP view if you run this across client estates, or just run a scan on your own domain.
Sources: Huntress — Rogue ScreenConnect Installations Across Unrelated Hosts Suggest Worm-Like Activity, ConnectWise security bulletin, 8 September 2026, CISA Known Exploited Vulnerabilities catalogue, BleepingComputer, 16 September 2026, NVD entry for CVE-2026-84869. The worm-like propagation is Huntress's analysis of a recovered modified client rather than an observed Host-side compromise, and no threat actor attribution has been published.