ConnectWise has warned customers about a newly identified security issue affecting file-transfer behavior in ScreenConnect Remote Access Support and Access sessions. The vulnerability affects both cloud-hosted and on-premises deployments, but at the time of disclosure it had not yet received a CVE identifier and ConnectWise had not released a permanent fix. Instead, the company has provided an interim mitigation requiring administrators to disable file-transfer permissions for affected user roles until a patched release becomes available. ConnectWise says an official CVE and fix will be issued within the week. The fact that the vendor is recommending removal of a core remote-support capability before the full technical details are public suggests that organizations should treat the issue seriously rather than wait for a severity score to appear in a vulnerability scanner. 

The vulnerable feature is especially sensitive because ScreenConnect is a remote-access platform used by managed service providers, internal IT teams and support organizations to troubleshoot systems, transfer files, execute administrative operations and maintain endpoints. File transfer is not an incidental feature in such a platform. It represents a direct path between a technician’s management environment and the remote system being controlled. Any weakness in how that functionality authorizes, scopes or validates transfers can potentially cross an important trust boundary. ConnectWise has not yet publicly described the exact exploit mechanics, so it would be premature to claim whether the issue allows arbitrary file upload, unauthorized download, privilege escalation or another specific outcome. What is known is that ConnectWise considers disabling file-transfer permissions sufficient to reduce the immediate risk while the permanent fix is being developed.

That distinction is important because vulnerability management sometimes becomes excessively dependent on CVE identifiers and CVSS scores. Neither exists yet for this issue, but the absence of those labels does not mean the vulnerability has no operational significance. The vendor has already identified a security weakness, both cloud and on-premises systems are affected, and administrators have been given an explicit mitigation. Organizations should act on those facts rather than waiting for a database entry to give the problem a number. A CVE is useful for tracking a vulnerability; it is not what makes the vulnerability real.

ConnectWise’s interim mitigation requires administrators to open the ScreenConnect Administration console, navigate to Security and Roles, edit the relevant roles and session groups, and remove the `TransferFiles` permission or the legacy `TransferFilesInSession` permission. The change needs to be repeated anywhere that permission has been assigned. This is a meaningful operational trade-off because technicians may legitimately rely on file transfer to deliver troubleshooting tools, configuration files or software to remote users. But temporarily losing convenience is considerably preferable to retaining a potentially vulnerable privileged transfer mechanism on an internet-accessible remote-management platform.

The situation is particularly important for MSPs because one ScreenConnect environment may provide administrative access to large numbers of independent customer networks. A security weakness in the central support platform can therefore create concentration risk. Attackers do not necessarily need to compromise each managed customer individually if they can instead exploit the infrastructure used by technicians to administer all of them. This is the same reason RMM and remote-access tools continue to attract ransomware operators and state-backed actors: their legitimate functionality already provides remote execution, privileged access and broad endpoint reach.

ScreenConnect has repeatedly demonstrated that attacker interest is not theoretical. In 2024, ransomware groups and the North Korean Kimsuky threat group exploited CVE-2024-1709, a ScreenConnect authentication-bypass vulnerability, to compromise vulnerable servers and deploy malware. In 2025, ConnectWise disclosed a separate incident in which a suspected state-sponsored actor exploited CVE-2025-3935, a high-severity ViewState code-injection flaw, and gained access to a limited number of ScreenConnect cloud customers. Earlier in 2026, ConnectWise patched CVE-2026-3564, a cryptographic signature-verification weakness that could allow attackers to hijack unpatched instances. CISA has added multiple ScreenConnect vulnerabilities to its Known Exploited Vulnerabilities catalog over the past several years.

This history matters because remote-access platforms are not obscure internal utilities waiting for attackers to notice them. They are already established targets. Public disclosure of a new weakness therefore creates an immediate research race. Even without complete technical details, attackers can begin examining ScreenConnect’s file-transfer implementation, comparing behavior across releases and testing permission boundaries. Once the vendor publishes a patch, binary or code comparison may further accelerate reverse engineering of the underlying flaw.

Nearly 6,000 ScreenConnect instances are currently visible on the public internet according to Shadowserver data cited by BleepingComputer, although that figure includes systems whose actual vulnerability or mitigation status is unknown. That exposure is significant because remote-management systems are particularly dangerous when universally reachable. Organizations should use this disclosure as an opportunity to reconsider whether their ScreenConnect administrative interface genuinely needs unrestricted internet accessibility.

