ScreenConnect CVE-2026-84869: Guest File Transfer Without Host Consent, Worm-Like VBS Spread, CISA KEV

Introduction

ConnectWise patched CVE-2026-84869 in ScreenConnect 26.6.5 after Huntress documented late-August intrusions that looked like a worm spreading across unrelated hosts. The client-side bug is missing authorization plus improper privilege management: during an active Support or Access session, file transfer and execution can proceed without Host confirmation. CVSS is 9.9. CISA added the CVE to KEV on September 11 and gave federal agencies three days. Shadowserver still sees more than 1,000 unpatched internet-exposed ScreenConnect instances, most of them in North America.

What Happened

ConnectWise's September 8 bulletin is narrow and important: servers are not impacted. The defect is in ScreenConnect clients prior to 26.6.5, in Remote Access Support and Access sessions, cloud and on-prem. Under certain circumstances a guest can transfer and execute files on the Host without the Host operator confirming it. Interim mitigation — disable the TransferFiles permission (legacy name TransferFilesInSession) on every role — shipped in a September 3 advisory while the CVE and patch were still coming.

Huntress's customer cases (first seen August 20, additional on August 24) started with tech-support-scam social engineering: victims ran a rogue ScreenConnect client pointed at attacker infrastructure. That client then watched for other live sessions and pushed a four-stage VBScript chain (1.vbs through 4.vbs) onto connected endpoints. Later stages included PyTorchFix.ps1 (UAC bypass via ms-settings, AMSI bypass, a Defender exclusion spanning C:\Users, a concealed ScreenConnect client, WindowsServiceHost Run-key persistence) and a WinRing0 svcdrv64.sys miner payload. Some hosts also received UltraViewer. The VBS set was mirrored into the public user directory so newly connected endpoints inherited it — that is the worm-like part.

ConnectWise told on-prem partners they must already be on ScreenConnect 25.4 or later to jump to 26.6.5. CISA's KEV text matches the vendor: improper privilege management and missing authorization that may allow file transfer and execution through an active remote session without authorization or host confirmation. This is the fourth ScreenConnect issue CISA has flagged as exploited since 2024; two of the earlier ones were used in ransomware.

Why It Matters

RMM is supposed to be the helpdesk's scalpel. When guest file-transfer becomes unauthenticated execution on the Host, every live session is a lateral-movement bus. MSPs are the high-value target: one infected technician session can fan out into every customer who connects that day.

The social-engineering opener also matters. You can patch 26.6.5 and still lose if users install a lookalike client from a "helpdesk" call. Huntress's durable tell is in the server audit log: RunFiles / RanFiles with Process: Guest executing VBS or PowerShell.

Who Is Affected

  • ScreenConnect clients earlier than 26.6.5 (cloud and on-prem sessions)
  • ScreenConnect servers are not affected by this CVE, but they are where you hunt
  • On-prem partners still below 25.4, who cannot take 26.6.5 until they climb the upgrade path
  • MSPs and internal IT orgs that leave TransferFiles enabled for guest/technician roles
  • End users who were socially engineered into running a rogue ScreenConnect client (separate from the CVE, same campaign)

How to Protect Yourself

1. Upgrade clients to 26.6.5. Download from ConnectWise with a valid on-prem license, or allow cloud tenants to pick up the vendor push. Confirm the version on Administration → Overview before you declare the change done.

2. Until every client is on 26.6.5, disable TransferFiles on every role.

Administration → Security → Roles
Edit each role → each session group → deselect TransferFiles
(legacy: TransferFilesInSession)
Save. Repeat for every role.

3. Hunt ScreenConnect audit logs for guest-run scripts. Treat any RunFiles / RanFiles from Process: Guest as hostile, especially 1.vbs–4.vbs, runner.ps1, PyTorchFix.ps1, WindowsServiceHost.vbs / .bat.

On endpoints:

Get-ChildItem -Path C:\Users\Public, $env:TEMP, $env:USERPROFILE -Recurse -Include `
  1.vbs,2.vbs,3.vbs,4.vbs,runner.ps1,PyTorchFix.ps1,WindowsServiceHost.vbs,WindowsServiceHost.bat,svcdrv64.sys,value.txt,map.txt `
  -ErrorAction SilentlyContinue

Get-ItemProperty -Path 'HKCU:\Software\Microsoft\Windows\CurrentVersion\Run' |
  Select-Object WindowsServiceHost

Huntress also published campaign infrastructure (treat as hunting intel, it will rotate): 45.13.237.190, tele-sync.opik.net, 131.123.40.98:8041, 15.204.185.204, borertors92.anondns.net, plus rogue client ID 7a4d7d66502d4260.

4. Assume a matching host is rebuilt, not cleaned. RMM plus a kernel driver plus a Defender exclusion is not a "delete the VBS" job. Reimage, rotate local and domain credentials used on that host, and pull the rogue ScreenConnect client. Review ScreenConnect users, roles, and MFA on the legitimate server; change passwords; remove accounts you do not recognize.

5. Reduce the next RMM scam. Users should only install ScreenConnect from your branded portal. Block unknown ScreenConnect / UltraViewer outbound C2 at the edge. This is the same class of "IT support impersonation" Microsoft documented this month on Teams — train the helpdesk to never ask a user to run a second remote tool.

Source