CRITICAL: ConnectWise ScreenConnect CVE-2026-84869 Under Active Attack

There is a special kind of dread reserved for bugs in remote access tools, and MSPs know it better than anyone. The software that lets a technician fix a printer in Fargo at two in the afternoon is the same software an attacker would love to get their hands on, because it already has the keys, the trust, and the elevated rights. So when ConnectWise says a ScreenConnect flaw lets files move and run across a live session without anyone clicking yes, and CISA follows up by saying people are already exploiting it, that is not a ticket for next sprint. That is a drop everything morning.

The bug is CVE-2026-84869, and ConnectWise scored it at CVSS 9.9. It sits in the ScreenConnect client, not the server, and it allows files to be transferred and executed through an active remote session without authorization or Host confirmation in certain circumstances. ConnectWise shipped the fix in ScreenConnect 26.6.5 on September 8. CISA added the flaw to its Known Exploited Vulnerabilities catalog on September 11 and gave federal civilian agencies until September 14 to deal with it. That is a three day window, which tells you exactly how CISA feels about it.

What makes this one uglier than the average critical is the direction the attack travels. Most remote access bugs are about an outsider breaking into the console. This one, as Huntress documented it, can run the other way. A compromised endpoint on the far end of a session can hand malware back to the technician who connected to help it. Read that sentence again if you run a help desk.

What the flaw actually does

ScreenConnect sessions come in two main flavors. Support sessions are the ad hoc, click this link and read me the code variety, while Access sessions are the unattended agents that sit on managed machines waiting for a technician to connect. Both include file transfer and file execution actions, which are genuinely useful when you need to push a diagnostic script or a driver. Those actions are supposed to be gated by role permissions and by the person on the Host side approving what happens.

According to the ConnectWise bulletin, clients before 26.6.5 did not enforce that gate properly. The vendor maps the issue to CWE-862 for missing authorization and CWE-269 for improper privilege management, and the CVSS vector reads network attack, low complexity, low privileges, no user interaction, and a changed scope with high impact to confidentiality, integrity, and availability. The low privileges part deserves a pause. The attacker needs to be a participant in a session, which sounds like a real hurdle until you remember that the entire business model of a tech support scam is convincing someone to start a session with you.

The changed scope is what pushes the score to 9.9. The vulnerable component is the client, but the damage lands on whatever sits on the other side of the connection, and in the scenario Huntress described that is the technician's own workstation.

Worm-like behavior in the wild

Huntress started pulling on this thread in late August after responding to three incidents at unrelated organizations, two on August 20 and one on August 24. The initial access was depressingly familiar. Victims were talked into fake tech support calls over Microsoft Quick Assist, sent phishing emails carrying malicious MSI installers, or steered through poisoned search results to bogus Geek Squad refund forms. Every path ended with a rogue ScreenConnect client on the victim's machine.

The interesting part came next. The attackers modified those clients so they watched for newly established Host sessions. When someone connected, the client automatically transferred four VBScript files and ran them on the connecting system. Huntress put it bluntly, noting that connecting to an infected ScreenConnect client can cause the Host system to receive and execute the same four stage VBScript chain. The newly infected machine then gets its own rogue client, ready to repeat the trick on whoever connects to it next. That is the worm-like part, and it is exactly the propagation model an MSP should lose sleep over, because a technician's workstation touches dozens of customer environments in a normal week.

The script chain is methodical. The first stage profiles the host, checks whether ScreenConnect is already installed, and looks for security products including Huntress, CrowdStrike, SentinelOne, Sophos, Malwarebytes, and Cisco AMP, then writes a small state value to a text file in the temp directory. The second stage pulls a base64 encoded, XOR obfuscated configuration from Dropbox that holds payload URLs and AES keys. The third picks a payload that matches the system profile, and the fourth decrypts it, stages a PowerShell runner, and cleans up after itself.

What gets installed depends on what the scripts found. The lightest variant drops a user level ScreenConnect backdoor. The access variant goes further, compiling a small executable from inline C# to hijack the ms-settings protocol handler and abuse the built in ComputerDefaults.exe for a UAC bypass. From there, elevated PowerShell tries to break AMSI, adds C:\Users to the Microsoft Defender exclusion list, disables sleep and hibernation, and installs a hidden ScreenConnect client with its uninstall registry entry removed. The combo variant layers on wstunnel disguised as Themes.exe for tunneling to homehub.opik[.]net, an XMRig miner renamed SearchIndex.exe, and the vulnerable WinRing0 driver, while also silencing Defender notifications and turning off Hypervisor Protected Code Integrity. Persistence comes through a user Run key named WindowsServiceHost that points at a VBScript of the same name. The operators also kept UltraViewer around as a backup remote access channel, because apparently one RMM tool was not enough.

