N-central servers on Hotfix 2 mined through a new chain

Two analysts in a dim operations room before dawn, one pointing at a wall display of an incident timeline with three red markers

Two stories from this week moved overnight, and both raise questions MSP owners are asking this Friday, November 13, 2026. N-central servers that already run Hotfix 2 are now being compromised. The ScreenConnect extension behind Wednesday's rogue-client wave now has a CVE and a longer to-do list. CISA's exploited list has had no additions since November 10.

Is Hotfix 2 enough to keep my N-central server safe?

No. On November 12, researcher Sean Bales published two new exploit chains, which he tested against N-central 2026.4 Hotfix 2, build 2026.4.1.26. The November 12 briefing covered that release. Within hours, the server chain, called 4EverAble2Shell, was used in real attacks, as reported by BleepingComputer.

The chain starts with CVE-2026-90436, a 9.8 flaw in the Apache Axis component bundled with N-central. That gives commands as the nable service account. A separate N-central privilege escalation then turns it into root. Previdian, which tracks the chain as VULN-2026-0009, first saw attempts at 08:24 UTC on November 12.

Huntback counted 21 servers running a Monero miner by 12:50 UTC that day, according to the same BleepingComputer report. Per The Hacker News, 19 of them were on Hotfix 2. SecurityWeek reports Lupovis reached the same count of 21 from the attacker's wallet. The victims were in the US, Canada, South Africa, the UK, Germany, France and Sweden. So far the payload is a miner, but the attacker has root on a server that manages client endpoints.

Reports say the chain needs the Legacy API to be on. N-able ships it off by default. Keep Hotfix 2 installed, confirm the Legacy API is disabled today, and keep the server off the open internet. N-able has not given a date for the next fix.

How do I tell if my server was already hit?

Check your server for the indicators the researchers published, listed below. If any match, treat the server as fully compromised, not as a cleanup job. That means rebuilding, rotating every credential the server holds, and reviewing what it pushed to client endpoints since November 12. According to SecurityWeek, N-able said on November 13 that it had found more indicators and is working with affected customers.

Indicator	What it is
`157.20.241[.]16`	Attacker server, used for probing and payload download
`hxxp://157.20.241[.]16:8080/jup.sh`	Payload script
`mount -o remount,exec /tmp` followed by `curl -fsSL ... \	sh -s nc_<target>`	Command pattern on the server
Requests to `/dms/services/ServerUI` that reference `jline.internal.TerminalLineSettings`	Exploit attempt in web logs
An unexpected `xvd.service` systemd unit	Persistence
Files under `/tmp/.xvd` or `/var/tmp/.xvd`	Miner files
An XMRig process using about half the CPU cores	Miner

The IP, script and command pattern come from The Hacker News. The web request, service and paths come from BleepingComputer. Also look for new systemd units or cron entries you did not create.

What did N-able switch off, and what do I still owe it?

N-able says it is restricting some N-central features and integrations while it builds further fixes, according to BleepingComputer. It has turned off the Intune integration as a precaution. On hosted servers it applied the protections itself, so hosted customers need no server-side action. Expect some functions to stop working until the restrictions are lifted.

Your own job is unchanged from Hotfix 2. N-able's update says every customer, hosted or on-premises, must also upgrade Agents and Probes. Finish those upgrades and record which sites are still behind. The second chain, Agent2Shell, claims SYSTEM on managed Windows devices through the agent. N-able has not said whether current agents block it, so watch agents for commands nobody on your team sent.

Update: Does the ScreenConnect RMM+ problem have a fix yet?

It has a CVE, but no fixed version. ConnectWise assigned CVE-2026-127063 on November 12. The DataComm RMM+ extension for ScreenConnect ships with a static API secret by default. Where that default was never changed, outsiders can call the extension's API, including commands to managed agents. It is rated CVSS 4.0 9.3, and ScreenConnect's own server and client are not affected.

ConnectWise's advisory, updated at 18:45 UTC on November 12, now says attackers abused third-party extensions to deploy unauthorized remote-access software. It found no evidence that a ScreenConnect vulnerability was the way in. It has disabled the extensions in about 400 cloud environments. On-premises partners must disable RMM+ themselves and leave it off until ConnectWise issues further guidance.

The update also adds steps beyond the November 12 briefing. It ties the SCKit toolkit to CVE-2026-84869, a client file-transfer flaw fixed in ScreenConnect 26.6.5 on September 8. Updating a cloud console does not update technician clients, so check each technician workstation is on 26.6.5 or later. Turn off Transfer Files wherever it is not needed. Revoke ScreenConnect web sessions and identity-provider sessions, because password resets alone do not end them.

Sources

threat-briefingmanaged-it