When Remote Support Turns Against the Technician

When Remote Support Turns Against the Technician

On 8 September 2026 ConnectWise patched a hole in ScreenConnect rated 9.9 out of 10. It lets the computer being supported push files onto the technician's own machine and run them there — the opposite of how everyone assumes remote support works. US authorities logged it as actively exploited three days later, with a three-day deadline to patch.

What exactly happened?

ConnectWise published the advisory and shipped ScreenConnect 26.6.5 on the same day, 8 September 2026. The flaw is CVE-2026-84869, scored 9.9 out of 10 on CVSS — the industry's standard severity scale, where anything above 9 means a stranger can take over the machine without needing an account on it.

Two words decide who gets hurt here. In ScreenConnect, the Host is the technician running the session. The Guest is the machine being controlled — the customer's PC. Every mental model of remote support runs Host to Guest: the helper reaches in, the helped machine sits there.

This bug runs the other way. File transfer actions could complete during an active session without the Host confirming anything, and the transferred file could then be executed on the Host's system. The customer machine reaches back into the technician's laptop.

Huntress had already seen this used. Its write-up on rogue ScreenConnect installations records two incidents on 20 August 2026 and a third on 24 August, at organisations with nothing to do with one another. In each, someone was talked into running a modified ScreenConnect client. That client waited for a new Host session and then pushed four small VBScript files — Windows' own scripting format, which runs with no extra software installed — onto the technician's machine.

The four scripts split the work. The first profiles the machine: what security products are running, how much RAM, whether it is a virtual machine. The second fetches a payload map from Dropbox. The third pulls down the encrypted payload that matches the profile. The fourth decrypts it and starts a PowerShell runner. A registry entry named WindowsServiceHost makes the whole thing start again at every boot.

On 11 September 2026, CISA added CVE-2026-84869 to its Known Exploited Vulnerabilities catalogue — the US list of holes confirmed to be in real attacks, not just theoretically dangerous — and set the federal patch deadline at 14 September. Three days is short even by that catalogue's standards. The same batch covered two MikroTik RouterOS flaws added the day before, the ones behind the router takeovers we wrote about last week.

Why this matters if you have never installed ScreenConnect

ScreenConnect is one product in a category most Indonesian businesses already run without thinking about it: remote support agents, the small program that lets a technician take over your screen from somewhere else. AnyDesk, TeamViewer, RustDesk, Splashtop, and every vendor-branded support tool sit in the same category and hold the same position in your network.

Look at how IT actually gets done at a hotel, a factory, or a 30-person distributor here. There is no internal IT department. There is a vendor, or a freelancer, or the nephew who set up the network in 2021. One laptop — often a personal one — carries remote access to the point-of-sale machines, the server in the cabinet, the CCTV recorder, and the PC that runs the accounting software.

Everyone reasons about that access in one direction: what if the technician does something careless on my machine. That is the smaller risk. The bigger one is that the technician's laptop is a hub. It touches twenty customers. Compromise it once and you are inside twenty businesses, using a tool that every endpoint on the list already trusts.

It is the locksmith's key box. Nobody picks the lock on your front door if they can take the box where all the spare keys hang.

Who can already get into your machines?

Almost no business I have audited can answer this from memory, and the answer is never shorter than expected. Five questions produce the list:

1. Which remote access agents are installed on each business machine? Check installed programs and running services on the POS terminals, the office PCs, the server, and any machine attached to the CCTV recorder.
2. Who owns each one? Every agent traces back to a vendor, a contract, and ideally a person. An agent nobody can name is an open door with no landlord.
3. Which of them still needs to be there? Support agents outlive the projects that installed them by years. The integrator who finished in 2024 is usually still connected.
4. Which machines allow unattended access — connection without anyone sitting there to approve it? That setting is convenient and it is also the whole attack surface after hours.
5. Does the vendor's console use named accounts with a second factor, a code or key on top of the password? A shared login called admin means no session in the log can be traced to a person.

That inventory belongs in the same file as your system handover documents. If you have never built one, our piece on what to demand at vendor handover covers where access lists sit in the wider package.

What to fix this week

1. Update the clients, not just the server. ScreenConnect 26.6.5 fixes this, but clients live on endpoints and lag behind. Check versions on the machines, not on the console.
2. Turn off file transfer where it is not needed. ConnectWise names disabling the TransferFiles permission as the interim measure if you cannot update immediately. Most support sessions are a screen and a mouse, nothing more.
3. Remove orphaned agents. Anything whose owning project has ended comes off the machine today.
4. Stop supporting customers from the machine that holds your credentials. For a vendor, this is the cheapest control available: a dedicated virtual machine for remote sessions, with no saved passwords, no customer VPN profiles, no signing keys.
5. Named accounts with a second factor on every support console. The console is the master key, not the endpoints.
6. Read the session logs. In ScreenConnect, look for entries showing files run from the Guest side of a session. On any other tool, the equivalent is file transfers you did not initiate.
7. Put notification in the contract. Your vendor should be obliged to tell you when their own systems are compromised, in writing, within a fixed window. European buyers already get this by law — our piece on the 24-hour reporting rule explains the wording worth borrowing into a purchase order.

What if you think you were already hit?

Reimage. Huntress's own recommendation for the affected machines is to rebuild from clean installation media rather than clean up in place, because the persistence sits in several locations at once and the payload is fetched fresh each time.

Then work outward from that machine. Every credential it held is burned: saved remote sessions, customer VPN profiles, browser-stored admin passwords, cloud console logins. Rotate them all, and check whether the same account was reused across customers.

Last, tell the other customers. A support laptop that touched twenty networks is an incident at twenty companies, not one. Silence there is how a single compromised technician becomes a quarter of a client list.

The part that will still be true next year

The specific hole closes with an update. The shape of the problem does not: a remote support tool is a standing, authenticated path into machines that matter, granted once for convenience and almost never revoked.

Two habits cover most of it. Know who can reach into your systems, on paper, with names next to each entry. Remove the ones who no longer need to.

Both are boring, and neither shows up in a quarterly report. They are also the difference between patching one laptop and rebuilding twenty networks.