N-able’s N-central remote monitoring and management (RMM) platform is having the worst week an RMM vendor can have. On Sunday, November 8, an independent researcher released public proof-of-concept exploits for what they say are 33 zero-days in N-central. N-able responded by taking its hosted N-central environments offline worldwide and shipped an emergency hotfix on November 10. A day later the same researcher published two more exploit chains, 4EverAble2Shell and Agent2Shell, which are reported to work against the patched build. Exploitation attempts reportedly began within hours of the PoC release.

N-central is the fifth N-able disclosure we’ve covered since August, after CVE-2026-18556, CVE-2026-18577 (which Storm-1175 used to deploy StormEncryptor ransomware), and CVE-2026-86218. Because an N-central server pushes scripts and binaries to every endpoint it manages, compromising one server means compromising the downstream fleet of every MSP client on it.

Timeline

  • Nov 8: Researcher Sean Bales (who posts as “MSPNightmare”) publishes the Able2Shell GitHub repository, with PoCs for 33 alleged flaws tested against N-central Appliance 2026.4.0.31. The bug classes include credential disclosure, arbitrary file write, directory traversal, XSS, XXE injection, and an unauthenticated XXE-to-RCE chain that gives full administrator takeover. N-able did not receive coordinated disclosure.
  • Nov 9: N-able takes hosted N-central offline in the Americas, Europe, and APAC, and tells on-prem customers to shut their servers down. It also reports scanning that uses the public PoCs.
  • Nov 10: N-able releases N-central 2026.4 Hotfix 2 (build 2026.4.1.26). Its documented scope is seven CVEs, not 33. Hosted servers are upgraded, but partners still have to update Agents and Probes. Some reports date the hotfix to Nov 11.
  • Nov 11: Bales publishes 4EverAble2Shell and Agent2Shell and claims both work against 2026.4.1.26.

The new chains

4EverAble2Shell is an unauthenticated, server-side chain that ends with root on the N-central appliance. Initial access comes from CVE-2026-90436 (CVSS 9.8) in the bundled Apache Axis SOAP stack, which serves N-central’s Legacy API. The attacker then uses a separate N-central local privilege escalation to go from the web service account to root. Huntress’s code review supports the claimed path to root. Aviatrix reports reproducing the bypass of Hotfix 2.

Agent2Shell targets the server-to-agent channel rather than the server. It is a bundle of more than ten issues in how N-central talks to its Windows Agents and Probes, and it ends with code execution as NT AUTHORITY\SYSTEM on managed Windows endpoints. Bales notes one precondition: the attacker must know the target’s appliance ID. That limits blind mass exploitation, but it is no real barrier once the server is compromised or its IDs have leaked.

Exploitation status: contested

N-able says it has no evidence of successful exploitation in any customer environment. It also says 4EverAble2Shell depends on a non-default configuration, with the Legacy API enabled and exposed to the internet. Researchers disagree. BleepingComputer reports confirmed exploitation against production servers. Researchers counted at least 21 affected installations, 19 of them already on the latest hotfix, with attackers dropping cryptocurrency miners. Miners are the usual opening act. Ransomware crews like Storm-1175 have already shown they will turn N-central access into fleet-wide encryption.

What to do now

  1. Take on-prem N-central off the internet. That means behind a VPN or allowlisted management network only, whether or not you have Hotfix 2. Huntress advises treating fully patched servers as vulnerable.
  2. Disable the Legacy API if you don’t explicitly need it. This removes the reported 4EverAble2Shell entry point. It does not address Agent2Shell.
  3. Apply 2026.4 HF2 (2026.4.1.26) and update every Agent and Probe. The server upgrade alone leaves the agent-side fixes undeployed. Watch for the follow-up hotfix N-able has said is coming.
  4. Leave integrations off. N-able has restricted some features and integrations, including Intune, as a precaution. Don’t re-enable them until N-able clears them.
  5. Hunt. Look for unexpected processes running as the N-central service user or as root on the appliance. Look for new cron entries, systemd units, or SSH keys, and for outbound mining-pool connections. Review the scripts and automation policies pushed to agents since Nov 8. On managed Windows endpoints, look for SYSTEM-level process creation from the N-central agent that doesn’t match a known automation policy.
  6. Rotate credentials stored in or reachable from N-central (domain admin, PSA, backup, and cloud API keys) if the server was internet-exposed at any point after Nov 8.

The bigger lesson is familiar from the ConnectWise and Kaseya incidents. An RMM server is a supply-chain node with root on everything downstream. It belongs behind the same access controls as a domain controller, not on the open internet.

References