Attackers mine Monero on N-central Hotfix 2 servers

Nineteen of the 21 N-central servers found running an attacker’s Monero miner were on version 2026.4.1.26, the Hotfix 2 build N-able shipped on November 10 to close an earlier round of zero-days. The fix didn’t cover the flaw that got them.

On November 12, security researcher Sean Bales published proof-of-concept exploits for two N-central vulnerabilities he calls 4EverAble2Shell and Agent2Shell, both tested against that same Hotfix 2 release. Within hours, attackers were running the first one against production servers.

4EverAble2Shell gives an unauthenticated attacker command execution as root on an N-central server, provided the platform’s Legacy API is enabled. The chain starts with an Apache Axis vulnerability, CVE-2026-90436, which runs commands as the nable service account, then uses a separate N-central privilege escalation weakness to reach root. Previdian, which is tracking the escalation flaw as VULN-2026-0009, describes the mechanism: the attack abuses N-central’s privileged setLDFileOwner helper together with a symbolic link to make a normally root-owned script writable, rewrites the script, and invokes the serverControl function to execute it as root. It then tries to restore the modified files afterward. Agent2Shell, the second exploit, targets the agent and is claimed to run commands with SYSTEM privileges on Windows devices.

N-central is RMM software, used by MSPs and IT teams to monitor, manage, and secure customer devices and networks remotely, so a root shell on the server is a foothold on infrastructure that reaches into the customer environments it manages.

The timing is the part worth sitting with. Previdian first saw probes against its N-central honeypot around 08:30 UTC on November 12, using the same Java class named in Bales’ public exploit. Huntback saw the same attacker IP hitting its honeypots at the same time, with the first full exploit-chain attempts at 09:16 UTC. By 12:50 UTC, Huntback counted 21 live miners, each having submitted mining shares within the previous five minutes.

Previdian saw the payload pull an additional shell script from 157.20.241[.]16. Huntback saw the exploit chain install XMRig configured to use roughly half the available CPU cores, a common move to keep load under the threshold where someone notices. Huntback also enumerated the wider victim set through the mining pool itself: infected hosts registered worker names of the form nc_ followed by the server’s IP, which made the whole campaign readable from the pool statistics. The 21 confirmed servers were hosted across the US, Canada, South Africa, the UK, Germany, France, and Sweden. All 21 were hosted installations, and 19 were on the latest Hotfix 2 build.

N-able had already taken its hosted N-central environments offline earlier in the week and told on-premises customers to shut down their servers, after Bales dumped more than 30 alleged zero-days. In a November 12 advisory the company said it was restricting certain N-central features and integrations while it builds further fixes, disabled the Intune integration as a precaution, and urged on-prem customers to confirm Legacy API access is disabled, which is already the default. N-able said it had seen no signs of compromise via the new flaws; the honeypot data from Previdian and Huntback came in after that.

Bales has been openly critical of how N-able handled the disclosures. “It’s much much easier for me to just release the research I have and the vendor can decide what they want to do with it, what they do and don’t want to fix, etc. :)” he told BleepingComputer. He says N-able still hasn’t patched two unrelated RCE bugs in a different product that he reported in July.

If you run N-central on-prem, start by confirming Legacy API is disabled; 4EverAble2Shell needs it, and it should be off by default. Look for suspicious requests to /dms/services/ServerUI, particularly anything referencing jline.internal.TerminalLineSettings, the class from the exploit. On the host, Huntback flags an unexpected xvd.service systemd unit, cryptominer processes, and files under /tmp/.xvd or /var/tmp/.xvd as indicators.

If you find any of those, treat the box as a full compromise rather than just cleaning off the miner. The exploit hands over full root on the server, and cryptojacking is only what this crew chose to do with it; compromised N-central infrastructure gives an attacker a route into the customer environments it manages.