ConnectWise ScreenConnect is the remote-control software a technician uses to take over a computer and fix something on it. A flaw in it, CVE-2026-84869, could let files be transferred and run through a live session "without authorization or Host confirmation," and ConnectWise says where they land: "on the Host client system," the technician's side of the session, per ConnectWise's own disclosure. Huntress first saw the abuse on August 20, ConnectWise shipped version 26.6.5 on September 8, and CISA added the flaw to its Known Exploited Vulnerabilities catalog on September 11 with a federal deadline of September 14, per the CISA KEV catalog.
That deadline has passed, and it only ever bound federal agencies. What has not passed: any host client or access agent that was never updated is still on a vulnerable build, and the malware behind this checks which antivirus is installed and sends the heavier payload to machines running only Microsoft Defender.
Updated October 23, 2026: This guide now follows ConnectWise's own disclosure, which puts the risk on the technician's computer, and its instruction to update host clients and access agents rather than only the server. The cleanup is now one fixed order, isolate first.
Do you know which remote-control agents are installed on your shop's computers, and who is allowed to start a session? If nobody in the building can answer that, that is the first call. (336) 886-3282, or ask for a remote-access inventory.
Is ScreenConnect on my computers, and who put it there?
Possibly, and possibly not your IT company. Besides IT providers, a machine-tool vendor may install it to reach a CNC controller, an ERP consultant may leave it behind after a go-live, and tech-support scammers talk people into installing it. Huntress documented three ways victims ended up running a rogue client in late August: a scammer walked someone through Microsoft Quick Assist, a likely phishing email led to a ScreenConnect.ClientSetup.msi download, and a search for a Geek Squad refund form led to a rogue client, per the Huntress research and The Hacker News.
| How the rogue client arrived | What the person at the keyboard saw | What to check in your own shop |
|---|---|---|
| Microsoft Quick Assist session | Someone posing as tech support, by phone or a fake alert, walking them through built-in Windows help | Whether Quick Assist is usable by standard users at all, and whether anyone has run it |
| Likely phishing, with an MSI installer | A file called ScreenConnect.ClientSetup.msi | Installed-program lists for ScreenConnect entries nobody on staff can account for |
| A search for a Geek Squad refund form | Being convinced into downloading and running a remote-support client | Browser history and downloads on any machine used for personal errands |
What does CVE-2026-84869 actually let an attacker do?
It lets a machine on the far end of a session push files to the technician's computer and run them, skipping the authorization and confirmation that are supposed to gate a file transfer. ConnectWise says this "could allow files to be transferred to and executed on the Host client system, including through elevated execution actions," and that "ScreenConnect servers are not impacted," per ConnectWise. In ScreenConnect the host is the technician and the guest is the customer, per Wikipedia's ScreenConnect entry. So the exposed computer is the one doing the supporting: your IT provider's technician, your in-house IT person, a machine vendor's support engineer.
ConnectWise scored this 9.9 out of 10 as its own CVE numbering authority, and the NVD record carries no separate NIST score, so 9.9 is the vendor's number. NVD's affected range ends just below build 26.6.5.9742, so "26.6.5" alone does not prove a machine is patched. ConnectWise warned customers on September 3 and patched on September 8, a five-day window in which the only answer was a permission change, per Computerworld. And the server is not the whole job: for cloud instances ConnectWise says its servers "have been updated," but still recommends "updating your host clients" and access agents, per ConnectWise. On-premises servers upgrade to 26.6.5 or later.
After the transfer, Huntress watched the rogue clients spawn Windows Script Host repeatedly to run four files, 1.vbs through 4.vbs: profile the machine, download and decode a payload catalog from Dropbox, pull the payload matched to that profile, then decrypt and run it before killing the script hosts and deleting the staging directory. Persistence was a user-level registry Run key named WindowsServiceHost, pointing at a .vbs file in AppData, per the Huntress research.
Then it spreads. The recovered variant watched for newly observed Host sessions and, for each one, packaged the same four scripts into a file-transfer message with its action set to Run. "Connecting to an infected ScreenConnect client can cause the server-side Host system to receive and execute the same four-stage VBScript chain," Huntress wrote, describing "a worm-like behavior: propagating infections over new ScreenConnect connections," per the Huntress research. The client tracks each connection so it does not hit the same session twice, then forgets it on disconnect so a reconnection is infected again. Huntress's title says the evidence suggests worm-like activity, and we use their word. The trap: a technician connects to an infected machine to help, and the technician's computer receives the chain.
Nobody can patch an agent they cannot find. Preferred Data Corporation, (336) 886-3282, or managed cybersecurity.
Why does the malware check whether you only run Microsoft Defender?
Because it changes what you get. The first script builds a three-bit profile, and the middle bit is the one about you: it looks for Huntress, Cisco AMP, CrowdStrike, SentinelOne, Sophos, Malwarebytes and others, sets the bit to 0 if it finds any, and to 1 when Microsoft Defender appears to be the only thing there. The outer two bits test for an existing ScreenConnect install, and a separate RAM check for more than 5GB is most likely there to skip researchers' virtual machines, per the Huntress research.
Follow that through Huntress's map of profiles to payloads. States 000 and 001 get user.enc, a user-level ScreenConnect backdoor. States 010 and 011, the two where that middle bit is set, get acc.enc and combo.enc: privilege-escalation and persistence tooling in the first, and in the second a tunneling utility renamed Themes.exe plus an XMRig miner renamed SearchIndex.exe. The 010 package adds all of C:\Users as a Defender exclusion; the 011 package includes payloads that disable Defender reporting and HVCI. Those same two states write the four scripts to a public folder, which is what turns the machine into a carrier.
Key takeaway: The malware checks what antivirus you run and hands the worse payload to machines running only Defender. A protection the attacker can plan around is a reason to have someone watching.
The evidence is the malware's own code, though Huntress, which published it, sells one of the products checked for. See EDR versus a managed detection service.
Does patching clean up a machine this already ran on?
No. Updating closes the transfer path. It does not remove a registry Run key, a hidden second ScreenConnect instance, a Defender exclusion covering every user profile, or a tunneling binary wearing a Windows name. On machines where this chain ran, Huntress's security operations team recommended that "these affected hosts be reimaged from known-good media, or a clean operating system install," per the Huntress research.
How you find one: in ScreenConnect server audit logs, RunFiles or RanFiles entries with those 1.vbs through 4.vbs names executed from Process: Guest "should raise immediate suspicion and warrant reformatting that device," per Huntress. Huntress warns the filenames may change, so any Windows Script Host or PowerShell execution there deserves the same scrutiny. On the machine itself, look for the WindowsServiceHost Run key and the malicious ScreenConnect instance ID 7a4d7d66502d4260.
If you find one, this is the order for that machine and for every technician computer that connected to it, because the technician's side is where the chain runs. Nothing else goes first:
| Step | What to do | Why it comes here |
|---|---|---|
| 1. Isolate | Disconnect each machine from the network and leave it powered on, including technician workstations that joined its sessions: pull the cable or isolate it from your endpoint tool. Nobody remotes into it, through ScreenConnect or anything else | Connecting to it is how this spreads, and isolation stops the tunnel and any captured access being used from it |
| 2. Preserve | Call your insurer and incident responder before anything is reimaged. Have the responder image the disk, or image it yourself, and export the audit log entries with their times | The Run key, the hidden 7a4d7d66502d4260 agent, the C:\Users exclusion and the dropped files live on the machine, and a reimage destroys them |
| 3. Rotate | From a different, clean computer, change every password used on those machines: domain accounts, saved browser passwords, ScreenConnect technician logins, any service account that signed in there | Once the machine is off the network, it cannot capture a password that is never typed on it |
| 4. Reimage | Rebuild from known-good media, per Huntress | Removes the Run key, the exclusion, the hidden agent and the tunnel |
| 5. Return | Where a legitimate ScreenConnect agent or host client was in use, install a current one from clean media before it goes back on the network; then watch it | So the rebuilt machine is not exposed the same way again |
Huntress also suggests admins "apply extra scrutiny to any on-premises ScreenConnect installations," per Huntress. For a hit technician computer, review the server and every session that technician's account opened.
The order is standard incident response. CISA's playbook lists "Isolate affected systems" before "Change system admin passwords, rotate private keys and service/application account secrets," per CISA, and NIST warns that an intentional delay to containment "can be dangerous because an attacker could escalate unauthorized access or compromise other systems," per NIST SP 800-61r3.
Who does what, and what to say on the phone
If you are the owner or the plant manager, you probably cannot open the ScreenConnect console: it belongs to whoever installed the agent, which may be your IT provider, a machine vendor, or a company that stopped working for you years ago.
Two you can do yourself:
- Walk the machines you have rights to and list every remote-access program installed, not only ScreenConnect. For the floor boxes you are not admin on, write down who set them up instead.
- Write the approval rule. One page: nobody outside this company gets remote control of a machine without a named person here approving it first.
Three to put to whoever holds the console, in this order, with the answers in writing:
- "Pull our session audit log. Did any file execution come from a guest process?" Ask this first. If it shows the pattern above, stop here and run the five steps above today, on that machine and on every technician computer that joined its sessions: off the network but powered on, and your insurer and incident responder called before anything is reimaged. The two questions below wait until it is off the network.
- "Is every host client and access agent at build 26.6.5.9742 or later, and what date did that go on?" Ask about the technicians' host clients and the agents on your machines, not only the server, and ask for the full four-part build number.
- "Which roles hold file-transfer rights, and can you remove them where they are not needed?" This sits under Administration, then Security, then Roles; inside each role it is set per session group in the Scoped Permissions window, and legacy builds name it
TransferFilesInSessionrather thanTransferFiles, so looking only for the newer name can wrongly clear you. Repeat for every role, per The Hacker News.
We can tell you which agents are on your machines and who can start a session. Preferred Data Corporation, (336) 886-3282, [email protected]. We are headquartered at 1208 Eastchester Drive, Suite 131, High Point, NC 27265, work on site within 200 miles of High Point, and support clients remotely across the US and around the world. Founded in 1987, we support manufacturers and contractors, and our average client has stayed more than 20 years.
Frequently Asked Questions
Did the CISA September 14 deadline apply to my business?
No. It came from BOD 26-04, a directive that covers "Federal Civilian Executive Branch" systems, per CISA, not private companies in North Carolina. Its value to you was as a severity signal: CISA listed the flaw as known exploited on September 11 and gave agencies three days.
Are ScreenConnect servers affected, or only the client software?
ConnectWise states that ScreenConnect servers are not impacted; the flaw is in the client, and the files land on the host client, the technician's side. Cloud servers were updated by ConnectWise, which still recommends updating host clients and access agents. On-premises servers should be on 26.6.5 or later, per ConnectWise.
How would I know if this ran on one of my computers?
Check the ScreenConnect session audit log for file execution from a guest process, and the machine for a user-level Run entry named WindowsServiceHost. If either turns up, every technician computer that joined that machine's sessions goes through the same five steps, whatever its own check shows. Absence is not proof of safety: the filenames may have changed.
Is Microsoft Defender enough for a small manufacturer?
Huntress reports Defender detected and quarantined the last of the four scripts, 4.vbs, as Trojan:Script/Wacatac.H!ml. It did not stop persistence: Huntress reports the attacker created the WindowsServiceHost Run key and ran a batch file Huntress never recovered. What ended that intrusion was people: "the Huntress SOC shut the attack down before it could progress further," per the Huntress research. Defender is a reasonable floor, not monitored detection.
If my IT provider uses ScreenConnect, should I make them stop?
No. Remote support is how a small shop gets help without waiting for somebody to drive out. Ask for three things on paper instead: the build of their host clients and your agents with the date it went on, the list of roles holding file-transfer rights, and how long session logs are kept.
If my IT company's tool was the way in, whose problem is that?
Not really an IT question. Who bears remediation cost under your provider's contract is one for your attorney. Whether your cyber policy pays, given what you attested about endpoint protection, is one for your broker, worth asking before you need it.