RMM in CISA KEV: N-able N-central 2026.3.1.14 and ConnectWise ScreenConnect 26.6.5.9742

Between September 8 and 11, 2026, CISA added two vulnerabilities in remote monitoring and management (RMM) tools to its KEV catalog: N-able N-central and ConnectWise ScreenConnect. Four days apart, two different vendors, two products doing the same job — remotely administering thousands of customer endpoints.

This isn't a statistical coincidence. An RMM tool is pre-installed, legitimate administrative access across an entire estate, and since Kaseya in 2021 attackers have treated the category as exactly what it is: the most efficient way to compromise hundreds of organisations by exploiting a single flaw.

Fixed versions: N-central 2026.3.1.14 and ScreenConnect 26.6.5.9742.

The Two CVEs

CVE-2026-86218 — N-able N-central: RCE before authentication

N-central is vulnerable to a pre-auth remote code execution. This issue affects N-central: before 2026.3.1.14.

The description is minimal; CISA supplies the category: static code injection. The vector says the rest — network, low complexity, no privileges required, no interaction.

On N-central, a pre-auth RCE doesn't hit a server: it hits the server driving every agent. That's the convergence point of the entire managed estate.

CVE-2026-84869 — ScreenConnect: the flaw is in the client, not the server

This is the most important point in the article, and the one most summaries miss.

A condition in the ScreenConnect client may allow files to be transferred and executed through an active remote session without authorization or Host confirmation in certain circumstances. ScreenConnect servers are not impacted.

Three practical consequences:

1. Patching the server isn't enough. The fix has to reach every endpoint with a ScreenConnect client installed. Across thousands of managed machines, that's a deployment campaign, not a server update.

2. User confirmation is bypassed. ScreenConnect normally lets the person at the machine approve or refuse a file transfer. This flaw short-circuits that control — the one guardrail visible to the end user disappears.

3. The PR:L is misleadingly reassuring. It requires "low privileges" — in practice, an active remote session. In an MSP context, an attacker who has obtained low-level technician access, or compromised a support account, has exactly that.

The S:C (scope changed) reflects reality: the flaw is in the client, the impact lands on the end customer's machine.

Versions

Check N-central:

Admin interface → Help → About

Check deployed ScreenConnect clients:

# Windows — estate inventory
Get-CimInstance Win32_Product |
  Where-Object { $_.Name -like "*ScreenConnect*" } |
  Select-Object Name, Version, PSComputerName

# Or via the installed service
Get-Service | Where-Object { $_.Name -like "ScreenConnect*" } |
  ForEach-Object { (Get-Item (Get-CimInstance Win32_Service -Filter "Name='$($_.Name)'").PathName.Trim('"')).VersionInfo }

The question to ask about ScreenConnect isn't "have I updated?" but "what percentage of my installed clients is on 26.6.5.9742?". It's a coverage metric, not a boolean.

Why RMM Became the Preferred Target

The multiplier

An RMM tool is deployed by a managed service provider across all of its customers. Compromising a mid-sized MSP's RMM server means simultaneous administrative access to fifty to five hundred organisations — small businesses, medical practices, local government, retail — none of which has a security team.

That's the calculation ransomware operators have been making since Kaseya VSA in July 2021, where exploiting a single platform encrypted roughly 1,500 downstream companies over one weekend.

The tool's legitimacy

This is what makes detection hard. An RMM agent is designed to:

• run as SYSTEM
• deploy and launch executables
• open remote sessions
• disable or reconfigure security software

An attacker operating through RMM needs no malicious tooling: they use the product's normal functionality. The EDR sees a legitimate management agent doing what it does every day. Application allowlisting achieves nothing, since the binary is signed and approved.

Late detection

ScreenConnect in particular is also used by attackers as a remote access tool after an initial compromise — to the point that its mere presence on a machine the MSP doesn't service is a classic compromise indicator. That creates background noise which complicates telling legitimate use from malicious use.

Detection

N-central

• Unknown administrator accounts in the console
• Scripts or automated tasks added recently, particularly ones targeting multiple customers at once
• Package deployments not tied to any request
• Unusual application errors in server logs around September 6 (publication date) and after
• Outbound traffic from the N-central server to destinations unrelated to N-able and your customers

ScreenConnect — server side

Administration → Audit

Hunt for:

• File transfers in sessions no ticket justifies
• Sessions opened outside business hours or from unusual addresses
• Technician accounts created or elevated recently
• Sessions to machines outside your managed scope

ScreenConnect — endpoint side

This is where the flaw is exploited, so this is where the traces are:

# Files dropped by the ScreenConnect client
Get-ChildItem "$env:ProgramData\ScreenConnect Client*" -Recurse -File |
  Where-Object { $_.LastWriteTime -gt (Get-Date).AddDays(-30) } |
  Select-Object FullName, LastWriteTime

# Child processes of the client — the decisive signal
Get-CimInstance Win32_Process |
  Where-Object { $_.ParentProcessId -in (Get-Process ScreenConnect* -ErrorAction SilentlyContinue).Id } |
  Select-Object ProcessId, Name, CommandLine

A child process of the ScreenConnect client that isn't a recognised administration tool warrants immediate investigation.

The cross-cutting check

On an endpoint no MSP services, the presence of a ScreenConnect client is itself suspicious. Inventory it across the whole estate, not only on managed machines.

Mitigation

1. Update — both CISA deadlines have passed or are imminent

N-central to 2026.3.1.14, ScreenConnect clients to 26.6.5.9742. For ScreenConnect, run the rollout as a campaign and measure coverage: it's the only indicator that matters.

2. Restrict access to the RMM server

The N-central server shouldn't be internet-exposed without restriction. If technicians access it remotely, route that through a VPN with strong authentication rather than publishing it directly.

3. Mandatory multi-factor authentication — no exceptions

On both platforms, for every technician account. It's the measure that severs the ScreenConnect flaw's PR:L prerequisite, and the highest-value countermeasure against stolen credential reuse.

4. Limit technician account scope

A technician should only reach the customers they handle. An account granting access to the whole portfolio turns an individual compromise into a compromise of every customer.

5. Monitor usage, not just vulnerabilities

File transfers and remote executions should produce logs correlated to a ticketing system. Without that correlation, a malicious session is indistinguishable from normal work — and that is exactly what exploitation of this tool category relies on.

6. If you suspect a compromise

1. Treat the scope as every managed customer, not the server alone
2. Revoke and regenerate all agent tokens and technician credentials
3. Audit scripts and packages deployed over a wide window
4. Notify your downstream customers — in an MSP context, the duty to inform doesn't stop at your own organisation
5. Verify backups before anything else: if an attacker holds the RMM, they also hold the means to reach them

Why Continuous Monitoring of Remote Administration Tools Matters

RMM tools share a blind spot with other infrastructure software: installed by the team that uses them, updated on their own channel, absent from application inventories. But they have one trait that makes them worse — their surface isn't a server, it's every endpoint where the agent is installed, and "am I up to date?" has no binary answer.

With cveo.tech, inventory your remote management and access tools with exact versions, and get automatic alerts whenever a critical CVE affects one — so the rollout starts on publication day, not after the first intrusion.