MAG212 CYBER ORIGINAL ARTICLE

N-able N-central Zero-Day ‘4EverAble2Shell’ Exploited Within Hours on the Newest Build, With No Fix Yet

November 13, 2026 · El Mostafa Ouchen

For managed service providers, the past week has been a stress test of the platform many of them use to run their customers’ IT. After a researcher published more than 30 N-central zero-days on 8 November, N-able took its hosted service offline and shipped an emergency hotfix. On 12 November the same researcher released a new exploit, 4EverAble2Shell, that works against that hotfix. Within about five hours attackers were using it, and by early afternoon UTC one security firm had counted 21 compromised servers mining cryptocurrency. N-able has restricted features but has not yet released a fix.

Exploit	4EverAble2Shell: unauthenticated root, needs Legacy API
Also released	Agent2Shell: claimed SYSTEM on managed Windows
Seen	21 servers mining Monero, 19 on 2026.4 HF2
Vendor	Features restricted, Intune integration off; no fix yet

What happened

[Reported] Researcher Sean Bales published more than 30 N-central zero-days with exploits on 8 November. N-able took hosted N-central offline on 9 November and shipped 2026.4 Hotfix 2 (build 2026.4.1.26) on 10 November, fixing seven CVEs. On 12 November Bales released two more exploits, 4EverAble2Shell and Agent2Shell, tested against that same Hotfix 2 build. (SecurityWeek) (BleepingComputer)

[Reported] Previdian saw probing at about 08:30 UTC on 12 November. Huntback saw the full chain from 09:16 UTC, and by 12:50 UTC counted 21 compromised N-central servers running an XMRig miner. Huntback describes all 21 as hosted N-central servers; nineteen were on Hotfix 2, spread across the US, Canada, South Africa, the UK, Germany, France and Sweden. SecurityWeek, citing Lupovis and Huntback, puts the first successful compromises about five hours after the exploit was published. (BleepingComputer) (SecurityWeek)

Figure 2 · N-central: 8 to 13 November. From the first zero-day dump to miners on the newest build. Times are UTC on 12 November. Diagram: MAG212 CYBER

Who is affected and how it works

[Reported] N-central servers with the Legacy API enabled; Legacy API is off by default. [Unknown] How the compromised servers came to have it enabled. The chain uses an Apache Axis flaw, CVE-2026-90436, to run commands as the nable service account. It then abuses the privileged setLDFileOwner helper and a symbolic link to make a root-owned script writable, edits that script, and runs it as root through serverControl. The payload fetched a script from 157.20.241[.]16 and installed a miner set to use about half the CPU cores. (BleepingComputer) [MAG212 analysis] Cryptomining is the least of it: root on an RMM server means control of every endpoint it manages. Agent2Shell, if it works as claimed, targets those endpoints directly.

[Reported] N-able’s 12 November advisory says it is “restricting certain N-central features and integrations”. It has disabled the Intune integration, applied protections to hosted environments, and urges on-premises customers to confirm Legacy API access is disabled and to keep upgrading agents and probes. At that point it said it had seen no compromise using the new flaws; researchers have since reported compromises. (BleepingComputer) (N-able status)

N-central server check

OS: N-central appliance (Linux) · Shell: bash · Privileges: root / support shell · READ-ONLY

# Huntback indicators: miner service, staging folders, mining process
systemctl list-units --all --no-pager | grep -i 'xvd'
ls -la /tmp/.xvd /var/tmp/.xvd 2>/dev/null
ps aux | grep -Ei 'xmrig|xvd' | grep -v grep
# Exploit requests in your web access log (path varies by build)
grep -E '/dms/services/ServerUI' <N-CENTRAL-WEB-ACCESS-LOG> | grep -i 'TerminalLineSettings'
# Connections to the reported payload host
ss -tnp | grep '157.20.241.16'

Replace <N-CENTRAL-WEB-ACCESS-LOG> with your appliance’s web log path. Expected clean result: no output from any command. Any hit means full root compromise: take the server off the network and rebuild. Commands not tested by MAG212 CYBER. Indicators from Huntback and Previdian via BleepingComputer.

Contain and remediate (in order)

Follow N-able’s offline guidance. [Reported] After the 8 November dump, N-able advised on-premises customers to keep servers offline until it confirms they can safely return, and Huntress repeats that advice. (Huntress) If yours is back online, confirm Legacy API is disabled and that the server isn’t reachable from the internet.
Run the checks above. On a hit, isolate the server, preserve disk and logs, rebuild from a known-good install, and rotate every credential and integration secret the server held.
[MAG212 analysis] Check managed endpoints for unexpected scripts or agent tasks pushed since 8 November, and for new remote-access tools.
Watch N-able’s status page for the fix, then apply it immediately, along with the Hotfix 2 agent and probe upgrades.

Verify recovery: Legacy API is off, there’s no xvd service or miner, CPU use is normal, and the server runs the fixed build once N-able releases it. Prevention [MAG212 analysis]: this is the second RMM platform in two days. Treat RMM servers as tier zero: no internet exposure without a VPN or allow-list, MFA everywhere, and logs shipped somewhere the server can’t reach.

Why MSPs should treat this as more than cryptomining

[MAG212 analysis] A miner is the noisiest, least ambitious thing an attacker can do with root on an RMM server. The same access lets them push scripts, install software and open remote sessions on every endpoint the server manages, across every customer. The first wave chose mining; the next may not.

[Reported] The researcher also released Agent2Shell, which he says gives SYSTEM on managed Windows machines through the N-central agent. We have not seen independent confirmation that it works as described. If it does, the risk extends from the server to the fleet it manages.

[MAG212 analysis] This is the second remote-management platform in two days to be turned against MSP customers, after this week’s ScreenConnect SCKit campaign. The lesson is the same: RMM servers belong in the most protected tier of the network, never directly on the internet, and their logs should go somewhere the server itself can’t touch.

Why it matters

N-central sits at the centre of thousands of small businesses, schools and enterprise IT teams that outsource management to MSPs. A working root exploit with no patch, against the build N-able told customers to install, removes the usual answer of “update and move on”. Until N-able ships a fix, the only reliable protection is keeping servers offline or unreachable, with the Legacy API turned off.

The bottom line

Keep on-premises N-central servers offline until N-able confirms they can return, or at minimum ensure the Legacy API is disabled and the server is unreachable from the internet. Run the indicator checks, treat any hit as a full compromise and rebuild, then check managed endpoints for scripts or tools pushed since 8 November. Apply N-able’s fix the day it ships.

How we label evidence: [Confirmed] comes from a primary source such as a vendor or CISA; [Reported] from a secondary outlet; [Claimed] from an attacker or an unverified party; [MAG212 analysis] is our judgement; [Unknown] means not established at press time. Commands and indicators are copied from the cited sources and were not tested by MAG212 CYBER.

This story is part of MAG212 CYBER Daily, 13 November 2026, with the day’s other verified stories, the Defender’s Action Desk and a full source register. Get the daily briefing free: subscribe to MAG212 CYBER. By El Mostafa Ouchen.