Attackers have used a weakness in a third-party add-on for ConnectWise ScreenConnect, one of the remote-support tools IT providers use to look after their clients’ computers, to plant their own remote-access software on hundreds of machines. Security firm Huntress says it saw at least 288 endpoints across 48 organisations hit in about 90 minutes, and ConnectWise has switched off a family of extensions in roughly 400 customer environments while it investigates.
If your business outsources its IT to a managed service provider (MSP), this is the kind of attack that can reach you without anyone in your office clicking a link. Here’s what happened, what has and hasn’t been confirmed, and the questions worth asking your IT provider today.
What happened, in Australian time
The timeline below is drawn from Huntress and ConnectWise. The times are converted to Australian Eastern Daylight Time (AEDT) by us.
- About 4:47am AEDT on Thursday 12 November (17:47 UTC on 11 November): Huntress saw an operator using cloud-hosted ScreenConnect consoles to push commands to groups of managed computers. About a third of the 288 affected endpoints were hit in the first 10 minutes.
- 9:45am AEDT Thursday: ConnectWise published a Trust Center advisory naming five third-party extensions it had disabled as a precaution: Labtech Plus, RMM Plus, RMM+, RMM Plus Password Link and RMM+ Password Link.
- About 3:34pm AEDT Thursday: Huntress updated its report to say the activity “seems to be related” to one of those extensions, RMM+.
- About 4:50am AEDT on Friday 13 November: a CVE record, CVE-2026-127063, was published for the RMM+ issue, with ConnectWise as the issuing authority.
- 5:45am AEDT Friday: ConnectWise’s latest update said its investigation was ongoing and that “protective actions” had been identified.
How the attackers got in: a forgotten add-on
ScreenConnect lets a technician see and control a remote computer, run commands on it and transfer files. RMM+ is an extension made by another company that lets other management tools drive ScreenConnect through an API, without a technician using the normal console.
According to Huntress, RMM+ checks requests against a shared access key instead of ScreenConnect’s own user accounts, roles and multi-factor authentication (MFA). In versions 1.0.31 and 1.0.32, Huntress says, the extension accepted a blank key if an administrator had never set one. In practice that could let an attacker send commands without logging in at all. Huntress said this matched what it saw: commands reached endpoints across several ScreenConnect instances “within minutes”, with “no corresponding login activity”. It also said most RMM+ installs it found looked legitimate, and were “usually added for a project and left in place”.
The official record describes the flaw a little differently. The CVE entry and ConnectWise’s GitHub disclosure say RMM+ “uses a static API secret by default” and list all versions of the extension as affected, with a CVSS 4.0 score of 9.3 (critical). Both descriptions point to the same practical risk: if the extension’s secret was never changed, someone else could use it to send commands. ConnectWise says the issue is specific to the extension and does not affect the ScreenConnect server or client.
That matters because Huntress says ScreenConnect versions 26.6.6.9747 and 26.7.6.9783, the most current releases, were affected. As The Register noted, running the latest ScreenConnect release was not necessarily enough on its own for partners who still had the extension switched on.
SCKit: malware built to trap the technician
Once inside, the attackers used ScreenConnect’s Run Command feature to install a second, attacker-controlled ScreenConnect client and a 16-file toolkit Huntress calls SCKit. The extra client gives the attackers a way back in even if the IT provider’s own connection is closed.
The more unusual part is a component called RelayTrap. Huntress and Blackpoint Cyber, whose analysis was reported by BleepingComputer, say it is designed to wait for a technician to connect to the infected machine, then push a file back to the technician’s own workstation, steal browser session cookies and use the technician’s access to reach other customers’ machines. It relies on an older client flaw, CVE-2026-84869, which ConnectWise patched in ScreenConnect 26.6.5 on 8 September and scored 9.9 out of 10 on the CVSS 3.1 scale.
So far the spread does not appear to have worked. Huntress wrote that “The console-takeover attempt failed in every recovered host log we have checked so far.” Blackpoint researchers Sam Decker and Nevan Beal told Recorded Future News their testing showed the existing patch blocks the toolkit’s exploit against a fully patched client, but warned that “Patching addresses the known exploit, but it doesn’t eliminate the risks associated with a compromised operator session.” Huntress also said the RelayTrap code appears to have been generated by a large language model, based on its unusually detailed comments.
What ConnectWise says, and what is still unknown
In its latest update, ConnectWise said: “At this time, we have found no evidence of a compromise of ConnectWise infrastructure or that initial access involved a ScreenConnect vulnerability.” It stressed that the roughly 400 environments it acted on had the extensions installed, which “alone does not establish compromise”.
ConnectWise also says it has no visibility into what happened inside partner environments after initial access, so it cannot tell affected businesses what attackers did on their machines. Several important details are still unknown:
- How many organisations were affected in total. Huntress’s figures cover its own customers, and The Register reports that Huntress suspects more MSPs were compromised than it has detected.
- Who is behind the campaign, and whether any data was stolen. None of the reports we reviewed attributed the attack or named victims.
- Whether Australian MSPs or their clients are among those affected. We found no public report either way at the time of writing.
Not the only IT management tool under attack this week
The ScreenConnect campaign landed alongside separate trouble at another remote monitoring and management (RMM) vendor, N-able. BleepingComputer reports that a researcher published two new N-central exploits on 12 November (US time), just two days after N-able’s emergency patches for earlier flaws. Security firm Huntback reported that attackers had compromised at least 21 N-central servers with the public exploit to mine cryptocurrency, 19 of them on the latest hotfix. N-able said it was restricting some features and integrations while it works on fixes, and urged on-premises customers to make sure Legacy API access stays disabled.
The two incidents are not connected, as far as anyone has reported. But they show why attackers keep targeting IT management tools: break into one, and you may be able to reach every business that provider manages.
Why this matters for Australian businesses
Many Australian small and medium businesses never touch ScreenConnect or N-central themselves. Their IT provider does. That makes this a supplier risk, much like the remotely managed fridge controllers we covered in France’s supermarket cyberattacks: the weak point can sit with a contractor’s tools, not your own staff.
If you are an MSP or an in-house IT team running ScreenConnect, ConnectWise’s advisory is the place to start. Its key steps are:
- Keep the five listed extensions disabled. Cloud partners have had them switched off; on-premises partners must disable them themselves and should not reinstall them until ConnectWise says otherwise.
- Update every technician’s ScreenConnect client to version 26.6.5 or later and check each workstation. ConnectWise warns that “Updating a cloud console does not automatically update technician clients.”
- From a trusted device, revoke active ScreenConnect web sessions and identity-provider sessions, reset credentials and enforce MFA. Password resets alone do not end existing sessions.
- Don’t investigate a suspect machine over ScreenConnect. Use EDR (endpoint detection and response) or another out-of-band tool, and check technician workstations that connected to affected devices.
- Review Run Command, Toolbox, extension installation and login records, and look for a second, unapproved ScreenConnect client on managed machines. Huntress says some machines were reinfected soon after isolation ended because the malware had not been fully removed.
If a provider manages your IT, our advice is to ask them three plain questions: do you use ScreenConnect, N-central or another remote-access tool on our computers; did you have any of the affected add-ons or versions; and have you checked our machines for unauthorised remote-access software since 12 November?
Australian organisations can report cyber incidents to the Australian Signals Directorate through cyber.gov.au or on 1300 CYBER1 (1300 292 371). If personal information may have been accessed and serious harm is likely, organisations covered by the Privacy Act may also have obligations under the Notifiable Data Breaches scheme. As with this week’s Microsoft Outlook zero-day, the order of play is patch first, then check for signs that someone was already inside.
Our read
In our view, the lesson here isn’t just “patch ScreenConnect”. Huntress’s own findings show the attackers didn’t need a new ScreenConnect bug: they came in through an add-on that many providers had probably forgotten was there. For MSPs, an audit of every extension, integration and API key attached to their remote-access tools looks overdue. For their clients, this is a good week to ask who can reach your computers remotely, and how that access is protected.
Featured image: Network operations centre at Cyberport, Hong Kong (2008 stock photo, not connected to these attacks). Photo: Sunnyhtho via Wikimedia Commons, CC BY 3.0; converted to PNG. This article reflects information available at about 4pm AEDT on 13 November 2026; the investigation is ongoing.
