An N-central RMM compromise can still land on a server that already has Hotfix 2 when the Legacy API is enabled. SecurityWeek reports attackers compromised N-central servers hours after a November 12 proof of concept, and Huntback counted 21 Monero-mining servers that day, 19 already on that hotfix. For MSPs and every customer behind those consoles, a version check is not the control, and a cryptominer is the low end of the risk.
Updated November 13, 2026
Key Takeaways
- Hotfix 2 did not stop 4EverAble2Shell when Legacy API stayed enabled.
- Huntback counted 21 mining servers; 19 already ran Hotfix 2.
- Root on an N-central console is a multi-tenant compromise, not cleanup.
- On-prem teams must confirm Legacy API is off; hosted got vendor protections.
Why did Hotfix 2 fail to stop the chain?
N-able’s status archive lists Hotfix 2, build 2026.4.1.26, updated November 10, as a critical security update. Ostorlab reports that build was issued for Able2Shell flaws disclosed on November 9, and that 4EverAble2Shell bypasses it when the Legacy API is on.
SecurityWeek reports that Sean Bales published the proof of concept on November 12, two days after those fixes. The chain pairs Apache Axis CVE-2026-90436, CVSS 9.8, with an N-central flaw that needs the Legacy API, then reaches root. N-able says those issues were not responsibly disclosed through its established channels.
SecurityWeek, citing Lupovis and Huntback, puts compromise at roughly five hours. Ostorlab times Huntback’s first check from 157.20.241[.]16 at 08:30 UTC, 4.5 hours after publication, and the miner install at 09:16 UTC.
Is the Legacy API the real control?
Yes. In its November 13 security update, N-able said: “As part of today’s investigation, we identified Indicators of Compromise (IOCs) relevant only to customers who have not disabled the Legacy API.” The setting is off by default.
- Hosted: N-able applied temporary protections. No server-side action is required. Legacy API is off by default, and Intune integration is off while additional protections are validated.
- On-premises: disable Legacy API if it was enabled, and keep the Hotfix 2 guidance, including Agent and Probe upgrades. N-able deactivated Intune integration as a precaution and will phone customers it could not change.
Confirm the setting. Hotfix 2 does not close this chain. Disabling the API removes the published path but does not repair a rooted server or fix older Able2Shell builds. Ostorlab’s exposure case is an on-premises console, reachable from an untrusted network, with Legacy API on, on build 2026.4.1.26 or earlier. N-able says hosted environments are not affected by the new server issue.
What does an N-central RMM compromise mean for tenants?
At 12:50 UTC on November 12, Ostorlab says the operator’s mining pool listed 21 rigs named for victim IPs, all submitting shares in the previous five minutes. Huntback recorded that listing. Ostorlab says every address served an N-central login page. Lupovis told SecurityWeek, “Our decoys never execute anything, so none of the listed rigs are ours. Every one is a real server that ran the chain to root.”
| Reported detail | Figure |
|---|---|
| Mining N-central servers | 21 |
| Already on Hotfix 2 | 19 |
| United States | 9 |
| South Africa | 4 |
| Canada | 4 |
| Also listed | UK, Germany, France, Sweden |
Huntback, as quoted by SecurityWeek:
The miner is the only payload we have seen, but the escalation hands the operator root on a host that manages your customers’ endpoints. Treat a hit as a full compromise, not a cleanup job. Applying Hotfix 2 is not enough on its own.
Root here is a multi-tenant blast radius, not a process to kill. SecurityWeek reports that Agent2Shell, roughly a dozen flaws published the same day, could allow commands on managed Windows agents with System privileges. Ostorlab says the researcher describes more than 10 flaws that do that when the attacker knows the appliance ID. The pattern matches how acquisition-era systems widen a logistics blast radius: one control plane, many tenants.
What should MSPs and their customers do now?
N-able says further remediation is still in development. Until it ships, the setting is the control:
- Confirm Legacy API is disabled. Do not infer that from build 2026.4.1.26.
- Apply Hotfix 2 on older servers. It still closes the first Able2Shell chains.
- Upgrade every Agent and Probe. Ostorlab reports N-able treats both as mandatory because the update changes how they communicate.
- Limit console access to a management VLAN, a VPN, or fixed administrator addresses.
- If the server was reachable from the internet with Legacy API enabled, preserve logs and a disk image, rebuild from a known-good image, and rotate every stored credential.
- Hunt N-able’s indicators: jup.sh, xvgz, and xmrig.tgz from 157.20.241[.]16, plus outbound to that host on ports 8080 and 19202-19418, 139.99.69[.]109:10128, and 79.76.51[.]56:39100.
As of November 13, Ostorlab reported that neither CVE-2026-90436 nor this chain was in CISA’s KEV catalog. Do not wait on that list. Treat the console as a ScreenConnect incident checklist would: trusted by every tenant behind it.
Frequently asked questions
Did Hotfix 2 stop 4EverAble2Shell?
No. The chain works against build 2026.4.1.26 when Legacy API is enabled, and 19 of 21 mining servers were already on that hotfix.
Which N-central servers need action?
On-premises servers reachable from an untrusted network with Legacy API enabled, including Hotfix 2. Hosted customers had protections applied and need no server-side action.
Why is a cryptominer the low end of the risk?
Huntback said the miner was the only payload seen, but root on a host that manages customer endpoints should be treated as a full compromise.
Was this in CISA’s KEV catalog on November 13?
No. Ostorlab reported that neither CVE-2026-90436 nor the N-central chain was listed that day.
