Critical ScreenConnect Flaw Fuels Worm-Like Attacks Through Active Remote Sessions

ConnectWise has released an urgent security update for CVE-2026-84869, a critical ScreenConnect client vulnerability already being exploited in the wild.

The flaw allows an attacker to transfer and execute files through an active ScreenConnect remote session without proper authorization or host confirmation under certain conditions. Huntress has observed exploitation since August 20, including attacks that used compromised or malicious ScreenConnect clients to deliver payloads to other connected clients.

The vulnerability carries a CVSS v3 score of 9.9. CISA added it to the Known Exploited Vulnerabilities catalog on September 11, 2026, and set September 14, 2026, as the remediation deadline for US federal agencies.

ScreenConnect clients below build 26.6.5.9742 are affected

The vulnerable component is the ScreenConnect client. According to the NVD record, ScreenConnect servers are not affected by this specific security condition.

Version information is expressed at different levels of precision. ConnectWise identifies ScreenConnect 26.6.5 as the release containing the fix, while the NVD lists versions below 26.6.5.9742 as vulnerable.

Administrators should therefore verify the complete installed build rather than relying solely on the displayed feature release. The safe threshold is ScreenConnect 26.6.5.9742 or later.

The vulnerability is associated with two weakness categories:

• CWE-269 — Improper Privilege Management
• CWE-862 — Missing Authorization

Its NVD CVSS vector is:

CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H

That vector describes a network-reachable flaw with low attack complexity. Exploitation requires low privileges but no interaction from the user controlling the targeted host. The scope change indicates that successful exploitation can cross a security boundary, while the confidentiality, integrity, and availability impacts are all rated high.

ConnectWise says the corrected client strengthens session handling around file-transfer and file-execution operations.

Attackers are turning trusted sessions into propagation paths

The observed campaign begins with social engineering. Attackers persuade targets to run rogue ScreenConnect clients, establishing the initial position needed to abuse active remote-support relationships.

According to reporting based on Huntress observations, a modified ScreenConnect instance then deploys four VBScript files. Those scripts are intended to create persistence and help spread the payload to additional ScreenConnect clients.

The malicious clients check whether active remote sessions are available. When they find connected targets, the attackers use the vulnerable transfer and execution behavior to push the VBScript payloads through those sessions.

This is why the activity has been characterized as worm-like. A compromised or attacker-controlled client can use existing ScreenConnect connections to reach further systems, extending the intrusion through relationships that administrators may otherwise regard as trusted.

The description does not establish that the malware is a completely autonomous network worm. Social engineering is involved in the initial compromise, and propagation depends on active ScreenConnect sessions. Nevertheless, the ability to move from one client to other connected clients can accelerate compromise across remote-support environments.

Managed service providers, help desks, IT administrators, and organizations with dense ScreenConnect session relationships face particular operational risk. A single malicious client may become a distribution point when it encounters other active clients.

Unauthorized execution can affect entire support environments

Successful exploitation can let an attacker place and run selected files on systems associated with vulnerable ScreenConnect client sessions. The immediate outcome may include persistence, further malware deployment, or expansion into additional endpoints.

The high confidentiality rating reflects the potential exposure of data accessible from compromised systems. The integrity impact covers unauthorized modification and execution, while the availability rating accounts for the possibility of disruption or destructive activity.

No host confirmation is required in the vulnerable scenario. That characteristic reduces the opportunity for an endpoint user or technician to interrupt a malicious transfer before execution.

Remote-access software also occupies a sensitive position in enterprise networks. It connects operators, endpoints, and support infrastructure across organizational boundaries. Abusing those established channels may allow an attacker to blend malicious activity with legitimate administration and reach systems that are not directly exposed to the internet.

CISA lists ransomware use as unknown. There is therefore no confirmed basis for describing the observed ScreenConnect exploitation as a ransomware campaign.

CISA requires patching and forensic triage

CISA placed CVE-2026-84869 in its Known Exploited Vulnerabilities catalog on September 11, 2026. Inclusion confirms that the vulnerability is not merely theoretical: exploitation has been documented.

The federal remediation deadline is September 14, 2026. CISA also marks forensic triage as required under Binding Operational Directive 26-04, “Prioritizing Security Updates Based on Risk.”

Federal agencies must apply the vendor’s mitigations while meeting BOD 26-04 patching and forensic-triage requirements. They must also assess the internet exposure of affected assets. For cloud services, organizations must follow the applicable directive requirements or discontinue use when effective mitigations are unavailable.

Private-sector organizations are not bound by the federal deadline, but the same operational facts apply. Exploitation is active, propagation can occur through connected clients, and patching alone may not reveal whether a system was compromised beforehand.

No recent ConnectWise-specific KEV precedent has been identified in the available verified record. This case should therefore not be presented as part of a documented series of recent KEV additions affecting the vendor.

Patch first, then investigate active and historical sessions

Organizations should upgrade ScreenConnect clients to build 26.6.5.9742 or later. Where immediate deployment is not possible, ConnectWise recommends disabling the TransferFiles permission until the update can be completed.

A practical response should include the following steps:

1. Inventory ScreenConnect clients and exact builds. Identify every client below 26.6.5.9742, including systems managed by third parties or used intermittently for support.

2. Install the fixed release. Confirm that the resulting build meets or exceeds the NVD threshold rather than checking only for the broader 26.6.5 release designation.

3. Disable TransferFiles when patching is delayed. Treat this as a temporary mitigation, not a substitute for upgrading.

4. Review active and recent remote sessions. Look for unexpected connections, unusual session relationships, and clients communicating with systems outside normal support patterns.

5. Investigate unauthorized transfers and execution. Examine ScreenConnect activity for files pushed without an expected administrative task or host approval.

6. Hunt for VBScript-based persistence. Huntress observed four VBScript payloads, but their filenames, hashes, and other concrete indicators have not been disclosed. Defenders must therefore rely on behavioral searches, script-execution telemetry, persistence changes, and session history.

7. Inspect ScreenConnect client binaries. Unexpected, modified, or newly introduced clients may indicate the social-engineering stage or an attacker-controlled deployment.

8. Trace possible propagation. If one client appears compromised, examine every ScreenConnect client connected to it during the relevant sessions.

9. Perform forensic triage before closing the incident. CISA explicitly requires triage for covered agencies, and other organizations should preserve logs and endpoint evidence before remediation erases useful traces.

Updating removes the vulnerable condition, but it does not remove payloads already delivered through earlier sessions. Any organization running an affected build should treat patching and compromise assessment as parallel tasks.