ConnectWise Patches a 9.9-Rated ScreenConnect Flaw Used in Worm-Like Attacks

ConnectWise has released an emergency update for ScreenConnect, its remote support and access software, to close a critical client-side flaw that let an attacker move and run files inside an active session without the host's approval. The fix, ScreenConnect 26.6.5, shipped on September 8, according to the vendor's security bulletin. The vulnerability, tracked as CVE-2026-84869, carries a CVSS score of 9.9 out of 10, and researchers had already watched it being used in the wild for about two weeks before a patch existed.

Related reading: Attackers Used ConnectWise Cloud Backup's App Identity to Sign Into Microsoft 365 Tenants · FBI Arrests OpenAI Employee Accused of Planting a Hidden Recording Device.

The bug sits in the ScreenConnect client, not the server. ConnectWise describes a condition in which file-transfer actions can proceed "through an active remote session without authorization or Host confirmation in certain circumstances," and states that ScreenConnect servers are not affected. In practice, an attacker already inside a session can push a file to the connected endpoint and execute it, including through elevated execution actions.

What Huntress saw

The security firm Huntress documented the activity, first flagging it in late August and publishing its findings on September 9 in a detailed writeup. Across three unrelated incidents, its analysts found rogue ScreenConnect installations on victim machines that then repeatedly spawned wscript.exe to run four scripts named 1.vbs through 4.vbs.

The rogue installations arrived through social engineering. One began with a tech-support scam built on Windows Quick Assist. Another followed a search for a Geek Squad refund form that led the victim to run a downloaded client setup file. A third started with a poisoned search result that pushed a rogue ScreenConnect.Client.exe. These are familiar tactics: remote monitoring and management (RMM) tools are attractive to criminals precisely because they are trusted software that reaches deep into a network.

What made this campaign different was what the modified clients did next. According to Huntress, the rogue client watched ScreenConnect's connection list, and whenever a new host session appeared it registered the four VBScript files with the software's own file-transfer system and pushed them to the newly connected machine. The chain then repeated on that endpoint. Huntress called the behaviour worm-like because the payload spreads from session to session on its own, rather than waiting for an operator to repeat the work by hand.

On each host, the intrusions also left a Windows User Run key named WindowsServiceHost pointing to WindowsServiceHost.vbs in the user's AppData folder, and in at least one incident installed a second remote-access tool, UltraViewer. Huntress listed command-and-control addresses seen during the incidents, including 45.13.237[.]190, 131.123.40[.]98 and 15.204.185[.]204.

The four-stage loader

The scripts were staged to profile each machine before choosing a payload. The first, 1.vbs, wrote a three-bit value to a temporary file describing whether ScreenConnect was already installed, which security products were running, and how much memory the host had. The memory check, Huntress observed, is a common way to keep a payload from running inside a small analysis virtual machine.

A second script waited for that value, pulled a file from Dropbox, decoded it with a single-byte XOR key, and produced a catalogue of further payloads keyed to the three-bit value. A third script read the catalogue and downloaded the matching entry, which was stored encrypted as out.enc. The fourth decrypted it with an AES key taken from the catalogue, launched a PowerShell runner, decrypted a second archive into a Windows templates directory, deleted the staging files, and killed any remaining script hosts.

Among the outcomes Huntress observed were a UAC bypass built on the ms-settings protocol handler, an attempt to turn off the antimalware scan interface, a Microsoft Defender exclusion for the whole C:\Users tree, and a concealed ScreenConnect client whose uninstall entry and service descriptor were stripped so it would not appear in the usual places. One payload variant also delivered a cryptocurrency miner, a sign of financially motivated tradecraft.

One detail stands out for defenders. A comment inside 3.vbs spelled out the expected format of the payload catalogue, the kind of explanatory note a human developer leaves behind. Huntress wrote that the script was "likely" generated by a large language model. Commodity malware assembled with the same assistants that write ordinary code is now a routine part of incident response, and it makes the scripts read more cleanly than their intent deserves.

