As reported by BleepingComputer, the recent ScreenConnect attacks that compromised at least 288 endpoints across 48 organizations within a 90-minute window represent a textbook example of supply chain trust exploitation — and a sobering reminder that your security posture is only as strong as your weakest integration.

Security Impact: As reported by BleepingComputer, the recent ScreenConnect attacks that compromised at least 288 endpoints across 48 organizations within a 90-minute window represent a textbook example of supply chain trust exploitation — and a sobering reminder that your security posture is only as strong as your weakest integration.

The Real Story: RMM+ Authentication Bypass, Not ScreenConnect Core

While headlines focus on the SCKit worm-like malware and CVE-2026-84869 (a previously patched ScreenConnect vulnerability), the actual initial access vector was far more mundane and arguably more dangerous: a third-party extension called RMM+ with an authentication design flaw that allowed attackers to bypass ScreenConnect's native authentication and MFA entirely.

Versions 1.0.31 and 1.0.32 of RMM+ used a shared access key model that permitted a blank key if an administrator never explicitly configured one. This meant an attacker could pass an empty access key through the extension's authentication check and issue remote commands through the ScreenConnect environment without ever logging in as a legitimate user — and without triggering MFA prompts.

The absence of corresponding user login activity in ScreenConnect logs while commands were being executed is the hallmark of a failed trust boundary between core platform and extension authentication.

Why This Attack Pattern Is Especially Dangerous for MSPs

The speed of compromise — one-third of systems hit within the first 10 minutes — combined with the worm-like propagation design of SCKit creates a cascading risk scenario unique to MSP environments:

The Real Story: RMM+ Authentication Bypass, Not ScreenConnect Core
MSP technicians connect to hundreds of customer endpoints daily, creating a natural lateral movement pathway
SCKit's design to spread from infected customer devices back to technician workstations weaponizes the MSP's own workflow
A single compromised technician machine can become a pivot point into every network that technician services
The use of ScreenConnect's native Run Command feature makes malicious activity blend with legitimate administrative operations

CVE-2026-84869: Exploited but Not Successfully

SCKit leveraged CVE-2026-84869, a previously patched ScreenConnect vulnerability, to attempt code execution on technician workstations during remote sessions. However, both Huntress and Blackpoint Cyber confirmed that this exploitation did not succeed against patched ScreenConnect clients. This is a critical point: the patch worked as designed. The failure of the CVE-2026-84869 exploit chain in the wild validates the importance of maintaining current patch levels on remote access infrastructure.

The Broader Third-Party Extension Risk

ConnectWise's decision to disable five potentially related third-party extensions across approximately 400 partner environments reflects a hard truth: most RMM and remote support platforms do not adequately gate the security boundaries between their core authentication systems and those of third-party extensions. The RMM+ flaw is not unique — it is a pattern seen repeatedly across the MSP tooling ecosystem where extensions roll their own authentication using shared keys, API tokens, or bypass mechanisms that sidestep the parent platform's security controls.

Shield53 Recommendations

Immediate Actions

  • Audit all third-party extensions installed in your ScreenConnect environment and any other RMM/remote support platform. Identify any that implement their own authentication or use shared access keys.
  • Ensure RMM+ is either updated or removed if running versions 1.0.31 or 1.0.32. Verify that a non-blank access key is configured if the extension remains in use.
  • Confirm ScreenConnect clients are fully patched against CVE-2026-84869. While exploitation was unsuccessful in the wild, the vulnerability was clearly weaponized in active attacks.
  • Review ScreenConnect logs for command execution events without corresponding user authentication events — this is the primary indicator of RMM+ abuse.
  • Disable or isolate any third-party extensions you cannot independently verify as secure, especially those that interact with command execution or session management.

Strategic Hardening

  • Implement network-level controls restricting which IPs can reach ScreenConnect extension APIs and management interfaces
  • Establish a third-party extension governance policy requiring security review of any integration before deployment, including authentication architecture review
  • Deploy EDR on technician workstations with specific detection rules for suspicious child processes spawned by ScreenConnect or related remote session binaries
  • Segment MSP management networks so that a compromised technician workstation does not have unrestricted access to all managed customer infrastructure

The ScreenConnect incident underscores a reality that the MSP community must internalize: the attack surface is not the platform alone — it is the platform plus every extension, plugin, and integration that touches it. Treat your remote access tooling as privileged infrastructure, because that is exactly what attackers are doing.