N-central root chain: the hotfix is not the fix, Legacy API is

Sean Bales published exploit code for a new N-able N-central chain on November 12. Lupovis and Huntback saw the first successful compromises about five hours later, with an XMRig miner installed and kept alive through systemd or cron. Lupovis tied 21 mining rigs to compromised N-central servers, nine in the US, four each in South Africa and Canada, one each in the UK, Germany, France and Sweden.

Huntback, which wrote the chain up separately, reported that 19 of those 21 had N-able's latest patches on.

That is the number to take to your change board. The chain, 4EverAble2Shell, is unauthenticated remote code execution ending in root on the server, with no credentials needed. Bales says it works against 2026.4 HF2, build 2026.4.1.26, the hotfix N-able shipped on November 10 to close the first Able2Shell disclosure, and Huntress has not reproduced that itself but advises treating a fully patched server as vulnerable. The first stage is an exploit for CVE-2026-90436, a 9.8-rated flaw disclosed on November 6 in Apache Axis 1.x, a SOAP engine that is past end of life. The second stage, which SecurityWeek describes only as an unspecified hole, needs one thing: the Legacy API switched on.

The setting, not the build

This is the part worth getting right before anyone spends the weekend on an upgrade. N-able says the server issue depends on a configuration that is not the default: Legacy API enabled, and reachable from the open internet. The exploit's author updated the repository to say the same thing, and Huntress reports that a server on HF2 with Legacy API disabled is not exposed to this chain. N-able has published a knowledge base article for turning it off on on-premises servers, has restricted Legacy API and the Intune integration itself, and is not telling customers to take N-central offline this time. It also confirmed that Agent2Shell, the companion set of roughly a dozen flaws that reach managed Windows endpoints as SYSTEM, needs the same non-default setting.

So the patch state of your server is the wrong question tonight. The right one is whether Legacy API is on, and whether anything on the internet can reach it. One gap to keep in view: Huntback has not published the addresses of the 21 servers or said whether Legacy API was enabled on them, so the link between that setting and those particular compromises is inference rather than a stated finding.

One trap in the mitigation: Huntress warns against relying on IP allowlisting alone, because the endpoints involved are the ones Agents and Probes already use for check-ins. A machine sitting on an allowed network reaches them just as easily.

Indicators N-able released today

N-able updated its advisory at 13:40 UTC on November 13, as reproduced by Huntress, with indicators for customers who have not disabled the Legacy API. Its own list is the URLs and the outbound traffic below: the URLs sit on one staging host, and the outbound list adds two more addresses.

• URLs on 157.20.241[.]16 port 8080: jup.sh, xvgz, xmrig.tgz, an ob/cronhit request carrying a rig name and a persistence method, and ob/fcheck.
• Outbound traffic to 157.20.241[.]16 on port 8080 and on ports 19202 to 19418, to 139.99.69[.]109 on port 10128, and to 79.76.51[.]56 on port 39100.

The next two sets are not N-able's. They come from Huntress's static review of the published exploit code, and Huntress says none of them had been seen in the wild when it wrote them up.

• On the server: /var/opt/n-central/flag/flag_default.json present as a symlink to a ServerChild.sh script, serverchild files with a 12-character hex suffix under /var/opt/n-central/tmp/, and POSTs to /dms/services/ServerUI or /dms2/services2/ServerMMS2 carrying a session ID of -1.
• On managed Windows endpoints, encoded PowerShell running as SYSTEM spawned by the N-able Agent, and wsp.exe or service.cfg written into the Windows Software Probe bin directory. Both processes are normal children of N-able software, so the command matters more than the process tree.

Lupovis told SecurityWeek that each victim's miner was named after its IP address. SOCRadar's caution applies to all of the above: no match does not mean a clean server.

What IT teams and MSPs should do

• Confirm Legacy API is disabled on every on-premises N-central server, and where it has to stay on, take it off the internet and restrict access to the server.
• Apply 2026.4 HF2 anyway, and keep the server off the internet until the upgrade has finished, which is what N-able asks for. N-able has already applied the hotfix to hosted servers, and says all customers, hosted and on-premises, must upgrade Agents and Probes as well. It says the hotfix closes every flaw an unauthenticated user could reach, with the authenticated ones coming in a later hotfix.
• Where Legacy API was on and reachable, go back over server and endpoint activity starting November 11, rather than from today.
• If anything matches, follow Huntback's line and treat it as a full compromise rather than a cleanup job. This is an RMM server, so the blast radius is every client it manages.
• Do not take the absence of a vendor confirmation as all clear. In its November 11 post N-able said it was seeing scanning tied to the public code and no indications of compromise within its hosted servers, and that judging any single customer environment takes an assessment of that environment. On November 13 it went further: its investigation had turned up more indicators of compromise, and it was working with the specific customers concerned. It has also restricted features and integrations itself, Legacy API and the Intune integration among them. Huntress has seen no exploitation among its own partners. Beazley Security Labs said on November 10 that no confirmed customer compromise had been reported. Against that, Huntback and Lupovis count 21 servers with miners on them. Both things can be true at once, and only one of them is about your estate.

Worth noting for context on how this got here: the original disclosure was 33 critical flaws dropped on GitHub on November 9, which pushed N-able to take hosted N-central offline, and Tenable is careful to call that count alleged. N-able says those vulnerabilities did not come through its reporting channels or bug bounty, and rejects the suggestion that it ignored responsible disclosure. N-central has had a hard year either way: a critical unauthenticated flaw in August, an incomplete patch for it disclosed soon after, and an actively exploited pre-auth RCE rated 10.0 in September.