ScreenConnect client bypass CVE-2026-84869 actively exploited with worm-like spread

A missing authorization check in the client

ConnectWise disclosed CVE-2026-84869 in an advisory on 3 September 2026 and shipped the fix in ScreenConnect 26.6.5 five days later, on 8 September, according to a dev.to analysis of the incident. The flaw is a missing authorization check, classified under CWE-269 and CWE-862, in the ScreenConnect client's file transfer handling. ConnectWise scored it 9.9 out of 10.

The practical effect: inside an active remote session, a file transfer started from the technician's side can skip the Host confirmation prompt and execute directly on the target machine. Only the client is affected, at versions below 26.6.5. The server is not affected by the bug, which means an estate that upgrades its ScreenConnect servers but leaves old clients deployed remains fully exposed.

Exploitation with self-propagating behaviour

According to Huntress reporting cited in the write-up, the flaw has been used in real intrusions. In late August the security firm said it had found, across several organisations, ScreenConnect clients that had been installed without authorisation as well as clients that had been tampered with. The malicious activity repeatedly spawned wscript.exe to run four malicious VBScripts.

More striking is the propagation. The dev.to analysis notes that the activity could push itself onto endpoints that newly connected to the same ScreenConnect instance, giving it worm-like behaviour within a fleet of managed machines. Remote monitoring and management platforms are a natural target for this kind of abuse precisely because administrators deliberately grant them sweeping execution rights.

CISA listing and deadline

CISA added CVE-2026-84869 to its Known Exploited Vulnerabilities catalog and set a remediation deadline of 14 September. The exact listing date is inconsistent across records: the write-up observes that some listings show 10 or 11 September while others show 12 September.

What administrators should do now

The dev.to write-up lays out a response plan:

• Inventory the ScreenConnect client version on every managed endpoint, not just on the servers, and upgrade anything below 26.6.5.
• As a temporary control, clear the TransferFiles permission for each role under Administration, then Security, then Roles. ConnectWise cautions that this does not replace the upgrade.
• Hunt for signs of compromise: wscript.exe processes spawned by the ScreenConnect client, client installations that no change record explains, and client binaries whose hashes do not match a known vendor build.
• Review session records for file transfers that completed without a matching host approval event.

Why it matters

RMM tooling sits deep inside the trust boundary of most corporate estates, and MITRE ATT&CK tracks this style of intrusion under technique T1219. When the management tool itself becomes the target, the privileges that make administrators efficient are exactly what allows an intrusion to stay quiet. The ScreenConnect incident is a reminder that client-side components need the same version tracking and patching urgency as the servers they connect to: a patched server fronting a fleet of vulnerable clients is still an open door, and the KEV deadline signals that regulators expect the cleanup to reach every endpoint, not just the data centre.