CRITICAL: N-able N-central Exploited on 21 Servers Despite Hotfix 2

If you run N-central, this has been a week of patching and then finding out the patch wasn't enough. On Tuesday, N-able shipped N-central 2026.4 Hotfix 2 to close the Able2Shell bugs that researcher Sean Bales published over the weekend. By Thursday, Bales had released a new set of exploits that work against Hotfix 2 itself. By Friday morning, the security firm Huntback reported that attackers had used one of those chains, dubbed 4EverAble2Shell, to take over 21 N-central servers. Nineteen of the 21 were running the hotfix N-able had just told everyone to install.

That should get every MSP's attention. N-central isn't some forgotten departmental web app. It's the RMM console that pushes scripts, patches and remote sessions to every endpoint an MSP manages. Root on the N-central server puts an attacker one step from SYSTEM on every client machine behind it. This is the fourth emergency response N-able has run in about 15 months, and patch fatigue is beginning to look like a real attack surface of its own.

The Bug Underneath It All

The heart of 4EverAble2Shell is not N-able's code. It's CVE-2026-90436, a critical flaw in Apache Axis 1.x, the long-retired Java SOAP engine that a surprising amount of enterprise software still carries around. The Apache Axis project disclosed it on November 6, 2026, scored at CVSS 9.8, and classified it under CWE-470, the "use of externally controlled input to select classes or code" weakness, also known as unsafe reflection.

The mechanics are elegant in a way that should make any Java developer uncomfortable. Axis 1.x deserializes inbound SOAP fault messages without any authentication. If a fault contains a detail block with an exceptionName element, Axis helpfully loads whatever class that element names. If the fault also carries a String data element, Axis goes further and calls that class's String constructor before it ever checks whether the class is an AxisFault. Loading a class runs its static initializer, and calling a constructor with attacker-supplied input runs whatever logic that constructor contains. Any gadget on the classpath with a useful constructor becomes a code execution primitive. Because the fault is parsed before per-service handler chains run, the authentication handlers that admins assume are protecting the endpoint never get a vote.

Here's the part that matters most. Every Axis 1.x release through 1.4 is affected, and the Apache Axis project has said plainly that it does not expect to ship an Axis 1.x release fixing the problem. The project marked the CVE "unsupported when assigned." The official guidance is to migrate to a different SOAP engine such as Axis2/Java, or to cherry-pick the fix from commit 41f3b4e8 into your own Axis build. Your vendor can do that for you. Nobody upstream is going to.

N-central isn't the only product in that position. Atlassian has already tracked CVE-2026-90436 for Confluence Data Center, rated it critical at CVSS 9.3 under CVSS 4.0, and fixed it in version 9.2.28 and later. The exposure there depends on the Remote API for XML-RPC and SOAP being enabled, and that feature was removed entirely starting with Confluence 10.0, so newer releases are out of the blast radius. If you manage older Confluence instances for clients, add them to this week's list.

How the N-central Chain Works

In N-central, the Axis flaw is reachable through the Legacy API. According to Bales and to the exploitation details published by Previdian, a crafted SOAP request makes N-central's bundled Axis instantiate an attacker-chosen JLine class with malicious input. The result is command execution as the nable service account. From there, 4EverAble2Shell chains a separate N-central local privilege escalation weakness to get root. N-able hasn't published a CVE identifier for that second step, and the CVE-2026-90436 identifier is the only one currently attached to the chain.

Bales also released a second set of exploits called Agent2Shell, which he says strings together more than ten additional zero-days to run commands as NT AUTHORITY\SYSTEM on managed Windows agents. The attacker needs to know the target appliance ID for that one, which is a hurdle but hardly a wall once you already own the server. N-able has not yet confirmed how many of the claimed flaws it has reproduced across either disclosure.

N-able's position is that the server-side issue depends on a non-default configuration in which the Legacy API is enabled and exposed to the internet. That's true, and it's also the kind of reassurance that ages badly. Legacy integrations tend to stay switched on because one automation somewhere still depends on them, and nobody wants to be the person who breaks it. Hosted N-central customers are not affected by the server-side chain, according to the company. On-premises deployments in the Americas, APAC and Europe are.

What Exploitation Looks Like Right Now

