N-central's Hotfix Is Not Enough: 19 of 21 Compromised Servers Were Patched

TL;DR - On 8 November, security researcher Sean Bales began publishing more than 30 zero-days affecting N-able's N-central remote monitoring platform, under names including Able2Shell and Agent2Shell. N-able took its hosted N-central service offline on 9 November and shipped a hotfix, 2026.4.1.26, on 10 November. On 12 November, Bales published 4EverAble2Shell, an unauthenticated remote code execution chain that reaches root on N-central where the Legacy API is enabled, and attackers were running it within hours. The number that matters most: 21 servers were reported compromised, and 19 of them were running the latest hotfix. Patching alone did not hold, because the hotfix does not remove the Legacy API attack surface that the chain depends on. What you need to do: disable the Legacy API on your N-central server today, apply hotfix 2 and then verify it, coordinate directly with N-able support about the Legacy API restriction, and hunt your server for the XMRig miner indicators rather than assuming the patch closed the matter.

By The Numbers

There is a specific kind of bad day in IT where you patch the thing, feel the relief, and then find out the patch was not the whole answer. The N-central story this week is that day, written up in public.

N-able's N-central is remote monitoring and management software. It sits on a server inside an MSP or an IT department, watches every customer and every endpoint that team looks after, and from that central position it can run scripts, push software, collect credentials and reach into all of those machines. It is one of the most powerful boxes on the network, and it is exactly the box an attacker would want.

On 8 November, a researcher started publishing zero-days against it. On 9 November, N-able took its hosted service offline. On 10 November, a hotfix landed. On 12 November, an exploitation chain was published and attackers used it the same morning. Nineteen of the 21 servers reported compromised were running the fix.

Let me walk you through the timeline, the mechanism, why the hotfix did not hold on its own, and what to do about it today.

The timeline, in order

The N-central week reads like a disclosure that went wrong in every direction at once.

On 8 November, Sean Bales began publishing vulnerabilities against N-central. More than 30 zero-days in the first batch, published under the names Able2Shell and Agent2Shell. Publishing a large number of unpatched vulnerabilities at once is a choice with a predictable consequence, and the consequence arrived quickly. N-able had no coordinated window in which to fix anything quietly.

On 9 November, N-able took its hosted N-central service offline. That is a significant step. A vendor does not switch off a hosted service that customers depend on for monitoring and patching unless the alternative is worse.

On 10 November, N-able shipped hotfix 2, version 2026.4.1.26. For many administrators, that was the point where the incident felt handled. The fix was out, and the job was to apply it.

On 12 November, Bales published a new chain called 4EverAble2Shell. It reached unauthenticated remote code execution with root privileges on N-central where the Legacy API is enabled. Within hours, attackers were using it. A honeypot operated by Previdian recorded probing at 08:30 UTC and the full chain executing at 09:16 UTC, which is a 46-minute gap between someone testing the waters and someone finishing the job.

By the time the reporting caught up, 21 servers had been counted as compromised. Nineteen of them were running hotfix 2.

What 4EverAble2Shell actually is

The chain is described as an Apache Axis vulnerability combined with an N-central flaw, and the condition that makes it work is a configuration choice rather than a coding mistake.

Apache Axis is an older web services engine that exposes SOAP endpoints. Many products carry an Axis component for backwards compatibility, often long after the rest of the product has moved on. When that Axis surface is reachable, and when N-central's Legacy API is enabled on the same server, the two combine into a path that reaches code execution as root without the attacker logging in first.

The Legacy API is the part to underline. Modern APIs have authentication, rate limits, logging and review. A legacy interface tends to have whatever protection it shipped with years ago, kept alive because some integration still calls it. N-central's Legacy API existed to support older tooling, including the Microsoft Intune integration, and that is the surface the chain abuses.

So the honest description of the vulnerability is this: an attacker needs the right interface reachable, and if it is, the path to root does not require a credential.

Why the hotfix is not the finish line

This is the finding that makes the N-central story different from a routine patch race, and it deserves to be the spine of your response.

Hotfix 2 addressed code, and 19 of the 21 compromised servers had it. A hotfix cannot remove an attack surface that exists because a supported feature is switched on. If Legacy API is enabled, the interface is there, and the fix for the specific flaw in the chain does not change the fact that the interface is what an attacker needs.

N-able's own response acknowledges this. Alongside hotfix 2, the vendor restricted the Legacy API and the Intune integration, and its guidance tells customers to disable the Legacy API and coordinate with N-able support. That is unusual language for a vendor, because it means the fix is not complete until you make a configuration change and talk to the vendor about how your integrations will keep working.

For anyone whose N-central server depends on the Legacy API for an Intune integration or some other older tooling, the practical sequence is awkward and unavoidable. You disable the interface that the vulnerability needs, and then you work out with N-able how the integration is supposed to function afterwards. The alternative is leaving root-reachable code execution on a box that manages every endpoint you own.

