N-able's fourth hotfix is the one that closes the N-central code injection

Every term in the vector behind that 10.0 describes the vulnerable host: network-reachable, low attack complexity, no privileges, no user interaction, high impact on confidentiality, integrity and availability ^[2]. An N-central console holds credentials and agent relationships for managed endpoints, and it can push scripts, install software and change configuration across an entire customer estate ^[11]. An attacker with code execution there never has to touch an individual endpoint, because the platform handles distribution ^[19]. The dev.to analysis states the economics directly: one successful intrusion can produce hundreds of downstream footholds ^[20].

So for the 10.0 to describe an operator's actual exposure, the console would have to reach nothing but itself. On an MSP's console it reaches the estate. If your patch queue is sorted by base score alone, this sits beside any other 10.0 ^[16].

N-able's guidance notes that instances which had applied Hotfix 3 were still affected ^[4]. The fix is N-central 2026.3 Hotfix 4, which is build 2026.3.1.14 ^[5]. Hosted instances were remediated by the vendor, and self-hosted deployments require a manual upgrade ^[14]. Three calendar days separated the KEV listing from the federal remediation deadline ^[17]. That is a single maintenance window on the tool an operations team normally uses to schedule maintenance.

The dev.to account also reports that public reporting described at least one fully patched N-central instance as compromised, with the exploitation chain not confirmed at the time ^[9]. Because the chain is unconfirmed, that report does not show Hotfix 4 failing, and it is still a reason to treat an exposed console as a system needing investigation: after upgrading, look for administrative accounts nobody created, scheduled tasks nobody recognises, and outbound connections that do not match normal operations ^[10].

On exposure, the same analysis argues the console should not be reachable from the open internet by default, and that where remote access is required it should sit behind known administrative networks and strong authentication, with a proxy that can enforce access policy ^[13]. It puts the RMM in the trust tier of a domain controller or a hypervisor management plane, with dedicated administrative accounts, credentials separate from the rest of the environment, and monitoring that does not run through the RMM itself ^[12].

September's KEV additions included workflow orchestrators, artifact repositories, AI gateways and edge VPN appliances, and what they share, the dev.to piece notes, is administrative reach ^[15].