SCKit exploits ScreenConnect: patch now or expose your remote support

The detail that changes the diagnosis: there is no new vulnerability

When an active campaign against a remote access tool is detected, the instinctive reaction is to think of a zero-day flaw. In this case, the information points in another direction: the attacker's toolkit, dubbed SCKit, does not exploit an unknown vulnerability, but rather a critical breach already patched in ConnectWise ScreenConnect. According to data shared with The Hacker News by Blackpoint Cyber's Adversary Pursuit Group, the recovered kit exploits CVE-2026-84869, with a CVSS score of 9.9.

That nuance is important. This is not a problem that requires waiting for the vendor to publish a fix: the fix exists. The real risk is concentrated in installations that have not applied the update, in those that applied it late, or in those where the remote support software lives in a corner of the infrastructure that nobody reviews as often as they should.

Why ScreenConnect is an appealing target

Remote access tools are, by definition, legitimate doors. They are designed so that someone from outside can enter a machine and take control. That functionality is exactly what a managed service provider needs to serve its clients, but it is also what an attacker looking to move around without raising too many alarms is after.

SCKit's approach fits a trend we have been observing: instead of breaking authentication from scratch, it takes advantage of a support session to slip into the environment. If the tool is poorly patched, the attacker can turn what should be an assistance channel into an entry path. And if that tool is used by several clients through the same provider, the potential impact multiplies.

For an SMB, the reading is straightforward: the software you installed so that your IT person or your provider could help you remotely is not a neutral element. It is one more attack surface, and it deserves the same rigor as email, the VPN, or the firewall.

What it means for an IT team with limited resources

An SMB usually does not have a dedicated security team around the clock. Patch management competes with day-to-day operations, and remote support tools tend to fall off the radar because "the provider uses them" or "we installed them years ago and they work." That is precisely why they should be treated as critical infrastructure.

There are three scenarios worth reviewing without drama, but without delay:

• Own installations: if your company hosts ScreenConnect or any other remote access solution, check the version and apply pending updates. Knowing that a patch exists is not enough: you have to verify that it is installed.
• Delegated access to a provider: if a third party manages the tool, ask for written confirmation of the deployed version and the date of the last patch. Trust without verification is an inherited risk.
• Machines with the client installed: review which endpoints have remote access agents and whether all of them are still necessary. Every forgotten installation is a door that nobody watches.

Concrete recommendations for this week

Beyond applying the patch, which is the priority action, we propose a checklist that an SMB can address with its IT provider or its internal team:

1. Inventory of remote access tools: know what is installed, in which versions, and who has permission to use it. Without an inventory there is no control.
2. Review of access and privileges: limit who can start sessions and from where. Remote access should not be open to any account or any network.
3. Reinforced authentication: enable two-factor authentication on the tool's administration consoles, not just on email.
4. Logging and monitoring: retain session logs and review access outside business hours or from unexpected locations. A legitimate support session has a context; an intrusion does not.
5. Response plan: if a suspicious session is detected, know whom to notify, what to isolate, and how to revoke credentials without improvising.

This case is reminiscent of other recent advisories we have published, such as the one on N-central and the exploits that bypass the patch or the one on Apache HTTP/2: the window between the publication of a patch and its mass application remains the attackers' favorite ground. The difference, in the case of remote support tools, is that the attacker does not need to look for a new flaw: it is enough to find a door that should have been closed.

The underlying lesson

SCKit is not a story about a careless vendor, but about the gap between patch availability and actual deployment. For an SMB, the practical conclusion is simple: treat remote access software as you would treat corporate email or the VPN. Verify versions, limit permissions, enable two-factor authentication, and review logs. And if you depend on a provider, demand documented confirmation. The convenience of remote support should not become the attacker's convenience.

Source: The Hacker News. Analysis and adaptation: ForgeNEX.