SCKit Aimed a Worm at MSPs Through ScreenConnect. The Patch Held.

TL;DR - On 12 November, BleepingComputer and The Hacker News reported a worm-like malware family called SCKit being used against managed service providers through ConnectWise ScreenConnect support sessions. It arrived through a known authentication flaw in third-party RMM+ extensions, and it tried to turn a fix into a new infection by sending a malicious file back to the technician. The worm behaviour was attempted, not successful: Blackpoint reproduced it and blocked it, and Huntress found no successful exploitation in the logs it recovered. The patched clients held. The authentication gap that opened the door is the part worth your afternoon. What you need to do: update ScreenConnect to 26.6.5 or later, audit and remove unused third-party extensions from your RMM tooling, require MFA on every remote support path, and check whether anyone can start a support session into a client without a named, authenticated human approving it.

By The Numbers

I have spent a fair part of this year telling small businesses that their remote support tool is the most privileged software they own. Reading the SCKit reporting on 12 November, I had the same reaction I get every time this prediction lands: it turns out to be true, and I would rather have been wrong.

The short version is that a malware family called SCKit used ScreenConnect support sessions as its way into managed service providers. That is a sentence worth slowing down over. The tool that MSPs use to help customers is the tool that was co-opted to reach the MSP itself and, through the MSP, the customers.

There is also a genuinely good piece of news buried in the reporting, and I want to put it up front because most coverage skimmed past it. The worm technique was tried and it did not work against patched clients. That is not the whole story, but it is the most useful half of it.

Let me walk you through what SCKit actually did, what failed, what got in anyway, and what to check on your own estate this week.

What ScreenConnect is, and why attackers keep coming back to it

ScreenConnect, now sold as ConnectWise ScreenConnect, is remote support software. A technician installs a small client on a customer machine, and from then on that machine can be viewed and controlled from a support console. It is deployed across millions of endpoints because it makes remote support possible at all. MSPs live inside it all day.

That design is what makes it attractive. ScreenConnect sessions are trusted by default. The technician running the session is the privileged party, the software is already on the machine with broad rights, and it is allowed through firewalls precisely because support needs to reach inside the network. A tool built to cross trust boundaries at speed is a tool that an attacker wants to be standing inside.

The industry has known this for a while. The 2024 ScreenConnect authentication bypass that let attackers drop files onto customer machines was a warning shot, and it changed how a lot of MSPs think about patching their own tooling. SCKit is the next attempt to make the same trust model pay off.

What SCKit tried to do

The mechanism reported on 12 November is what makes this story distinctive. Rather than simply using a ScreenConnect session to run commands on the customer machine, SCKit tried to reverse the direction of the session.

In a normal support session, the technician's machine is the safe side and the customer machine is the one being inspected. The technique reported under the name RelayTrap replaces the guest-side support process and then attempts to send a file back to the technician, so the malicious payload travels from the client towards the support console. If that works, the infection has a route into the one machine in the relationship that nobody treats as untrusted.

That is the worm part. An MSP technician opens a session into a compromised end client, and the session itself becomes the delivery mechanism back into the MSP, where hundreds of other client sessions are waiting. It is a supply chain attack that runs through the support desk rather than through a software update.

The underlying flaw is tracked as CVE-2026-84869, a critical client-side file-transfer vulnerability, and ConnectWise fixed it in ScreenConnect 26.6.5.

The part that actually worked: the extension authentication gap

Here is where the story stops being a near miss and starts being an operations lesson.

The initial access did not rely on the file-transfer flaw that gave the worm its name. It came through an authentication weakness in third-party ScreenConnect extensions built on the RMM+ framework, specifically versions 1.0.31 and 1.0.32. Those extensions accepted commands without properly authenticating the caller and without requiring MFA. An attacker who could reach the extension endpoint could issue commands without proving who they were.

ConnectWise disabled five third-party extensions across roughly 400 partner environments once the flaw was understood. Read that as a vendor deciding that the safe move was to switch off a whole category of third-party add-ons rather than trust partner code to be clean.

This is the sentence I would underline for any IT manager reading this. The worm attempt failed on patched clients, and that is real. But the door that let the attacker in was not the worm. It was an extension sitting beside the support tool, written by a third party, installed because it made an MSP's life easier, and it did not insist that the person issuing commands prove who they were.

What the numbers say

The telemetry makes the speed of the incident clear. Huntress tracked the activity across 288 endpoints in 48 organisations, and reports that roughly two-thirds of the related activity in that set landed inside a ten-minute window. That is not a slow campaign ramping up over days. It is a burst that arrives while the support desk is on lunch.