The exploitation numbers

Two timestamps tell the story of how fast a public proof of concept turns into an attack.

The Previdian honeypot saw probing at 08:30 UTC on 12 November and the full chain at 09:16 UTC. Under an hour between reconnaissance and a working exploit against a live system. That is consistent with everything the patch-window conversation has been saying this year: the distance between a published proof of concept and automated tooling has collapsed.

The compromise count runs the other way. Of the 21 servers reported compromised, 19 were running hotfix 2. That ratio is the reason this post exists. It means the population that patched promptly and the population that got hit are substantially the same population. Patching moved from a solution to a first step, and the step that actually removed the exposure was the configuration change most people had not made yet.

The payload is a cryptocurrency miner. XMRig, the same commodity miner that shows up in the long tail of almost every appliance compromise. That is worth noting for two reasons. A miner is noisy and it consumes the box's CPU, which is how a lot of these compromises get noticed in the first place. And a miner is not the ceiling of what an attacker on an RMM server could do. Someone who reaches root on the platform that manages an entire customer estate can deploy ransomware, steal credentials, or stay quiet. Mining is what this campaign chose. The access it obtained is worth far more.

Why this could be good

There is a real disclosure-process lesson in the week, and it is not flattering to either side.

The good part is that the vendor response was unusually fast and unusually frank. N-able took a hosted service offline on 9 November rather than waiting for a clean fix, shipped a hotfix on 10 November, and then told customers that the hotfix was not sufficient on its own and that they needed to disable a feature and contact support. A vendor saying "our patch is one step of several" is a harder message to send than "apply the update", and it is the message that actually protects people.

The other genuinely useful thing is that the exploitation was visible fast. Honeypot probing at 08:30 UTC and a full chain at 09:16 UTC gives defenders a concrete sense of the window. There was no phase where anyone could reasonably believe they had weeks. The proof of concept was public and the attack followed inside a morning.

But the week also shows what uncontrolled disclosure costs. Publishing more than 30 zero-days at once against a platform that manages other companies' entire estates left N-able fixing in public, under attack, while its customers absorbed the risk. There is a case for hard disclosure when a vendor is unresponsive. The reporting does not establish that N-able was unresponsive, and the outcome for customers was a scramble either way.

Concerns

Three things keep this from being a story with a clean ending.

First, hotfix insufficiency is a pattern now, not an exception. When a vulnerability is reachable through a legacy interface, the code fix and the exposure fix are different tasks, and the second one lives in a configuration screen that nobody wants to touch because an integration depends on it. Expect more of this shape, and treat "patched" as a question to verify rather than a state to assume.

Second, an RMM server is a supply chain crown jewel. N-central does not just hold its own credentials, it holds the ability to run commands across every client estate the MSP or IT team manages. A compromise at root on that box reaches down into customers who have no visibility into it. Nineteen patched servers being compromised means the exposure was at the platform layer, but the blast radius is every endpoint underneath.

Third, integration pressure works against the mitigation. The Legacy API exists because something calls it. Disabling it breaks that integration, and the business will want it back. Whatever replaces the integration has to be reviewed by someone who can read an authentication path, not just configured by whoever is on support that day.

What to do right now

1. Disable the Legacy API on your N-central server today. This is N-able's own guidance and the single action that removes the attack surface 4EverAble2Shell depends on. Do not wait for the hotfix conversation to finish before doing this.
2. Apply hotfix 2 (2026.4.1.26), then verify it. Nineteen compromised servers were running it, so treat installation as a claim and confirm the version and build on the box. If a provider manages the server, get the version in writing.
3. Contact N-able support about the Legacy API restriction and any Intune integration. The vendor restricted the Legacy API and Intune support, which means your integration may already be affected. Get the migration path in writing rather than working it out from a knowledge base article.
4. Hunt for the miner and for the intrusion. XMRig is the observed payload, so look for the process, its network connections and the CPU load. Then look wider, because the miner is the low end of what root on an RMM server can do.
5. Check who can reach the N-central admin and API interfaces. If either surface answers from the public internet, close that path today. The chain needs reachability, and an internal-only management interface removes most of the risk in one change.
6. Audit the integrations that depend on old interfaces. Every legacy API call in your tooling is a candidate for the next version of this story. Inventory them, and decide per integration whether it still earns its place.
7. Treat your RMM server as a tier-zero asset. Separate its credentials from anything else, review which accounts can log in to it, and make sure the answer to "what does this server control" is written down somewhere a new starter could read.

Key Takeaways