A crypto miner might sound like a low stakes ending, but do not let that fool you. Anyone holding a hidden, elevated remote access client and a tunnel on a technician's machine can sell or use that access for something far worse, and the miner is simply what they chose to run in the meantime.

It is fair to note that the picture evolved over the past couple of weeks. ConnectWise's initial September 3 advisory promised a CVE and a fix within the week, and early reporting was careful to say a direct link between the flaw and the campaign had not yet been confirmed. By the time CISA added CVE-2026-84869 to KEV, that caution had given way to evidence of exploitation. ConnectWise's own bulletin still labels the issue Important rather than Critical, while simultaneously assigning it Priority 1 and recommending emergency deployment. Vendors contain multitudes.

Who is exposed

Every ScreenConnect client older than 26.6.5 is in scope, across both cloud and on premises deployments. ScreenConnect servers themselves are not vulnerable. ConnectWise has already upgraded cloud instances, but that does not finish the job, because the bulletin also calls for reinstalling host clients and updating access agents. If you run ScreenConnect on premises, nothing changes until you upgrade the server to 26.6.5 and get updated clients out to your technicians and endpoints.

This matters because ScreenConnect is everywhere in the MSP world and in plenty of internal IT shops, and the product has a long rap sheet. CVE-2024-1709, the authentication bypass from February 2024, was mass exploited within days of disclosure. CVE-2025-3935, a ViewState code injection issue, surfaced in 2025 alongside an incident ConnectWise attributed to a nation state actor. Attackers keep coming back to this product for the same reason bank robbers kept going to banks.

What to do right now

Upgrade on premises servers to ScreenConnect 26.6.5 or later today, then reinstall or update host clients and access agents so the fixed code is actually running on endpoints and technician machines. Cloud customers should confirm their instance reports 26.6.5 and still follow the client reinstall guidance.

If you cannot upgrade immediately, the interim mitigation from ConnectWise is to remove the TransferFiles permission from every role that has it, which lives under Administration, then Security, then Roles. Your technicians will complain about losing file transfer. Let them. It is far less painful than explaining to forty customers why their IT provider seeded a miner and a backdoor across their fleets.

For detection, go straight to the ScreenConnect audit logs and look for RunFiles or RanFiles events where the process is listed as Guest, particularly for scripts named 1.vbs through 4.vbs. On endpoints, hunt for a Run key value named WindowsServiceHost, VBScript files dropped under the Public Libraries directory, a sys_cache.zip file under the Windows Templates folder in AppData, unexpected Defender exclusions covering C:\Users, and processes named Themes.exe or SearchIndex.exe running from places they have no business being. Microsoft Defender flagged one sample as Trojan:Script/Wacatac.H!ml. On the network side, block and search for tele-sync.opik[.]net, borertors92.anondns[.]net, and homehub.opik[.]net, along with the IP addresses Huntress published, including 45.13.237[.]190 and 146.59.55[.]107.

Take a hard look at every ScreenConnect client in your environments that you did not deploy yourself. Rogue instances with unfamiliar connection IDs are the tell here, and Huntress specifically called out a hidden client using the ID 7a4d7d66502d4260. Review who has session access while you are in there, and rotate technician credentials if anything looks off.

If you do find a compromised host, Huntress recommends reimaging from known good media rather than trying to clean it, and given the UAC bypass, Defender tampering, and driver abuse involved, that is the right call. Treat any technician workstation that connected to an infected endpoint as suspect until proven otherwise.

The bigger lesson is one this industry keeps relearning. Remote access tools are privileged infrastructure, and they deserve the same patch urgency, logging, and application allowlisting you give your domain controllers. If an unapproved RMM client can install and run on a user's laptop without anything raising an alert, that gap is going to get used, whether through this CVE or the next one.

The MSP angle

Every MSP running ScreenConnect should be able to tell clients this week that they patched, audited session logs, and hunted for rogue RMM installs, and that conversation is a natural opener for managed detection and response, RMM allowlisting, and security awareness training built around tech support scams. Clients who hear nothing from their provider this week will remember that too.