Branching payloads

Not every host received the same package. Huntress found that the catalogue mapped the three-bit profile to one of three encrypted payloads: a user-level ScreenConnect backdoor, an access package that carried persistence and privilege-escalation tooling, or a combined package that it said included tunnelling utilities and a cryptocurrency miner. Building a target profile and then choosing a payload is ordinary tradecraft for a loader of this kind, but it shows the operators were sorting machines rather than spraying one stage at everything they touched.

How the response unfolded

The disclosure ran on a compressed schedule. ConnectWise published an advisory on September 3 warning of an issue in file-transfer behaviour in ScreenConnect's support and access sessions across both cloud and on-premises deployments, and said a CVE and an official fix would follow within the week, while recommending that partners review and disable the TransferFiles permission in the meantime. Huntress, which had been tracking the anomalies since late August, updated its writeup on September 8 when the 26.6.5 patch arrived, and again as the exploitation picture filled in. CISA's catalog entry on September 11 turned a vendor remediation into a federal deadline of September 14 for civilian agencies. The sequence, advisory first, patch days later, then a known-exploited listing, has become the standard rhythm for a serious enterprise bug, but it still left about two weeks between the first observed intrusions and a fix.

Why remote access keeps being the target

ScreenConnect is widely used by managed service providers and IT help desks. That is exactly what makes it valuable to an attacker: it is legitimate software with broad reach into customer networks, and it runs with the privileges a help-desk technician is expected to hold. RMM abuse has been a top attack vector for years, and ScreenConnect has been through this before. A 2024 authentication bypass in the product was exploited widely, and the pattern of using a remote-support session to drop tooling has become so common that defenders now treat RMM installs as a detection surface in their own right.

For a managed service provider the stakes are higher than for a single enterprise. An MSP often administers many customers from one ScreenConnect deployment, so a contaminated client that pushes payloads to new sessions can threaten downstream customers as well as the provider's own machines. That is a supply-chain problem in miniature, and it is why the vendor's advice to audit session file-transfer permissions applies most urgently to service providers.

The propagation model is the new part. RMM abuse normally depends on an operator pushing a tool to one machine at a time, which limits how fast an intrusion spreads and gives defenders more chances to catch it. A client that pushes the next stage to any machine it later connects to removes that bottleneck. It also complicates attribution, because every machine on the same ScreenConnect deployment becomes a potential delivery point.

The patch deadline

CISA added CVE-2026-84869 to its Known Exploited Vulnerabilities catalog on September 11 and gave federal civilian agencies until September 14 to remediate, under Binding Operational Directive 26-04. It was one of three entries that day and part of a wider cluster the agency catalogued during the week, alongside two MikroTik RouterOS flaws and two JFrog Artifactory flaws that The Hacker News reported were chained in attacks on self-hosted servers. SecurityWeek was among the outlets that confirmed the ScreenConnect exploitation.

Two caveats are worth keeping. The worm-like description comes from Huntress's investigation rather than from ConnectWise, and it describes session-to-session propagation among machines that share a ScreenConnect deployment, not the self-sustaining, internet-wide spread that the word worm usually implies. Separately, neither company has attributed the campaign to a named group. The common miner component and the consumer-support lures point to a financially motivated operator, but that is an inference from tradecraft, not a confirmed identification.

What to watch

The immediate question for any organisation running ScreenConnect is whether the modified clients reached machines outside the estate that its own administrators know about, since the whole point of the propagation is to land on endpoints the operator did not touch directly. Audit logs that show a Guest process running files on a host are the place to start.

The longer question is whether the same technique shows up in other remote-support products. The underlying condition, a client that acts on session instructions without a clear authorization check, is unlikely to be unique to one vendor. ConnectWise has shipped the fix; the rest of the RMM market now has a reason to look at how its own clients decide which file transfers to trust.

Image: ScreenConnect logo by ScreenConnect, via Wikimedia Commons, licensed under CC BY-SA 4.0. The image has been cropped and placed on a background.