ScreenConnect CVE-2024-1709: how an RMM server became a remote entry point

As of February 19, 2024, self-hosted ConnectWise ScreenConnect servers had to be updated to at least version 23.9.8. That day ConnectWise disclosed CVE-2024-1709 — an authentication bypass in the ScreenConnect server component in versions 23.9.7 and below — and released a fix for on-premises installations. On February 22, CISA added the vulnerability to its Known Exploited Vulnerabilities catalog with a status of active exploitation. The official record rates it 10.0 on CVSS v3.1: exploitable over the network, without an account and without user interaction (ConnectWise, security bulletin of February 19; CVE-2024-1709, CISA-CG record).

This was a defect in the remote access server, not in the ScreenConnect agents on endpoints. But the purpose of that server defined the consequences: after bypassing authentication, an attacker could create an administrator and then use the built-in extension system to execute .NET code as SYSTEM on the server itself. The vulnerability did not turn every agent into an automatically compromised device, yet it did hand over administrative control of a central RMM component (Huntress, technical breakdown).

Step 0. The server was visible from the internet

Before any exploitation, there was a signal available to outside observation: a public ScreenConnect server and its version. On February 19, Huntress reported that a Censys search showed more than 8,800 reachable servers running a vulnerable version. That number refers to visible vulnerable instances at a specific moment, not to confirmed breaches (Huntress, vulnerability reproduced on February 19).

The practical value of this observation is limited, but real. External discovery of a service does not prove exploitation and does not establish which systems sit behind it. What it does establish is different: the organization is publishing an RMM component whose version needs to be checked and updated. This step is possible before any attack logs exist and before a rogue account is created.

This is where an RMM server differs from an arbitrary web application in terms of what a takeover means. The sources do not confirm an automatic path from the server to every managed device. They do confirm that ScreenConnect's own administrative features are designed for remote management and for extending what the server can do. An externally reachable RMM instance therefore has to be counted as a perimeter asset in its own right, not merely as a web page with a login form.

Step 1. An alternate path bypassed the access check

CVE-2024-1709 is classified as CWE-288 — authentication bypass using an alternate path or channel. In the chain Huntress reproduced, a path segment was appended to the URL of an already configured server, after which the SetupWizard.aspx page became reachable. That page was meant for initial setup, yet it opened on a live server without the usual authentication check (CVE-2024-1709, description and CWE; Huntress, breakdown of the bypass).

This stage required no valid credentials. The official CVSS assessment likewise indicates no privileges required, no user interaction, a network vector and low attack complexity. It follows that multi-factor authentication for legitimate administrators did not, on its own, break the demonstrated chain: the attacker was not signing in under an existing account but reaching the setup wizard by a different route.

The boundary of this conclusion is precise. The CVE gave a bypass of the access check on the server component. It was not a defect in the ScreenConnect agents and it did not mean that passwords of working administrators were stolen. The ConnectWise bulletin states directly that agents are not directly affected; remediating the two disclosed vulnerabilities did not require updating them.

Step 2. The setup wizard created a new administrator

After opening SetupWizard.aspx, Huntress researchers were able to complete the wizard and create a new administrative user. By their description, the previous local user database was overwritten in the process (Huntress, technical breakdown).

At this step the nature of the risk changed. Before it, there was unauthenticated access to a setup function. After it, the attacker held an administrative account created by the application's own means. Subsequent actions could look like an administrator using permitted features, even though the right to use them had been obtained through a vulnerability.

Huntress also names a change to User.xml as one possible artifact. The researchers separately caution, however, that changes to this file occur during normal activity. Such an artifact on its own does not prove compromise; it has to be correlated with timing, context and other events (Huntress, detection guidance).

Step 3. A built-in extension ran code as SYSTEM

Having obtained administrative access, the researchers used the Extensions feature. Through it they could upload an extension that executed .NET code as SYSTEM on the server. Huntress stresses that this execution mechanism is a legitimate administrative capability of ScreenConnect, not the substance of CVE-2024-1709 (Huntress, chain through to code execution).

This distinction matters when assessing the incident. The vulnerability broke an authentication boundary. Code execution became possible because the administrator created through the bypass gained access to a powerful built-in feature. In other words, the damage was defined not only by the technical class of the CVE, but by the permissions of the role the defect allowed someone to create.

