CVE-2024-1709 — ConnectWise ScreenConnect auth bypass

TL;DR: ConnectWise ScreenConnect (remote-support / RMM) shipped an installation wizard endpoint at /SetupWizard.aspx that remained reachable on already-installed instances. Anyone hitting the URL was treated as a fresh-install admin and could create a new administrator account. With admin, the attacker could install a remote-command plugin and execute arbitrary code on every endpoint managed by the ScreenConnect server. Disclosed February 2024; pre-auth → SaaS-wide RCE in two HTTP requests. Companion to broken-access-control and reading-public-pocs-effectively.

Why this matters

One of the most consequential bugs of 2024 in breadth — a single ScreenConnect server compromise enabled access to every managed-endpoint downstream (MSPs typically manage hundreds of customer environments).
Root cause is path-based access control failure — easy to teach.
Patch is a few lines — easy to diff and learn.
Exploited within hours of disclosure by multiple ransomware crews.

The bug

SetupWizard.aspx is intended for first-run setup. Logic was supposed to gate the endpoint with “is the system already configured” check. Implementation: the gate was applied via path string comparison that could be bypassed by trailing path components.

Pseudo-shape:

  
if (request.Path == "/SetupWizard.aspx") {
    // ... blocked once configured
}

But ASP.NET routing accepted /SetupWizard.aspx/anything as the same handler. The literal-string compare failed; the handler still ran. The handler treated the requester as a first-run admin.

The exploit

Two requests:

POST /SetupWizard.aspx/anything with body containing the new admin username + password and the “wizard step” parameters.
Log in as that admin.

Once admin: install a remote-command extension; push commands to every managed endpoint. Full takeover.

The patch shape

Switched from string-compare path matching to a runtime gate flag persisted at first-run completion. New requests check the flag; if set, all SetupWizard.aspx traffic is rejected regardless of path suffix.

Lesson: state, not URL, should gate first-run logic.

Mass exploitation

Within 48 hours of disclosure:

Black Basta and Bl00dy ransomware variants were deployed via compromised ScreenConnect.
Many MSPs had to assume every downstream customer was compromised.
Cloud-hosted ScreenConnect instances were also affected unless the cloud vendor pre-patched.

The blast radius taught the industry to treat RMM compromise as a customer-wide incident.

Workflow to reproduce

Spin up vulnerable ScreenConnect 23.9.7 or earlier.
Complete first-run normally to simulate a production instance.
Send the path-trailing-suffix POST.
Observe new admin creation.
Log in, install a remote-command extension, send a command to a connected endpoint.

Public PoCs (Huntress, watchTowr, others) landed the day of disclosure.

Detection and IR

Audit logs for SetupWizard.aspx requests after first-run completion.
New admin user accounts in the ScreenConnect User table.
New extension installations.
Commands pushed to endpoints in the same hour as admin creation.

If compromise confirmed: assume every managed endpoint is compromised; treat as MSP-wide incident.

Affected versions

ScreenConnect 23.9.7 and prior.

Fixed in 23.9.8.

Lessons

Path equality is not a security gate. Use middleware that normalises and matches handlers, then re-checks state.
First-run code paths are high-risk. They have the highest privilege of any code path and are tested the least.
RMM tools are the highest-impact pivot in any environment. Treat them like domain controllers.
MSP environments are a single-point-of-failure for downstream customers; segregation and break-glass for RMM compromise should be in runbooks.

CVE-2024-1708 (ScreenConnect path traversal) — disclosed in the same advisory.
The ConnectWise advisory is a good case of bundling two bugs of disparate severity into one patch. Always read for the other CVE in the advisory.