ScreenConnect MSP Breach 2026: UK Impact and Response

What's actually happening

ConnectWise is investigating an active malware campaign that compromises ScreenConnect environments used by managed service providers and then deploys rogue remote-access clients onto the customer devices those MSPs manage, according to BleepingComputer. The observed activity appears to abuse legitimate functionality; Huntress and ConnectWise had not publicly established the initial-access mechanism, which makes the activity harder to distinguish from routine administrative traffic.

Cybersecurity firm Huntress first reported the campaign on 11 November 2026 and, at that time, had identified six compromised MSPs, 286+ affected endpoints and 47 impacted organisations, with the numbers still climbing — this is a reporting snapshot, not necessarily the date the broader compromise began. ConnectWise separately disabled five third-party ScreenConnect extensions across approximately 400 partner environments as a precaution, though the presence of these extensions alone does not establish compromise, and investigators had not confirmed they are the entry point.

Why UK buyers should treat this as their problem, not their MSP's

RMM platforms exist precisely because they give one console centralised administrative reach across many customer networks at once. That concentration is the entire value proposition of outsourced IT management — and it is exactly what turns a single compromised MSP account into simultaneous, parallel access across every tenant it touches. If your organisation's endpoints are managed through ScreenConnect, directly or via a nested MSP relationship, you are inside the exposure window whether or not your own systems show an alert yet.

Huntress has also flagged a second propagation route that UK buyers often overlook: a technician's own workstation can reportedly be compromised the moment they open an interactive ScreenConnect session with an already-infected customer device. That reverses the usual assumption that support sessions only carry risk one way, from technician to customer.

Third-party extensions are a suspected component, but the entry point remains unconfirmed

ConnectWise said it had found no evidence that its own infrastructure was compromised or that ScreenConnect itself was vulnerable. The suspicion centres on five independent, third-party extensions — Labtech Plus, RMM Plus, RMM+, RMM Plus Password Link and RMM+ Password Link — installed through ScreenConnect's built-in Extensions marketplace, with one or more of these extensions installed in approximately 400 partner environments. A separate claim that two specific RMM+ versions accept a blank access key where none has been configured has been reported elsewhere but is not confirmed by the primary ConnectWise or Huntress advisories reviewed here, and is omitted pending direct sourcing.

This distinction matters for buyers running due diligence: it reframes the incident less as 'is ScreenConnect safe' and more as 'what has our MSP bolted onto it, and did anyone check the access-key configuration before going live.' On-premises ScreenConnect customers were told they must disable the flagged extensions manually — ConnectWise cannot do this remotely for self-hosted environments — so any UK MSP running on-prem needs to confirm this has actually happened, not assume it.

The audit UK buyers should demand this week

Disabling the extension may prevent further abuse through that extension, but it does not establish containment or eradication, nor does it prove an endpoint is clean. Huntress has warned that sequential attacker-assigned tags suggest other MSPs may have been compromised earlier than currently known, meaning organisations that have received no alert should still check their history.

• •Confirm which ScreenConnect extensions are installed, their version numbers, and whether access keys are properly configured — not left blank
• •Review available historical records for the longest practicable period, including Run Command history, Toolbox records, authentication logs and administrative activity, even without an active alert
• •Match outbound connections and client IDs against published indicators — attacker infrastructure, rogue client IDs and C2 domains — across DNS, proxy, firewall and EDR logs
• •Check every managed endpoint for unexpected ScreenConnect installer activity, scheduled tasks, services and local accounts, not just the MSP console
• •Avoid opening interactive ScreenConnect sessions with any suspect device until it has been assessed out-of-band

Rotate credentials in the right order

Credential rotation needs to follow trust boundaries, not a blanket reset. As a recommended staged response, responders should prioritise credentials that could still provide attacker access: typically starting with ScreenConnect and extension access keys, then MSP technician credentials, service accounts and API tokens, and finally any customer administrative credentials reachable from the platform — but the correct order depends on the organisation's actual trust relationships and the evidence gathered. Active sessions and tokens should be revoked, MFA enforced universally, and dormant accounts removed, with evidence preserved before changes are made. Getting this right is squarely the territory of identity and access management discipline applied under pressure, and it should be tested as part of routine incident response planning rather than improvised mid-incident.

The wider RMM risk UK procurement teams can't ignore

This is not an isolated event in the RMM category. A separate incident saw N-able take its hosted N-central environments offline after more than 30 alleged zero-day vulnerabilities — including authentication bypass, credential disclosure and remote code execution issues — were published. N-able reported the release of hotfix N-central 2026.4 HF2 on 11 November 2026, addressing some of the most critical issues, after earlier urging on-premises customers to take vulnerable servers offline amid reports of internet scanning.

The incidents illustrate the potential blast radius of centralised RMM access; they do not by themselves establish a common cause or sector-wide trend. UK buyers renewing or tendering MSP contracts should still consider pushing evaluation criteria beyond feature lists — recommended buyer requirements to weigh include tenant isolation, immutable audit logs, granular role-based access, per-tenant credentials, rapid extension revocation and tested recovery procedures, ideally benchmarked against a recognised security or procurement framework. Strengthening endpoint security defences and considering independent endpoint monitoring or managed detection & response — subject to validating its separation from the MSP's RMM administration — can provide an additional check rather than relying solely on the vendor's own console.