On Monday, November 9, 2026, N-able took every hosted N-central environment offline, in the Americas, Europe and Asia-Pacific, and told customers who run N-central on their own servers to switch them off too. Hours earlier, an independent researcher had published proof-of-concept exploits for 33 unpatched vulnerabilities in the platform, under the name Able2Shell.

N-central is the remote monitoring and management (RMM) platform many managed service providers use to watch, patch and reach their clients’ machines. Shutting it down was the safe call. It also means that for as long as it stays off, an MSP that relies on it has lost the system that would tell it a client is down. This post covers what happened, what still works, and what to have in place that does not go dark with your RMM.

What happened

Time (UTC)Event
Nov 9, 04:14Sean Bales commits “Able2Shell” to a public GitHub repository: write-ups, screenshots and proof-of-concept scripts for 33 vulnerabilities, grouped into four exploit chains. The README says all of them worked, unpatched, on N-central Appliance 2026.4.0.31.
Nov 9, 14:00N-able’s status page opens a Major Outage incident for N-central, hosted and on-premises, in all three regions.
Nov 9, 15:15N-able says it has not seen active exploitation. Hosted N-central is offline, and on-premises customers are told to “temporarily take their N-central servers offline until further notice”.
Nov 9–10Status updates at about 21:00, 00:00, 05:00 and 09:30. N-able gives an ETA of midday on November 10, US Eastern, for a hotfix.
Nov 10, 17:42N-able says the release is close to general availability.

The flaws are serious. The first chain in the write-up needs no credentials: it ends with commands running on the server and, optionally, a new administrator account. Another needs no credentials either and reaches root once an administrator opens a tampered patch page. Other flaws leak credentials or let an attacker write files on the server. The repository does not say whether N-able was told before publication.

The README calls 2026.4.0.31 a pre-release build and says most, “if not all”, of the vulnerabilities should also work on earlier versions, including the current release. That is why N-able treated every server as exposed.

N-able says it is seeing scanning tied to the published code, but has “no evidence that any customer environment has been successfully exploited”. watchTowr reported exploitation attempts against its N-central honeypots on the night of November 9. Honeypots are decoys, so that shows attempts, not compromised customers.

What still works

N-able’s status page lists what stayed up. Its cloud services behind N-able Login (Asset View, Patching, Vulnerability Management, scripting, policies and tagging) remain online for hosted and on-premises partners. It has also opened N-able.app, Take Control from Asset View and on-demand Windows patching as previews, so technicians can still reach and patch endpoints.

What does not run is N-central itself, and with it the monitoring an MSP has built there: service checks, thresholds, the alerts they raise and the tickets those alerts open. While the server is off, nothing reaches it, so nothing raises an alarm.

The third N-central emergency since August

  • August. Attackers exploited an authentication bypass in on-premises N-central from July 31. N-able says a “limited” number of customers were breached. In the cases reported, attackers took over an administrator account and used Take Control to connect to managed endpoints. CISA added CVE-2026-18556 and CVE-2026-18577 to its Known Exploited Vulnerabilities catalog with a three-day deadline for federal agencies.
  • September. N-able shipped two hotfixes in two days, the second for CVE-2026-86218, an unauthenticated remote code execution flaw rated 10.0. Huntress described it as exploited; N-able’s release notes said it had no confirmation of exploitation in production.
  • November. Able2Shell, and a full shutdown of N-central.

This is not only an N-able problem. An RMM server can reach every machine an MSP manages, and that makes RMM platforms a target for anyone who wants many networks at once. Any MSP should plan for its RMM being unavailable, whichever vendor it uses.

Your RMM is also your monitoring

For most MSPs, the RMM watches the clients. Agents report to the server, and the server decides what is worth an alert. That works until the server is what has to go offline. Then the dashboard does not turn red; it stops. A client’s website, VPN gateway or mail server can fail during the outage, and the first you hear of it is a phone call from the client.

The fix is not a second RMM. It is a small set of checks that run outside your management stack, look at each client from the internet and alert people directly.

What to keep outside the RMM

  1. An outside-in check for each service a client depends on. Their website and portals over HTTPS, a VPN or remote desktop gateway as a TCP port check, mail submission on port 587 or 465, a firewall’s public address with a ping check, and the certificates and domains in front of them. These keep running when your RMM does not, because they do not depend on it.
  2. More than one location. Check from at least two places and alert when more than one fails, so a single bad network path does not page anyone at 3 a.m.
  3. Heartbeats for scheduled jobs. Have each client’s backup job call a heartbeat URL when it finishes. If the call does not arrive on time, you get an alert, whether or not your RMM is up to notice.
  4. Alerts that go straight to people. Send these checks to on-call phones, a Slack or Teams channel and your paging tool, not into a queue that only your RMM or PSA reads.
  5. A status page your clients can find. During a vendor outage like this one, clients want to know whether their systems are affected and what you are doing about it. A status page that is hosted outside your stack lets you say it once. N-able’s own handling is a fair template: one consolidated post, timestamped updates, what still works and what customers should do.
  6. A subscription to your vendors’ status pages. N-able’s page at uptime.n-able.com is where this incident was announced, and it has a subscribe button.

What outside-in checks will not do

They see what the internet sees. They will not tell you a disk is filling up, a patch failed or antivirus stopped running on a laptop, and they cannot reach a server that is only on the client’s internal network. That is still the RMM’s job. They also do nothing for security: if your N-central server was exposed, follow N-able’s guidance and check for signs of compromise.

For on-premises servers, Huntress suggests reviewing logins and authentication activity from November 8 onward, and looking for unfamiliar remote sessions, newly deployed scripts and new administrator accounts. Keep the server offline until N-able confirms it is safe, then apply the hotfix. Huntress notes the hotfix may not change the version number shown, so check N-able’s upgrade guidance for how to confirm it is installed.

If you manage client sites

Our partner program gives each of your clients its own Site Qwality account: 30-second checks from AWS, Google Cloud and Microsoft Azure, alerts to Slack, Teams, SMS and your paging tool, and a status page on the client’s own domain under the client’s brand. We bill you once a month for all of them, and none of it runs through your RMM.

Sources