The timeline is short. Previdian's Ryan Dewhurst saw targeted probing for 4EverAble2Shell within hours of the proof of concept going public, all from the IP address 157.20.241[.]16, and called it the first documented exploitation attempt against CVE-2026-90436 anywhere. watchTowr reported similar probes against N-central builds with the Legacy API turned on. Within a day, Huntback confirmed that the same IP had compromised 21 servers, with victims concentrated in the United States, South Africa, Canada, the United Kingdom, Germany, France and Sweden.

The observed sequence is simple. The attacker gets initial execution through the Axis flaw, escalates to root with the N-central local weakness, remounts /tmp with exec permissions, then uses curl to pull a script named jup.sh from port 8080 on the attacker's server and pipes it straight into sh. The payload so far has been an XMRig Monero miner configured to use only about half of the available CPU cores, presumably so nobody notices fans spinning in the server room. The attacker also sent diagnostic information and command output back to the same server.

A cryptominer is the good news, if you squint. It means the first wave of attackers is monetizing compute, not client networks. But the operator already has root on an RMM server and is collecting host details, so that could change at any time. Huntback put it bluntly and said any hit should be treated as "a full compromise, not a cleanup job." Remember that in August, Microsoft tied exploitation of the earlier N-central flaws CVE-2026-18556 and CVE-2026-18577 to Storm-1175, a financially motivated group that used compromised N-central servers to deploy StormEncryptor ransomware onto MSP-managed endpoints. Somebody is going to try that again with this chain.

What to Do Today

First, disable the Legacy API if it's on. N-able says it is off by default and not recommended, and it has urged every on-premises customer to confirm it's disabled. If something in your stack still needs it, put it behind a VPN or an IP allowlist today and plan its retirement this quarter. An internet-facing Legacy API on N-central right now is an open invitation.

Second, keep Hotfix 2, which is build 2026.4.1.26, and finish the agent and probe upgrades. N-able says upgrading both is mandatory for managed devices to keep communicating and receiving patches, because the release changes how probes and agents talk to the server. Hotfix 2 does not stop 4EverAble2Shell, but it does close the seven Able2Shell CVEs from earlier in the week, CVE-2026-125878 through CVE-2026-125883 and CVE-2026-91000, and you don't want to fight two fires at once. Huntress has also warned that a patched server may not show a new version number, so verify against N-able's guidance and not the version string.

Expect some features to be missing for a while. N-able is restricting certain N-central features and integrations while it builds additional remediation, and in hosted environments the Intune integration is turned off until new protections are validated. That will annoy some techs. It's better than the alternative.

Third, hunt. Search for any connection to or from 157.20.241[.]16, any request on port 8080 for jup.sh, any remount of /tmp with exec, and any curl output piped into a shell from the nable account or root. Look for unexplained XMRig processes or sustained CPU usage around the 50 percent mark. Review authentication activity from November 8 onward and look for admin accounts, scripts, scheduled tasks and remote sessions your team didn't create. If you find any evidence of compromise, preserve logs and a snapshot before you touch anything. Then rebuild rather than clean, rotate admin and technician credentials, agent registration tokens and integration keys, and assess every client network that server manages.

Finally, audit everywhere else Axis 1.x may be hiding. Confluence Data Center before 9.2.28 with the Remote API enabled is the obvious one, but plenty of older Java applications bundle axis.jar without advertising it. A quick search of your file systems for axis-1.4.jar or axis.jar will tell you more than any vendor questionnaire.

If an IT provider manages your systems

Many outside IT providers use N-able N-central to send patches, scripts and remote sessions to every computer they manage. If their N-central server is taken over, an attacker can reach your machines through it. Attackers have already taken over 21 of these servers using a flaw that the latest hotfix does not stop.

• Do you run N-central on your own server, and is the Legacy API turned off or blocked from the internet?
• Have you installed Hotfix 2 (build 2026.4.1.26) and finished the agent and probe upgrades?
• Since November 8, have you checked your server for signs of this attack, including connections to 157.20.241[.]16?

A good answer is specific. They tell you whether N-central is hosted or on their own server, confirm the Legacy API is off, and share the results of a search they have already done. If they are unsure, or they find any sign of compromise, bring in incident response to check the server and every computer it manages.

If you are an IT provider yourself, see how we partner with MSPs.