On the worm claim itself, the honest reading is narrower than some headlines suggested. Blackpoint reproduced the technique in its own environment and blocked it. Huntress went through recovered logs and found zero successful exploitation. So the correct description is that the technique was attempted and did not succeed against patched clients. I have no interest in writing the version where a worm swept the MSP world, because that is not what the evidence says.

There is one loose thread worth naming. A July 2026 VirusTotal batch script referenced the same rogue client ID seen in this activity. Reported coverage treats the connection as unclear, and so should you. It could be the same operator, it could be shared tooling, and it could be coincidence. Nothing in the reporting establishes the link, so I am not going to assert one.

Why this could be good

The failure is the good news, and it is worth being specific about why it failed.

First, the file-transfer flaw was fixed before the worm made the news. ScreenConnect 26.6.5 was out, and organisations that had applied it were not reachable by the technique that gave SCKit its worm behaviour. Patching a support tool promptly is exactly the discipline the 2024 incident taught, and it paid off here.

Second, the defenders had telemetry fast enough to say something true. Blackpoint reproducing and blocking the technique, and Huntress reporting zero successful exploitation from recovered logs, is the kind of measured public account that helps everyone else calibrate. Nobody had to guess whether the worm worked. Two independent firms looked and told us.

Third, ConnectWise moved to switch off the vulnerable third-party extensions across hundreds of environments rather than waiting for each partner to decide. An ecosystem-level action on a shared risk is the right shape of response, and it closed the specific authentication gap that was being used.

Concerns

I am not going to pretend the operation is fully closed, for three reasons.

First, disabling extensions is a mitigation, not a cure. Every MSP that relied on one of those five add-ons now has a hole in a workflow. The pressure to re-enable something, or install a lookalike replacement, is real, and the replacement will not automatically be better written than the one that failed. Supply chain risk in the RMM extension market is a structural problem, not a one-off bug.

Second, the trust model has not changed. ScreenConnect is still software that lives on every managed endpoint with broad rights and is trusted across network boundaries. The vulnerability of the week was fixed. The architecture that made it valuable to an attacker is unchanged.

Third, the extension authentication pattern is not unique to this vendor. Any platform that allows third-party code to extend a privileged tool inherits whatever access control those extensions implement. If the extension does not enforce authentication and MFA on its own command path, then the strength of the underlying platform does not save you.

What to do right now

1. Check your ScreenConnect version and move to 26.6.5 or later. That is the fix for CVE-2026-84869, the client-side file-transfer flaw at the centre of the reported worm technique. If a provider manages the console for you, ask them for the version in writing this week.
2. Audit every third-party extension in your RMM stack. List what is installed, who installed it, and whether anyone still needs it. The five extensions ConnectWise disabled are the immediate priority, and anything built on RMM+ versions 1.0.31 or 1.0.32 should be treated as untrusted until the vendor confirms otherwise.
3. Require authentication and MFA on every support path. If any extension, script, or integration can issue commands to a customer machine without a named, authenticated human in the loop, that is the finding. MFA on the console login is not enough if the extension path skips it.
4. Review session approvals. Find out whether a technician can open a session into a client without the client, or an internal approver, seeing it in a log. Support sessions should be logged, attributable, and reviewable afterwards.
5. Hunt for the reported indicators. ConnectWise, Blackpoint, Huntress and the security press have all published detail on this activity. Pass the reported file paths and client IDs to whoever runs your EDR and ask for a retro-hunt, not just a forward-looking rule.
6. Treat the technician session as untrusted input. Whatever you monitor on customer endpoints, apply the same logging to the direction that comes back. A file arriving from a customer machine into a support session is the shape of this attack and should never be invisible.
7. Ask your provider the uncomfortable question. Not "are you patched", but "can any tool you run issue commands against my machines without authenticating the person issuing them". The first question has a yes or no answer. The second one is where the real exposure lives.

Key Takeaways

• SCKit used ScreenConnect support sessions as an attack path into MSPs on 12 November 2026. Reported by BleepingComputer and The Hacker News the same day.
• The worm behaviour was attempted, not successful. The client-side file-transfer flaw was patched in ScreenConnect 26.6.5, Blackpoint reproduced and blocked the technique, and Huntress found no successful exploitation in recovered logs.
• The real entry point was third-party extension authentication. RMM+ extension versions 1.0.31 and 1.0.32 accepted commands without authenticating the caller or requiring MFA, and ConnectWise disabled five extensions across roughly 400 partner environments in response.
• Speed is the defining characteristic. Huntress saw activity across 288 endpoints in 48 organisations, with roughly two-thirds of it inside a ten-minute window.
• Update the support tool, then audit the extensions beside it. The console patch closes the reported flaw, the extension audit closes the gap that was actually used.
• The trust model is the durable risk. Any privileged remote support platform that accepts third-party extensions inherits the access control those extensions implement.

