Your RMM Is the Attack Vector: 1,000+ ScreenConnect Instances Still Exposed as Attackers Exploit CVE-2026-84869

The Story Every IT Team Should Read Twice

CISA has added CVE-2026-84869 — a critical authorization flaw in ConnectWise ScreenConnect — to its Known Exploited Vulnerabilities catalog after confirming active exploitation in the wild. Federal agencies have three days to secure affected systems. And here's the part that should make every sysadmin and MSP tech uncomfortable: more than 1,000 internet-exposed ScreenConnect instances are still sitting out there, unpatched, right now.

If you work in IT operations, the irony isn't lost on you. ScreenConnect is the tool you use to fix everything. It runs with SYSTEM-level access on every endpoint it touches. When the remote management tool itself becomes the vulnerability, the blast radius isn't one server — it's your entire managed estate. For an MSP running one ScreenConnect instance across 20 client environments, a compromise means one door into every client at once.

And yet more than a thousand instances remain exposed. Not because admins don't care. Because of how we've built our tooling — and how we've failed to manage the management plane.

The Problem in Depth: Nobody Monitors the RMM

Think about how most IT departments and MSPs are actually set up:

• A monitoring tool watches servers, switches, and disk space.
• An RMM platform (ConnectWise, Ninja, Syncro, Datto) manages endpoints, runs scripts, and provides remote sessions.
• A helpdesk tracks tickets.
• Patch management runs on its own schedule, endpoint-first.

Each tool does its job. But ask yourself: which one of them is watching the RMM server itself? In most environments, the answer is none of them.

The RMM server is the management plane. It can execute code, push files, and reach hundreds of machines. Yet it's often an on-prem box somebody stood up in 2019 — exposed to the internet because remote access "needed to work from anywhere," running a version nobody has checked since the original install went live.

Why do 1,000+ instances remain vulnerable when a patch exists? Three very recognizable reasons:

1. No central inventory of remote access tooling. Ask five techs which clients use ScreenConnect, where the servers live, and what versions they run. You'll get five different answers and at least one "wait, we have one there too?" Shadow instances — a "temporary" install for one project that became permanent — are the norm, not the exception.

2. Patch processes cover endpoints, not infrastructure tooling. Your Windows Update rings and third-party patch policy probably cover workstations and servers beautifully. But the RMM server, the jump host, the remote access appliance — these often fall outside patch scope because they're "the tool," not "the asset."

3. Tool sprawl hides version drift. When monitoring, RMM, patching, and helpdesk live in four separate consoles, there is no single query that answers "which machines in my estate are running an outdated remote access client?" Answering it means RDPing into servers one by one, or exporting CSVs from three tools and hoping the columns line up.

The business impact is ugly. A compromised RMM means incident response across every managed endpoint simultaneously — for an MSP, every client at once, plus the contractual, insurance, and reputational fallout. Even the near-miss version burns the team: emergency patch windows at night, war-room calls with clients, days of verification work to prove nothing happened. Meanwhile CISA gave federal agencies three days. Your clients will expect something similar — and if your helpdesk and monitoring data live in separate systems, assembling the evidence of what you did and when will take days by hand.

That's what tool fragmentation actually costs: not inconvenience, but time-to-answer. And in an actively exploited CVE situation, time-to-answer is the whole game.

How AlertMonitor Closes the Gap

AlertMonitor was built on a simple premise: the remote access layer should be a first-class citizen of your monitored, patched, and documented estate — not a separate kingdom nobody audits.

The RMM lives inside the monitoring platform. Remote sessions, script execution, software pushes, and remote control all happen from the same console where your alerts fire. No tab-switching between the monitor that tells you something's wrong and the RMM you use to fix it. When an alert opens, the technician is one click from a remote session on the affected endpoint.

Software inventory includes remote access tools. AlertMonitor tracks installed software — including ScreenConnect, ConnectWise agents, AnyDesk, TeamViewer, and similar — across every managed endpoint. "Which machines have ScreenConnect and what version?" is a 10-second query, not a half-day scavenger hunt.

Scripts run across device groups, and results land in the same timeline as alerts and tickets. Push a version-audit script to 400 endpoints. Results stream back into AlertMonitor, attach to the ticket or alert context, and become part of the documented record. Automated remediations and manual technician actions are both visible — no more "did anyone actually patch that box?" archaeology.

Patch management covers third-party applications. When a vendor ships a security fix for a remote access client, the update rolls through the same patch pipeline that handles your Windows updates — with compliance reporting to prove it.

Version drift generates alerts. If an endpoint's remote access client falls behind your baseline, that's an alert with a ticket attached — surfaced during business hours, not discovered during a 2am incident.

Compare the workflows. The old way: a vendor advisory email, a panicked Slack channel, three techs RDPing into servers to check versions, a spreadsheet, and a hope. The AlertMonitor way: one script task against a device group, results in minutes, exceptions flagged automatically, a patch task created and tracked to completion — the whole trail in one place for the client report or the auditor. For MSPs, client segmentation keeps the NOC view organized across dozens of environments, so a version audit touches every client's estate in one pass — not twenty separate console logins.