Where practical, administrative access should be placed behind VPN, zero-trust access infrastructure or restrictive source allowlists. Multi-factor authentication should remain mandatory even though the present vulnerability has not yet been described as an authentication flaw. Strong identity controls reduce the number of alternative attack paths available if another weakness is discovered. Remote-access systems should ideally be reachable only from known administrator networks or authenticated management pathways rather than from every address on the internet.

Role design also deserves review. The temporary mitigation specifically involves removing a permission from ScreenConnect roles, which highlights the importance of least privilege within administrative platforms. Not every technician necessarily requires file-transfer capability for every customer or session group. Permissions should reflect operational requirements instead of accumulating indefinitely because they were convenient during initial deployment. Even after the vulnerability is fixed, organizations may decide that broad file-transfer privileges were unnecessary in the first place.

For MSPs, tenant separation is especially important. A technician account or compromised role should not automatically provide identical privileges across every managed customer environment. Customer groups should be isolated wherever ScreenConnect’s permission model permits, and especially sensitive systems should require stronger controls or dedicated administrative roles. The objective is to reduce the blast radius if one account, role or platform feature is abused.

Logging should also receive attention while the permanent patch is unavailable. Administrators should review ScreenConnect audit logs for unusual file-transfer activity, particularly transfers initiated by unexpected accounts, transfers involving unfamiliar file names or executable content, and activity occurring outside normal support periods. Where possible, ScreenConnect telemetry should be forwarded to an external SIEM rather than retained solely on the ScreenConnect server. If the management platform itself is ever compromised, independent logs provide a much more trustworthy forensic record.

Organizations should also monitor downstream endpoints. A suspicious file arriving through ScreenConnect may be harder to identify than one downloaded through a browser because endpoint security products may regard the remote-management agent as trusted software. Defenders should therefore correlate ScreenConnect activity with endpoint telemetry. A legitimate ScreenConnect process writing an executable and immediately spawning a new service, PowerShell session or unknown process should not be assumed safe merely because the initial transfer occurred through authorized remote-support software.

This illustrates a wider problem with dual-use management tools. Software such as ScreenConnect, N-central and other RMM platforms performs actions that look almost identical to attacker activity because administrators and attackers ultimately want many of the same capabilities: remote execution, software deployment, file transfer and system configuration. Detection therefore cannot rely on the tool name alone. It needs to understand whether the action was expected, approved and consistent with the identity performing it.

Organizations should also ensure that ScreenConnect itself runs on a hardened host with minimal additional software. Administrative platforms should not share servers with unrelated public applications or general-purpose workloads. Privileged service credentials should be tightly controlled, operating-system patches should be current and unnecessary outbound access should be restricted. If an attacker eventually discovers a way to turn the file-transfer flaw into deeper platform compromise, these surrounding controls can limit what becomes possible next.

The absence of a permanent patch creates another useful incident-response question: should organizations disable ScreenConnect entirely? For environments heavily dependent on remote support, that may create unacceptable operational disruption. ConnectWise’s own guidance currently recommends disabling the vulnerable file-transfer capability rather than shutting down the product, so that is the more proportionate immediate response based on the evidence available today. Organizations with exceptionally sensitive systems or very limited need for ScreenConnect may choose stricter isolation until the vendor publishes the fix, but that decision should be based on their exposure and operational requirements.

Once the patch is released, administrators should not simply re-enable file transfers and consider the incident finished. They should first verify the fixed version, review ConnectWise’s final advisory and determine whether exploitation indicators or retrospective compromise checks are recommended. If the vendor later confirms active exploitation, any internet-exposed system that retained vulnerable file-transfer permissions during the exposure period should be investigated before assuming the patch alone restored trust.

The disclosure also provides a useful reminder about temporary mitigations. Security teams sometimes hesitate to implement a workaround because it affects functionality and prefer to wait for the cleaner vendor fix. That preference is understandable during ordinary vulnerabilities. It becomes much harder to justify when the vendor explicitly says a security-sensitive feature should be disabled until remediation becomes available.

A compensating control does not have to be elegant.

It has to reduce the attacker’s opportunity.

The broader lesson from this ScreenConnect issue is therefore not merely that another remote-access vulnerability has appeared.

It is that privileged management platforms need enough security flexibility to survive the period between vulnerability discovery and patch availability.

When the fix does not yet exist, least privilege, restricted exposure, feature reduction, independent logging and network segmentation become the patch.

And for an RMM platform capable of reaching thousands of machines, waiting passively for the official update is a considerably larger gamble than temporarily disabling file transfer.

ConnectWise has shared temporary mitigation measures for a new ScreenConnect Remote Access vulnerability that it plans to patch later this week. [...]

Source: ConnectWise warns of new ScreenConnect flaw without patch via Bleeping Computer — published 07 Sep 2026.