FAQ

Is my ScreenConnect installation affected? If it is below version 26.6.5, it is exposed to CVE-2026-84869, the client-side file-transfer flaw behind the reported worm technique. Check the version in the console, and if a provider runs it for you, ask them for the version number in writing rather than taking "we are up to date" as an answer.

Did the worm actually succeed anywhere? The evidence points the other way. Blackpoint reproduced the technique in its own environment and blocked it, and Huntress found zero successful exploitation when it reviewed recovered logs. The right description is that the technique was attempted and failed against patched clients.

What are RMM+ extensions and why do they carry risk? They are third-party add-ons that extend what a remote monitoring and management platform can do. They run with the privileges of the platform they extend, so an extension that does not enforce its own authentication is effectively a privileged API with a weak lock on it. That is the pattern that was abused here.

Do I need to remove all my extensions? Not automatically. The immediate priority is the five extensions ConnectWise disabled and anything built on RMM+ versions 1.0.31 or 1.0.32. Beyond that, the useful exercise is asking what each extension can do, who installed it, and whether it authenticates the person issuing commands.

Does MFA on the ScreenConnect console protect me? It helps, and it is not sufficient on its own. If a vulnerable extension accepts commands without checking authentication, then an attacker who reaches the extension endpoint is not stopped by the fact that the console login has MFA. The authentication requirement has to apply to the command path, not just the front door.

How do I know if a session was abused? Look for support sessions that are not attributable to a named technician, unexpected files arriving from a client machine into the technician side, and client or extension IDs that do not match anything your team deployed. Session logs are the primary evidence here, which is a reason to make sure they are on and retained.

We are an SMB using an MSP. What do we do? Ask your provider three questions in writing: which ScreenConnect version are you running, which third-party extensions are installed against my estate, and can any of them issue commands without authenticating the person doing it. You do not need to understand the exploit to ask those.

Is this connected to the July 2026 VirusTotal batch script? Not on the evidence available. A batch script from July referenced the same rogue client ID, and reported coverage describes the relationship as unclear. It could be shared tooling, a shared operator, or coincidence, and nobody has established which.

My Take

The part of this story I keep returning to is that the worm failed and the door was still open.

Two independent firms reproduced the technique and confirmed it did not land on patched clients. That is a genuine win, and it came from people doing the unglamorous thing: patching their support tool quickly and keeping telemetry good enough to say what happened. Then you look at how the attacker got in, and it was a third-party extension that accepted commands without checking who was sending them. The patched client was never the weakest link. The add-on beside it was.

Every MSP I have worked with runs something in that category. A billing integration, a documentation sync, a reporting dashboard, a ticket automation. Each one was installed to save an hour a week, each one inherits broad rights, and most of them were chosen on the strength of a demo rather than an authentication review. Nobody is blameworthy for that, because the extension ecosystem presents itself as plumbing.

The fix is not to stop extending your tooling. It is to make authentication and approval apply to the command path, and to be able to name who can start a session into a customer machine. Do that, and the next version of this attack finds the console patched and the side door locked.

Further Reading

• BleepingComputer: New worm-like 'SCKit' malware targets MSPs in ScreenConnect attacks - the 12 November report, including the RelayTrap behaviour and the extension versions
• The Hacker News: SCKit Malware Turns ScreenConnect Support Sessions Into Potential MSP Attack Paths - the same-day coverage and the Huntress and Blackpoint findings
• PaperCut NG/MF zero-day: the print server MSP checklist - the other managed-tooling exposure from this year, and the same "who owns this box" question
• Exposed management interfaces at continental scale - why internet-reachable admin paths keep turning into incidents
• Cloud identity token theft: the CISA and NIST playbook - what to do after credentials in a trusted tool are abused
• SonicWall SMA zero-days and the ANZ branch office patch - internet-facing appliances and the checklist that still applies
• Hard-coded keys and unauthenticated RCE in SolarWinds ARM - the neighbouring failure where an integration credential was the whole vulnerability
• Vibe-coded apps: discovery and audit - the third-party code you did not review, and how to find it

Mathew Clark Founder, SecureInSeconds Currently: asking every MSP I know which five extensions ConnectWise just switched off, and watching nobody want to answer first Drafted with AI assistance - read, verified, and fixed by a human.