CVE-2026-84869: Worm-like VBScript Campaign Targeting ScreenConnect Clients

The critical vulnerability CVE-2026-84869 (CVSS 9.9) in the client components of ConnectWise ScreenConnect is being actively exploited for worm-like propagation of malicious VBScript chains. According to Huntress research, at least three independent incidents were recorded in August 2026 in which compromised ScreenConnect clients automatically delivered a malicious payload to every newly connected system. All ScreenConnect versions prior to 26.6.5 are affected — both cloud and on-premises deployments. Organizations using ScreenConnect must immediately update or disable the file transfer feature.

The vulnerability and scope of the issue

According to the official ConnectWise disclosure, CVE-2026-84869 describes a flaw in file transfer handling on the ScreenConnect client side. The vulnerability makes it possible to transfer and execute files over an active remote session without proper authorization or confirmation from the host, including actions with elevated privileges. The CVSS 3.1 score is 9.9 Critical (vector: AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H), indicating a network-based attack vector with low complexity and no need for user interaction.

An important clarification: the ScreenConnect server component is not directly affected. ConnectWise cloud servers have already been updated, but client agents (host clients and access agents) still require updating. On-premises deployments must be upgraded to version 26.6.5 or later.

Attack mechanism: four-stage VBScript chain

Huntress observed three incidents with different initial access methods but an identical subsequent infection chain:

• Quick Assist scam (20 August 2026) — social engineering under the guise of technical support led to the installation of a fake ScreenConnect client that connected to a C2 server at 45.13.237[.]190 (domain tele-sync.opik[.]net).
• Phishing MSI installer (20 August 2026) — the file ScreenConnect.ClientSetup.msi, presumably delivered via phishing, deployed a client that communicated with 131.123.40[.]98 on port 8041.
• Fake Geek Squad refund form (24 August 2026) — the user downloaded ScreenConnect.Client.exe, which connected to borertors92.anondns[.]net.

In all cases, after the fake ScreenConnect client was installed, the system began repeatedly launching wscript.exe to sequentially execute four VBScript files:

• 1.vbs — profiles the host: checks the amount of RAM (threshold — 5 GB), checks for installed ScreenConnect, enumerates security solutions (Cisco AMP, CrowdStrike, Huntress, Malwarebytes, SentinelOne, Sophos, Symantec Endpoint Protection). The result is written to %TEMP%\value.txt as a three-bit state variable.
• 2.vbs — waits for the value.txt file, verifies that the word “abort” is absent, and downloads a file from Dropbox whose contents are decoded into %TEMP%\map.txt.
• 3.vbs — based on the state value from value.txt, downloads the corresponding payload from a link in map.txt and writes it as %TEMP%\out.enc.
• 4.vbs — launches the PowerShell script runner.ps1, which decrypts out.enc, writes the result to %APPDATA%\Microsoft\Windows\Templates\Classic\sys_cache.zip, and executes the secondary script PyTorchFix.ps1.

Adaptive payload

The three-bit state value determines which toolkit will be delivered to the compromised system:

• 000 / 001 — user-level ScreenConnect backdoor.
• 010 — tools for privilege escalation via UAC bypass (using substitution of the ms-settings protocol handler and ComputerDefaults.exe), AMSI bypass, adding broad exclusions in Microsoft Defender, and installing a hidden ScreenConnect client.
• 011 — tunneling utilities and the XMRig cryptominer (disguised as SearchIndex.exe), with Defender reporting disabled, Memory Integrity (HVCI) protection turned off, and use of the vulnerable driver svcdrv64.sys (WinRing0).

Worm-like propagation

The key feature of this campaign is its self-propagation mechanism. After a host is compromised, the modified ScreenConnect client packages and executes the four-stage VBScript chain on every new connection. When the state value is 010 or 011, the 4.vbs script copies the VBScript files to C:\Users\Public\Libraries\Default\Lib\Lib1, turning the infected system into a malicious code delivery mechanism.

The system tracks connection IDs (ConnectionID) so as not to attack the same active session repeatedly. However, once a connection is closed, its ID is removed — a reconnection triggers the infection again. This creates a persistent spread cycle across the ScreenConnect infrastructure, although it should be emphasized: this is not autonomous self-replication, but propagation via ScreenConnect’s connection and file transfer mechanism.

Indicators of compromise

According to Huntress, the following network indicators were recorded:

• IP addresses:45.13.237[.]190, 131.123.40[.]98, 146.59.55[.]107, 45.32.192[.]150, 15.204.185[.]204
• Domains:tele-sync.opik[.]net, borertors92.anondns[.]net, homehub.opik[.]net
• Registry key:HKCU\Software\Microsoft\Windows\CurrentVersion\Run → WindowsServiceHost
• Characteristic files:WindowsServiceHost.vbs, WindowsServiceHost.bat, PyTorchFix.ps1, SearchIndex.exe, svcdrv64.sys, Themes.exe

Additional remote management tools, including UltraViewer, were also found on some compromised hosts. Attribution of the campaign to a specific group has not been established at this time.

Response recommendations

Priority actions for organizations using ScreenConnect:

1. Update ScreenConnect to version 26.6.5 or later (Huntress recommends 26.6.6). This remediates CVE-2026-84869.
2. Temporary measure before updating: disable the TransferFiles permission (or TransferFilesInSession for legacy versions) for all roles under Administration → Security → Roles.
3. Review ScreenConnect audit logs for RunFiles or RanFiles entries executed by the Guest process that launch suspicious scripts.
4. Check for indicators of compromise: the WindowsServiceHost registry key, the files value.txt, map.txt, out.enc in the %TEMP% directory, and sys_cache.zip in the Templates directory.
5. Compromised hosts — Huntress strongly recommends full redeployment from a known-good image or a clean operating system installation.

The combination of a critical 9.9 CVSS score, confirmed exploitation in real-world attacks, and a self-propagation mechanism makes this vulnerability one of the highest priorities for immediate remediation. Organizations with deployed ScreenConnect instances should treat upgrading to version 26.6.5+ as an emergency task, and upon detecting any of the described indicators, move to full redeployment of affected systems rather than attempting in-place “cleanup.”