CVE-2026-84869 is an actively exploited flaw in the ScreenConnect client, not the ScreenConnect server. That distinction matters: an organisation can have a properly administered remote-support server and still expose people using its client software during an active session.
ScreenConnect is ConnectWise remote-support and remote-access software. Managed service providers, internal IT teams, enterprise service desks and technical-support groups use it to view or control endpoints, run diagnostics and commands, move files, and support attended or unattended machines. It is available as a ConnectWise-hosted service and for on-premises deployment, so exposure spans organisations running support desks in government, education, retail, technology and financial services as well as MSP customer estates.
A connected guest can cross the session boundary
In ScreenConnect terminology, the Host is ordinarily the technician-side participant and the Guest is the remote endpoint. CVE-2026-84869 is a missing-authorization and improper-privilege-management condition in the client’s handling of file-transfer and file-execution actions. Under circumstances ConnectWise has not publicly explained, a Guest can transfer a file through an existing remote session and have it executed on the connected Host without proper authorization or the Host’s confirmation.
An attacker therefore needs a foothold as the Guest in an active ScreenConnect session; this is not described as unauthenticated internet-side compromise of a ScreenConnect server. But that prerequisite can be realistic when attackers persuade a victim to install an attacker-controlled or modified client. The vendor assigns a 9.9 CVSS score, while its September 8 bulletin calls the remediation priority “1 – High.” The bulletin says the update strengthens client and session handling, but does not identify the faulty function, authorization check, or the conditions that trigger the bypass.
Exploitation followed social engineering
Exploitation in the wild is confirmed: CVE-2026-84869 entered CISA’s Known Exploited Vulnerabilities catalogue on September 11, with a federal remediation deadline of September 14. Its KEV record lists ransomware-campaign use as unknown.
The reported campaign is particularly useful for hunting because it shows how the flaw can turn a remote session into a propagation path. Investigators found modified clients that watched for Host connections, registered staged VBScript files with ScreenConnect’s transfer mechanism, selected the Run action, and queued execution on the Host. The documented incidents began with social engineering—such as Quick Assist abuse, likely phishing, and a fraudulent refund form—not this flaw as initial access. No named actor or total victim count has been published.
No public standalone proof of concept or general-purpose exploit implementation could be verified as of September 12, and no vendor patch diff or source-code fix is public. That absence should not reduce urgency: operationally modified clients have already demonstrated the behavior.
Patch clients and review sessions
ConnectWise says every ScreenConnect version before 26.6.5 is affected; upgrade on-premises deployments to 26.6.5 or later. Cloud deployments were updated automatically, but ConnectWise still recommends reinstalling cloud Host clients and updating access agents. On-premises environments must already be on 25.4 or later for the direct upgrade path, and should verify every client and agent rather than treating a server update as sufficient.
If patching cannot happen immediately, remove TransferFiles from every relevant role and session group; legacy releases call it TransferFilesInSession. ConnectWise says that is temporary mitigation, not a replacement for the update. Hunt for unexpected ScreenConnect client installs, suspicious wscript.exe activity, staged VBScript files, queued transfer-and-run actions, and sessions involving unrecognised Guests.
Treat remote-support clients as privileged software, because here a session participant can become an execution path into the technician side. SecAlerts monitors an organisation’s actual software stack and alerts on new vulnerabilities affecting the products it runs; use that visibility alongside asset checks and session review to make sure the client fleet, not merely the server, is remediated.