At the same time, ConnectWise disclosed CVE-2024-1708 — a path traversal rated 8.4 on CVSS. According to the Huntress analysis, exploiting that defect on its own required an administrative account and access to Extensions. The code execution chain the researchers demonstrated did not require CVE-2024-1708: the administrative access obtained through CVE-2024-1709 already allowed use of the built-in extension mechanism.

For that reason, the phrase "the RMM server became a remote entry point" applies only to the takeover of the remote administration server itself. Public sources do not establish that every reachable server was breached, that every server taken over led to the compromise of all connected devices, or that the exploitation belonged to a single campaign.

Step 4. A fix existed, but acting on it depended on the hosting model

An independent researcher reported two potential vulnerabilities to ConnectWise on February 13, 2024. The company confirmed them on February 14 and, on February 19, published a bulletin and an update package for on-premises customers. Versions 23.9.7 and below are listed as affected; 23.9.8 is the minimum fixed version (ConnectWise, disclosure timeline; official CVE record).

For the screenconnect.com and hostedrmm.com cloud environments, ConnectWise stated that the issue was resolved without partner action and that the risk was mitigated within 48 hours. Self-hosted servers required an immediate update by the owner of the instance. The company later provided an interim patch on the 22.4 branch for customers who were no longer under maintenance.

The lesson for perimeter control is not that cloud hosting is always safer. The sources do not establish that. The difference here is operational: in a vendor-managed environment the vendor applied the fix, while for a self-hosted instance the action depended on whether the organization knew about the server, its owner and the installed version.

What should have worked earlier

The first control is an inventory of internet-reachable assets. If external accounting is limited to VPNs and firewalls, a self-hosted ScreenConnect may fall outside the same process even though it remains a publicly reachable server. The Huntress observation via Censys shows that the presence and version of such instances could be determined from the outside as early as February 19.

The second control is continuous version checking. A one-off inventory would establish that the server exists, but not that its risk changed once the bulletin was published. From February 19, the verifiable condition became running version 23.9.8 or higher, or the applicable interim fix. In on-premises environments this required action by the owner.

The third control is prioritization by exploitability, not by the CVSS number alone. In this case both signals aligned: CVSS 10.0 and a network authentication bypass without credentials. On February 22 an additional confirmed signal appeared — the KEV listing with a status of active exploitation. In practice the requirement is that such a server should not sit in the general queue of web vulnerabilities: a successful bypass immediately created an administrative context from which code execution as SYSTEM was available.

ConnectWise later published three IP addresses that, according to its data, were used by attackers: 155.133.5.15, 155.133.5.14 and 118.69.65.60. These indicators are usable for log review, but they do not replace version control: they are not attributed to a specific group and do not represent a complete list of exploitation sources (ConnectWise, updated bulletin).

The early text of the bulletin reported no evidence of exploitation in real-world attacks. That assessment applies to the moment of initial publication. From February 22, the later CISA status applies — active exploitation. Public materials do not say which specific cases formed the basis for the KEV listing.

Where the chain could have been broken

Each line below pairs a requirement, with the date it took effect, and the action that answers it.

• Before exploitation: count a public RMM server as an external asset — discover internet-reachable ScreenConnect instances alongside VPNs, firewalls and other remote access components; record the owner and the version
• From February 19, 2024: remediate CVE-2024-1709 and CVE-2024-1708 on self-hosted ScreenConnect — update the server to version 23.9.8 or higher, or apply the vendor-provided fix for the supported branch
• From February 19, 2024: separate the vulnerable server from the general patch queue — prioritize it by network exploitation without credentials and by the possibility of obtaining administrative access
• From February 22, 2024: account for confirmed active exploitation per CISA KEV — raise the urgency of the update and review server logs, administrator creation, User.xml changes and use of Extensions; do not treat a single artifact as proof of a breach on its own
• After a vulnerable external instance is identified: keep checking reachability and version continuously until remediation is confirmed, because discovering an asset once does not confirm that the fix was installed
• When assessing consequences: verify the server takeover and the subsequent actions separately; do not treat agents or all managed devices as automatically compromised