Practical Steps: Audit Your Remote Access Footprint Today

You don't need to wait for a platform migration to start. Here's what to do right now.

Step 1: Inventory every remote access tool in your estate. Run this against your servers and workstations to find every installed remote access agent and its version:

# Remote access tool inventory - run per machine or via your script runner
$computers = Get-Content .\servers.txt
$paths = "HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\*",
         "HKLM:\SOFTWARE\WOW6432Node\Microsoft\Windows\CurrentVersion\Uninstall\*"
$results = foreach ($c in $computers) {
    try {
        Invoke-Command -ComputerName $c -ScriptBlock {
            Param($paths)
            Get-ItemProperty $paths -ErrorAction SilentlyContinue |
                Where-Object { $_.DisplayName -match 'ScreenConnect|ConnectWise|AnyDesk|TeamViewer|Splashtop|Dameware|RustDesk' } |
                Select-Object DisplayName, DisplayVersion, InstallDate
        } -ArgumentList $paths | Select-Object @{n='Computer';e={$c}}, DisplayName, DisplayVersion, InstallDate
    } catch {
        [PSCustomObject]@{ Computer = $c; DisplayName = 'UNREACHABLE'; DisplayVersion = ''; InstallDate = '' }
    }
}
$results | Sort-Object Computer | Export-Csv .\remote-access-inventory.csv -NoTypeInformation
$results | Format-Table -AutoSize

The output is your raw material: every machine, every remote access tool, every version. Sort by version. The gaps will stare back at you.

Step 2: Check the ScreenConnect server itself — not just the agents. If you run an on-prem instance, confirm its installed version directly:

# Check service status and installed version of a ScreenConnect server
$svc = Get-Service -DisplayName "*ScreenConnect*" -ErrorAction SilentlyContinue
if ($svc) {
    $svc | Select-Object Name, Status, StartType
    $exe = "C:\Program Files (x86)\ScreenConnect\ScreenConnect.Service.exe"
    if (Test-Path $exe) {
        "Installed version: " + (Get-Item $exe).VersionInfo.ProductVersion
    }
} else {
    "No ScreenConnect service found on this host"
}

Compare that version against the vendor's fixed release. If you can't answer "what version are we on?" in under a minute, that's the finding.

Step 3: Turn the audit into an ongoing check, not a one-off. In AlertMonitor, save the inventory script as a script task and run it against a device group — all servers, or a client-scoped group. Machines reporting outdated versions get flagged, and the results appear in the monitoring timeline next to the alerts and tickets they relate to:

# AlertMonitor script task: flag outdated remote access clients
$minimum = @{ 'ScreenConnect Client' = [version]'25.0.0'; 'AnyDesk' = [version]'9.0.0' }
$installed = Get-ItemProperty "HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\*",
    "HKLM:\SOFTWARE\WOW6432Node\Microsoft\Windows\CurrentVersion\Uninstall\*" -ErrorAction SilentlyContinue
foreach ($tool in $minimum.Keys) {
    $app = $installed | Where-Object { $_.DisplayName -eq $tool } | Select-Object -First 1
    if ($app -and $app.DisplayVersion -match '^\d+(\.\d+)+$' -and [version]$app.DisplayVersion -lt $minimum[$tool]) {
        Write-Output "OUTDATED: $tool $($app.DisplayVersion) on $env:COMPUTERNAME"
    } elseif ($app) {
        Write-Output "OK: $tool $($app.DisplayVersion) on $env:COMPUTERNAME"
    }
}

Wire that script's output into an AlertMonitor alert rule so any "OUTDATED" line raises a ticket automatically. Next time a vendor drops an emergency advisory, you're not auditing — you're already looking at a filtered list of the six machines that matter.

Step 4: Sweep your Linux servers too:

# List running remote access agents on a Linux server
ps -eo pid,comm,args | grep -Ei 'screenconnect|anydesk|teamviewer|rustdesk' | grep -v grep

Step 5: Fold remote access tooling into third-party patching. ScreenConnect clients, AnyDesk, TeamViewer — these belong in your patch policy on the same cadence as browsers and Java. In AlertMonitor, third-party applications sit in the same patch pipeline as OS updates, so a remote access client pinned to an old version shows up in the same compliance report your team already reviews.

The pattern across all five steps is identical: make the remote access layer visible, queryable, and patchable from the same place you already work. The teams that get burned by vulnerabilities like CVE-2026-84869 are rarely the teams without tools — they're the teams whose tools don't talk to each other, and whose most privileged asset was the one thing nobody thought to monitor.

More than 1,000 ScreenConnect instances are still exposed as you read this. The fix is already published. The only question is whether you can find — and patch — your instances before someone else finds them for you.

Related Resources

AlertMonitor RMM & Remote Management AlertMonitor Platform Overview Book a Demo RMM & Remote Management Resources