For: organizations that use ScreenConnect (especially managed service providers and IT teams that manage customers' devices) and the customers of those providers. This article is an explainer based on ConnectWise's official advisory and does not cover attack steps or indicators of compromise.
Developing: this article will be updated as the organisation publishes more
- Who is affected
organizations that use ScreenConnect (especially managed service providers and IT teams that manage customers' devices) and the customers of those providers.
- Confirmed so farSee the table ↓
- Partner environments with an RMM+ family extension installed
- Precautionary disabling
- Rogue client installs in the investigating security firm's customer environments
Listed as possibly affected
- Abuse of third-party extensions as the way in
- Not yet confirmed
- How attackers first got in (the company says it has not been established)
- The full scope: which partner and customer environments were affected (the company has no visibility after initial access)
- The final assessment of the third-party extensions (the company is still validating)
1 more
- Further guidance on the disabled extensions (the company says not to re-enable them pending further guidance)
- What to do nowSee the steps ↓
- Check that the listed extensions are disabled and keep them disabled
- Update every technician client to 26.6.5 or later
- Reduce the Transfer Files permission while updates are pending
4 more
- Revoke sessions and reset credentials from a trusted device, with MFA
- Investigate with separate tools and preserve logs
- Watch for unusual sign-ins and unapproved remote-access software
- Customers of a managed service provider: ask your provider
- Where to verify (source)All sources ↓
- ConnectWise, "ScreenConnect security advisory: Precautionary extension disabling and partner guidance" (official Trust Center advisory; first published November 11, 2026 at 22:45 UTC, last updated November 13 at 21:15 UTC; checked November 14)
- Last checked
- As of November 14, 2026
Follow-up plans and what we checked
The company says it will keep validating findings, reconcile scope information and update its Trust Center as information is confirmed. When we checked on November 14, 2026, the latest entry was the November 13 update at 21:15 UTC. The security firm's blog also added a second wave in its 22:30 UTC update on November 13.
What ScreenConnect users should do today
Check that the listed extensions are disabled and keep them disabled
The advisory lists five independently developed third-party extensions for precautionary disabling: Labtech Plus, RMM Plus, RMM+, RMM Plus Password Link and RMM+ Password Link. The company disabled them in about 400 cloud environments. Because it cannot disable them in on-premises environments on partners' behalf, on-premises partners must disable them immediately (November 13 update). In that update it also says it disabled three more extensions in cloud and marketplace environments (ITBoost Integration, RepairShopr Integration, Guest Session Starter), strongly encourages all partners to do the same on and off premises, and asks partners to disable them immediately as a precautionary containment measure. Everyone who has them should verify their status and avoid re-enabling or reinstalling them pending further guidance. See the extension removal instructions on the company's page.
Update every technician client to 26.6.5 or later
This applies to both cloud-hosted and on-premises users. Check the installed version on each technician workstation, because updating a cloud console does not update the technician clients. The company says versions 26.6.5 and later block the attempted spread from an endpoint to a technician workstation. It adds that this does not remove an existing compromise.
Reduce the Transfer Files permission while updates are pending
Review roles and their session-group permissions and disable Transfer Files wherever it is not needed (older versions may call it TransferFilesInSession). The company calls this a temporary risk reduction, not a substitute for updating.
Revoke sessions and reset credentials from a trusted device, with MFA
The company asks you to revoke all active ScreenConnect web sessions and the associated identity-provider sessions, reset relevant credentials and enforce MFA. A password reset alone does not invalidate all existing sessions. See the multi-factor authentication guide.
Investigate with separate tools and preserve logs
Do not use ScreenConnect itself to investigate or clean affected devices; use EDR response capabilities or another trusted out-of-band method, and include technician workstations that connected to affected devices. Preserve authentication, extension installation, administrative, Run Command and Toolbox records first, then clear queued commands and tools on the server, remove unauthorized software and persistence, and validate before reconnecting devices.
Watch for unusual sign-ins and unapproved remote-access software
The company lists unusual sign-ins, unexpected MFA prompts, new administrators, permission changes, unapproved remote-access software, and unexpected commands or extension installations. It also asks you to verify unexpected support requests and password-reset messages through a trusted channel. See What phishing is.
Customers of a managed service provider: ask your provider
The company has no visibility into activity inside partner environments after initial access, so it cannot say whether a customer's devices were affected. Ask your provider whether it used ScreenConnect and these extensions, and what it has checked (our view).
What happened (from ConnectWise's advisory)
This section is based on ConnectWise's advisory "ScreenConnect security advisory: Precautionary extension disabling and partner guidance" on its Trust Center. It is the company's own account and has not been verified by a third party. Times are as the company states them (UTC).
September 8
The company releases ScreenConnect client version 26.6.5, which fixes CVE-2026-84869, an earlier client issue. It later says this version blocks the spread technique described in this incident (earlier fix).November 11, 22:45 UTC (November 12, 7:45 JST)
The company publishes its first advisory. It says it is aware of reports of unauthorized access to partner accounts and the deployment of unauthorized remote-access software in customer environments, lists five third-party extensions that may be involved, and says it disabled them in about 400 partner environments as a precaution.November 12, 02:45 UTC (11:45 JST)
The first update. It repeats that no compromise of its infrastructure or ScreenConnect vulnerability has been found, and states that the extensions provide an API capable of executing remote commands, protected by a passphrase set by the partner.November 11, 17:47 UTC (November 12, 2:47 JST)
A security firm that investigated the activity observes suspicious activity in its customer environments; it reaches at least 288 endpoints in 48 organizations within about 90 minutes (the firm's blog). This is before the company's first advisory.November 12, 18:45 UTC (November 13, 3:45 JST)
The second update. It adds the guidance to update technician clients to 26.6.5 or later and to review the Transfer Files permission, and reports on third-party researchers' findings.November 13, 16:12 UTC (November 14, 1:12 JST)
The investigating security firm records a second wave: 205 endpoints in 41 organizations (the firm's blog, updated at 22:30 UTC).November 13, 21:15 UTC (November 14, 6:15 JST)
The third update. Three more extensions disabled in cloud and marketplace environments; on-premises partners must disable immediately; researchers report additional activity targeting on-premises environments.
- What the company is investigating
- Unauthorized access to certain partner ScreenConnect environments and the deployment of unauthorized remote-access software in customer environments
- Initial assessment
- The activity may involve a threat actor's abuse of independent third-party extensions installed in partner environments. Still being validated. The initial access method and full scope have not been established
- The extensions
- An API capable of executing remote commands, protected by a passphrase configured by the partner during setup. The presence of the extensions alone does not establish compromise
- Third-party researchers' reports (not verified by the company)
- Attackers used access to partner consoles to deploy unauthorized ScreenConnect clients and a toolkit designed to spread to connecting technician workstations. Researchers say they have not observed that spread succeed. They also report an authentication flaw in an extension. The company says it is assessing these findings. A CVE has been assigned to an issue in the third-party extension
- The company's actions
- Disabled the extensions in about 400 cloud environments, advised on-premises partners to disable them, contacted affected partners directly and emailed ScreenConnect partners, and took additional protective measures including coordinating efforts to disrupt reported malicious infrastructure
- Visibility
- The company does not have visibility or telemetry into activity inside partner environments following initial access, and cannot independently determine what may have happened in affected partner or customer environments
- Where to look
- The advisory also publishes reported indicators of compromise for investigation, which this article does not reproduce. It says that an absence of matches does not rule out compromise
What is known and what is not
The state as of November 13, 2026. We will update the status column when more is published.
| Item | Content | Status |
|---|---|---|
| Unauthorized access to partner ScreenConnect environments and deployment of unauthorized remote-access software | The company is aware of reports and is investigating | Under investigation |
| Partner environments with an RMM+ family extension installed | About 400 (not a count of confirmed compromises) | Confirmed (the company) |
| Precautionary disabling | Done in the cloud environments; on-premises partners must do it themselves | Confirmed (the company) |
| Abuse of third-party extensions as the way in | Initial assessment, still being validated | Possible (the company's assessment) |
| Compromise of ConnectWise infrastructure | No evidence found | Not confirmed (the company) |
| A ScreenConnect vulnerability in initial access | No evidence found | Not confirmed (the company) |
| Spread to technician workstations | Researchers say they have not observed it succeed; the company says 26.6.5 and later block the technique | Under investigation |
| Activity inside partner and customer environments after initial access | The company has no visibility | Not stated |
| Initial access method and full scope | Not established | Under investigation |
| Rogue client installs in the investigating security firm's customer environments | November 11: at least 288 endpoints in 48 organizations (about 90 minutes). November 13: 205 endpoints in 41 organizations. The firm's official blog | Confirmed (the security firm; within its customer base) |
| Total number of affected partners and customers | Not stated in the company's advisory | Not stated |
How to read this: the number is environments with the extensions, not victims
The "about 400" is the number of partner environments that had at least one of these extensions installed. The company says this reflects installation, not confirmed compromises. The advisory gives no total for how many organizations were actually affected. The security firm's at least 288 endpoints in 48 organizations is a count within its own customer base; it is neither a total of victims nor the same population as the "about 400". The assessment about the extensions is also described by the company as initial and still being validated.
What can happen when remote-management tooling is abused
The following is what can generally happen, not a statement that any of it has occurred in a given environment. What the company says has occurred is limited to "What happened" above.
A remote-access tool used by an IT provider can run commands on, and transfer files to, every device it manages. If someone gains control of the tool's console or of a technician workstation, that reach extends to the provider's customers. That is why the company asks for an investigation through separate tooling, and why a provider's customers have reason to ask what was checked.
What organizations that run remote-management tools should review
This section does not evaluate the company's response, and it does not guess the technical details of the intrusion. From the published account, it is limited to points to check in your own setup, and they are our view.
Keep a list of the extensions and add-ons installed on your remote-access tool
The extensions in this case were independently developed and added by partners. Know which add-ons are installed, who approved them and what they can do, and remove those that are not needed (our view).
Check that any command-running API sits behind more than a single passphrase
The company describes an API capable of executing remote commands, protected by a passphrase set during setup. A feature that can run commands on managed devices deserves stronger authentication and network restriction than a shared secret (our view).
Track the version of the technician client, not just the console
The company notes that updating a cloud console does not update technician clients. Keep an inventory of the client version on each technician workstation (our view).
Grant file transfer and remote command rights only to the roles that need them
The company's temporary step is to disable Transfer Files wherever it is not required. Review roles regularly so that a single compromised account cannot move files to every device (our view).
Keep a way to investigate that does not depend on the tool under suspicion
The company asks you not to use ScreenConnect to investigate. Have an EDR or other out-of-band way to isolate and inspect devices ready before you need it (our view).
Sources (public records)
The facts in this article come from the public information below. Attack step details and indicators of compromise are not covered.
- ConnectWise, "ScreenConnect security advisory: Precautionary extension disabling and partner guidance" (official Trust Center advisory; first published November 11, 2026 at 22:45 UTC, last updated November 13 at 21:15 UTC; checked November 14) — connectwise.com
- Security firm that investigated, official blog (published November 11, 2026, updated November 13 at 22:30 UTC; checked November 14; observations in the firm's own customer environments) — huntress.com
Update history
2026-11-14: Added the investigating security firm's confirmed counts (at least 288 endpoints in 48 organizations on November 11; 205 endpoints in 41 organizations on November 13) and reflected ConnectWise's November 13 update (21:15 UTC): three more extensions disabled, and on-premises partners must disable immediately. The counts are within that firm's customer base, not a total of victims.
2026-11-13: First version. Based on ConnectWise's advisory as updated on November 12 (18:45 UTC). We will update when more is published.
Read next
- A similar remote management tool incident: N-able N-central vulnerability reportedly exploited after test code release
- Another incident at the same company, in a different product: ConnectWise Cloud Backup and Microsoft 365
- Protecting accounts: Multi-factor authentication guide / What phishing is
- Other 2026 incidents: Data breaches and cyberattacks of 2026