RMM Agent Inventory: What the N-able N-central Shutdown Means for Your Cloud Workloads

On 9 November 2026, N-able took its hosted N-central environment offline worldwide and told customers running on-premises servers to switch theirs off too, “until further notice”. The trigger was a public GitHub release, branded “Able2Shell”, in which an independent researcher published details and proof-of-concept code for 33 alleged vulnerabilities in N-central. If your managed service provider (MSP) uses N-central, the first useful question this morning is not “is it patched?” It is: which of our cloud workloads run an RMM agent, what can that agent do, and what stops working while its console is dark? That question is an RMM agent inventory, and most organisations cannot answer it quickly.

This article walks through what is known, what is not, and how to build that inventory across AWS, Azure and Google Cloud in an afternoon.

What happened, and what is still unconfirmed

Here is what the reporting supports as of 9 November (sources at the end):

• Vendor action (confirmed by N-able, as quoted by Huntress and Field Effect): hosted N-central was taken offline on 9 November. On-premises customers were advised to take their servers offline and keep them offline until N-able confirms they can be restored. N-able said it had not seen active exploitation as of 9 November, 15:15 UTC, and was working on a hotfix with no ETA.
• Researcher claims (not yet confirmed by the vendor): 33 vulnerabilities, chainable into four exploits (three remote code execution, one escalation to root). One chain reportedly starts with an unauthenticated XML external entity (XXE) flaw. Testing was on N-central appliance build 2026.4.0.31, and the researcher says earlier builds are likely affected.
• No CVE identifiers had been assigned at the time of writing.

This is the fourth N-central security event this year. Huntress notes that an earlier flaw, CVE-2026-86218, was actively exploited, and that attackers used it to push unauthorised scripts and tools into downstream environments. That history explains why the vendor chose a full shutdown over a quiet hotfix.

Check N-able’s status page for the latest position before acting; this is a fast-moving situation.

Why an RMM console is a cloud security problem

Remote monitoring and management (RMM) tools are built to do exactly what an attacker wants: run scripts, install software and open remote sessions on every managed machine, usually as SYSTEM or root. When an MSP manages your cloud virtual machines, the RMM agent on those VMs is a remote-execution channel that sits outside your cloud provider’s identity and access controls. Your IAM policies, conditional access rules and security group reviews don’t cover it. The agent makes an outbound connection to the vendor and takes instructions from whatever the console says.

That creates two separate risks:

1. Compromise risk. If the console is breached, every agent becomes a way into your estate. Our Puppet piece yesterday covered the same pattern for configuration management. The difference here is that the console isn’t yours, and you may not know it exists.
2. Continuity risk. When the vendor pulls the plug, patching, monitoring, backup checks and scripted maintenance can all stop at once. If nobody listed what the RMM was doing, nobody knows what has quietly stopped.

Building an RMM agent inventory: a practical how-to

You don’t need the RMM console to find its agents. Your cloud providers already collect software inventory if you turn it on.

Step 1: Find the agents from the cloud side.

• AWS: Systems Manager Inventory records installed applications on managed instances. Query it, or the Resource Data Sync output in Athena, for your RMM vendor’s name across all accounts and regions.
• Azure: use Defender for Cloud’s software inventory or Change Tracking and Inventory to list installed software. Also check VM extensions, because some MSPs deploy agents that way.
• Google Cloud: VM Manager’s OS inventory reports installed packages per instance.

Instances that are not covered by these tools are a finding in their own right. Note them too.

Step 2: Confirm from the network side. An agent that phones home leaves egress traffic. Search VPC Flow Logs, NSG flow logs or firewall logs for connections to your RMM provider’s domains and IP ranges. This catches agents on hosts your inventory tooling can’t see.

Step 3: Record what each agent can do. For each host, note the account the agent runs as, whether it allows remote shell or scripting, and which MSP or tenant owns the console. An agent on a domain controller, a bastion host or a backup server belongs in your highest risk tier.

Step 4: Record what the console holds. RMM platforms often store domain admin credentials, cloud API keys inside scripts, and integration tokens. List them, because if the console is ever confirmed compromised, these are what you rotate first.

Step 5: Write the “vendor dark” runbook. For each function the RMM performs, name a fallback. Native options include AWS Systems Manager Patch Manager and Session Manager, Azure Update Manager, and Google Cloud’s OS patch management. Test one fallback before you need it.

Impact assessment

The CloudShieldSecure perspective

Incidents like this come down to one question: what is running in our cloud, and who can give it orders? CloudKonsult built CloudShieldSecure to answer that continuously, not during an emergency. CloudShieldSecure keeps an inventory of cloud assets and their network exposure across accounts. It also tracks third-party integrations and the access they hold, so “which workloads talk to an outside management service?” is a lookup, not a project.

Last week we wrote about third-party cloud access reviews after the Northflank breach, which covered vendor roles in your cloud accounts. RMM agents are the other half: vendor code running on your workloads. And as our Puppet Server RCE analysis argued, any system that can push commands to your fleet belongs in Tier 0, alongside your identity provider. Learn more at cloudshieldsecure.cloudkonsult.cloud.

Recommended actions

1. Today: ask every MSP and IT provider directly whether they use N-able N-central, and whether any of it touches your environment.
2. Today: if you run N-central on-premises, follow the vendor’s advice. Keep it offline until N-able confirms it is safe to restore.
3. This week: review N-central login, authentication and audit activity from 8 November onwards, as Huntress recommends. Look for new administrator accounts, unexpected scripts or software deployments, and unusual remote-control sessions.
4. This week: build the RMM agent inventory above for all RMM vendors, not just N-able.
5. If anything looks unusual: rotate the credentials stored in or used by the RMM: admin accounts, service accounts and integration tokens.
6. This month: write and test the “vendor dark” runbook for one critical function.

Sources and references

• Huntress, “N-able Disables Cloud Services Following Disclosure of ‘Able2Shell’ Exploit Chains” (9 Nov 2026): https://www.huntress.com/blog/n-able-disables-cloud-services-following-disclosure-of-able2shell-exploit-chains
• Field Effect, “N-able takes N-central offline as alleged zero-day exploits surface” (9 Nov 2026): https://fieldeffect.com/blog/n-central-offline-alleged-zero-days
• SecurityOnline, “Researcher Publishes Details and PoC Exploits for 33 N-able N-central Vulnerabilities” (9 Nov 2026): https://securityonline.info/n-central-vulnerabilities-poc-exploit/
• N-able status page: https://uptime.n-able.com
• AWS Systems Manager Inventory: https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-inventory.html
• Google Cloud VM Manager OS inventory: https://cloud.google.com/compute/docs/instances/os-inventory-management