• N-central had more than 30 zero-days published from 8 November 2026. The batch, named Able2Shell and Agent2Shell, led N-able to take its hosted service offline on 9 November and ship hotfix 2 (2026.4.1.26) on 10 November.
• 4EverAble2Shell is unauthenticated RCE to root where the Legacy API is enabled. It chains an Apache Axis vulnerability with an N-central flaw, and it was published on 12 November.
• The hotfix was not sufficient on its own. Nineteen of the 21 compromised servers were running hotfix 2, and N-able's guidance is to disable the Legacy API and coordinate with support.
• Exploitation came within hours. A Previdian honeypot saw probing at 08:30 UTC and the full chain at 09:16 UTC on 12 November.
• The observed payload was an XMRig cryptocurrency miner. The access obtained is worth far more than the miner, which is why the hunt matters after the patch.
• Patching is a step, not a state. Where a legacy interface is the exposure, the configuration change is the fix and the code fix is the prerequisite.
• An RMM server is a supply chain crown jewel. Root on N-central reaches every endpoint that server manages, including customers who never see it.

FAQ

Am I affected if I run N-central on premises? Yes, potentially. The chain needs the Legacy API enabled and the relevant interface reachable. N-able's guidance applies to on-premises and hosted customers alike: apply hotfix 2, disable the Legacy API and contact support about any integration that depended on it.

Is applying hotfix 2 enough? Not on its own, and the incident count makes that clear. Nineteen of the 21 compromised servers were running the hotfix. The hotfix addresses code, and the exposure is a configuration surface, so the Legacy API has to be disabled as well.

What is the Legacy API and why is it still there? It is an older interface that N-central kept for backwards compatibility with tooling such as the Microsoft Intune integration. Legacy interfaces survive because something depends on them, which is exactly why they are the least reviewed and often the least protected surface on a server.

How fast was the exploitation? Very fast. A honeypot recorded probes at 08:30 UTC on 12 November and the full chain at 09:16 UTC, so a working attack followed the public proof of concept inside a morning.

What should I look for to see if I was hit? The observed payload is the XMRig cryptocurrency miner, so start with unexpected CPU load and a process you do not recognise, then look at outbound connections from the N-central server. Because the access is root on a management platform, keep hunting past the miner rather than stopping when you find it.

Does this affect N-able's other products? The reporting focuses on N-central. If you run other N-able tooling, ask the vendor directly which products share the Legacy API component and whether the same chain applies.

Should I take my N-central server offline? Only if you cannot disable the Legacy API and close the management interface today. Taking it offline is a big operational decision, since it is the server doing your monitoring and patching. N-able's recommended path is to disable the exposed feature and coordinate with support, and that is the smaller disruption.

What if a provider manages N-central for us? Ask them for three things in writing: their N-central version and hotfix level, whether the Legacy API is enabled, and whether the management interface is reachable from the internet. Their exposure is your exposure, because the platform manages your endpoints.

My Take

The number I cannot get past is nineteen out of twenty-one.

A hotfix shipped on 10 November, attackers published a chain on 12 November, and two days later the servers that got compromised were mostly the servers that had taken the fix. That is the whole shape of modern incident response in one ratio. Patching is not the finish line any more, and treating it as one is how a patched estate ends up in a breach report.

The reason is almost always a legacy interface. The Legacy API, the old SOAP endpoint, the integration nobody wants to break, the port that has been open since before the current team joined. Those surfaces are not oversights in the sense of laziness. They are deliberate decisions to keep something working, made by people with a business to run and no time to review an authentication path on a component nobody thinks about.

So the lesson is not "patch faster". Everyone already knows that, and the people at 19 of those servers did patch. The lesson is to know which of your interfaces still carry an integration that predates you, and to have an answer ready for what happens when one of them becomes an attack path. Disable the Legacy API today, then spend the rest of the week working out how you will live without it.

Further Reading

• BleepingComputer: New N-able "4EverAble2Shell" zero-day exploited hours after PoC released - the chain, the timestamps and the Legacy API condition
• The Hacker News: Hackers Exploit N-central Flaws to Infect 21 Servers, Including 19 Running Hotfix - the compromise count and the hotfix ratio
• TechCrunch: N-able takes its remote access service offline after researcher publishes dozens of zero-day bugs - the disclosure sequence and the hosted service shutdown
• The private key was the number 4: test your estate before the long tail bites - the same pattern of a hard-coded or default value becoming the whole vulnerability
• PHP2Shell is coming: your patch window is 15 minutes - patch speed as an operations problem, and the preparation that has to happen before the advisory
• PaperCut NG/MF zero-day: the print server MSP checklist - managed tooling as the attack path, and the ownership question that decides your week
• Metabase zero-day: check your instance - the internal-tooling exposure that turns into an incident on patched servers
• SonicWall SMA zero-days and the ANZ branch office patch - internet-facing management interfaces and the response checklist that still holds

Mathew Clark Founder, SecureInSeconds Currently: reading "19 of 21 were patched" out loud to anyone who still thinks the patch button is the whole plan Drafted with AI assistance - read, verified, and fixed by a human.