N-central Exploit Chains Bypass Hotfix 2: Disable Legacy API and Check Windows Agents

If you run N-central on-premises, start with one setting: Legacy API. If it's on and reachable from the internet, treat this as an incident until you've shown it isn't one.

What was disclosed​

BleepingComputer reports that Bales published proof-of-concept exploits for both the 4EverAble2Shell and Agent2Shell vulnerabilities, saying they were tested against N-central Appliance 2026.4.1.26 HF2, the security update N-able released on November 10. That hotfix was N-able's answer to Bales' earlier "Able2Shell" release. The Hacker News reports that the new PoCs successfully work against N-central 2026.4 Hotfix 2 (build 2026.4.1.26).

The two chains go after different parts of the platform:

• 4EverAble2Shell (server): The 4EverAble2Shell exploit allows unauthenticated attackers to execute commands as root on vulnerable N-central servers. BleepingComputer says it combines an Apache Axis flaw, CVE-2026-90436, with a separate N-central privilege-escalation weakness.
• Agent2Shell (Windows endpoints): According to The Hacker News, it leverages more than 10 zero-day vulnerabilities to run commands on managed Windows agents as NT AUTHORITY\SYSTEM, assuming the attacker knows the target appliance ID.

The disclosure date shifts with the time zone. Huntress says the researcher published the code late on November 11, US time. BleepingComputer dates it November 12.

The Legacy API condition​

Bales' own GitHub repository makes the most important point. The folder describes an anonymous-to-root exploit chain verified against N-able N-central Appliance 2026.4.1.26 HF2. It then adds a caveat: "Legacy API needs to be enabled; Forgot this was turned on during earlier testing for other vulnerabilities."

The repository also shows how the chain works. The public Axis endpoint builds a JLine terminal-settings class from attacker-supplied SOAP fault data before it checks the type. Then JLine injects that value into sh -c as nable; the inline stage then uses the self-restoring setLDFileOwner and serverControl helper chain to execute as root.

N-able's advisory, as quoted by The Hacker News, matches this. N-able says the server issue requires a non-default setup where Legacy API is turned on and exposed to the internet, and that Legacy API is off by default and not recommended. N-able also told The Hacker News that hosted environments aren't affected by the server issue. The affected services are N-central on-premises in the Americas, APAC and Europe.

Summary: A default, fully patched HF2 install with Legacy API off is not exposed to 4EverAble2Shell, based on the vendor and the researcher's own correction. Agent2Shell is a separate question, covered below.

Exploitation: probing confirmed, compromise disputed​

Everyone agrees attackers moved quickly. The Hacker News reports that Previdian founder Ryan Dewhurst said targeted N-central probing has been observed against 4EverAble2Shell within hours following the release of the PoC. watchTowr also posted that it was seeing probes for 4EverAble2Shell targeting N-Central builds with the Legacy API enabled.

Previdian gave BleepingComputer a timeline. Its N-central honeypot saw suspicious requests at about 08:30 UTC on November 12, using the same Java class as the public exploit, and later saw full exploit-chain attempts. The payload tried to download a shell script from 157.20.241[.]16 and sent diagnostic output back to the same address. On its public tracker, Previdian lists the privilege-escalation flaw as VULN-2026-0009 with exploit status Exploitation Attempts Observed in the Wild, and says its sensors saw 2 exploitation attempts, 1 unique attacker IP, and 1 country.

The reports split on whether real systems have been compromised:

Huntback's method is concrete. The attacker's mining pool labeled infected machines with identifiers starting nc_ followed by the server's IP address. Huntback says it found 21 such miners that had submitted mining shares within the previous five minutes. It then checked each IP and found N-central running on all of them. The servers were in the US, Canada, South Africa, the UK, Germany, France and Sweden, and the miner was set to use about half the available CPU cores.

These accounts don't necessarily contradict each other. N-able's view covers its own hosted estate, and Huntress's covers its partners. Neither can see every self-hosted server on the internet. Still, the 21-server figure comes from one firm's analysis and hasn't been independently corroborated in the reporting available so far.

Summary: Attempted exploitation is confirmed by several firms. Successful compromise rests on Huntback's evidence alone, which is specific but uncorroborated.

N-able's response​

BleepingComputer reports that N-able's November 12 advisory says the company is restricting some features while it builds fixes: "We are restricting certain N-central features and integrations," N-able said. It has disabled the Intune integration as a precaution. It also tells on-premises customers to make sure Legacy API is disabled and to keep upgrading Agents and Probes under the earlier Hotfix 2 guidance. Hosted environments already have these protections.

Huntress says N-able has published a knowledge base article on disabling Legacy API on on-premises servers. Huntress also notes that N-able is not telling customers to take N-central offline this time. That's a change from November 9, when N-able took hosted N-central offline and told on-premises customers to shut their servers down.

The disclosure dispute​

The way this has unfolded is a story of its own. Bales has published the Able2Shell, 4EverAble2Shell and Agent2Shell exploits without notifying N-able first. He says N-able ignored his earlier reports, and that N-able has not patched two unrelated RCE vulnerabilities in a different N-able product that he previously disclosed to the company in July. BankInfoSecurity reports he described 4EverAble2Shell on LinkedIn as one that "will one-shot a N-central server, and provides root, anonymously,".

Both sides have a case. A vendor that sits on reported bugs invites this kind of response. On the other hand, attackers were probing for 4EverAble2Shell within hours of the release, which shows the risk that full public disclosure creates for MSPs who had just finished patching. Bales' own correction about Legacy API is another reason for caution: the first headlines said every patched server was vulnerable, and that turned out not to be true.

The bigger concern is the type of product. An RMM server has administrative reach into every customer endpoint it manages. Cryptomining is a loud and fairly low-damage first payload. An attacker with root on N-central could do much worse to downstream Windows environments, and that's especially relevant because Agent2Shell targets those endpoints directly.

What N-central administrators should do now​

1. Check Legacy API (on-premises).

• Confirm it's disabled. If it's on, turn it off using N-able's knowledge base article.
• If you really need it, Huntress advises not exposing it to the internet and restricting access to the server until N-able ships a fix.
• If you took the server offline earlier, confirm Legacy API is off before bringing it back.

2. Keep Agents and Probes up to date under the HF2 guidance, as N-able's advisory says.

3. Look for server-side indicators. The researchers quoted by BleepingComputer recommend checking for:

• Requests to /dms/services/ServerUI, especially any that reference jline.internal.TerminalLineSettings. Huntress's static analysis of the PoC notes it gets an HTTP 500 response.
• Unexpected xvd.service systemd units, cryptocurrency-mining processes, and files under /tmp/.xvd or /var/tmp/.xvd. Huntback recommends these checks.
• Huntress also lists /var/opt/n-central/flag/flag_default.json existing as a symlink to /opt/nable/var/ncsai/scripts/ServerChild.sh, and serverchild-*.bak/.sh/.out files in /var/opt/n-central/tmp/.
• Traffic to or from 157.20.241[.]16.

4. Check Windows endpoints for Agent2Shell activity. Huntress built these from static code analysis and says none have been seen in the wild:

• powershell.exe -NoProfile -NonInteractive -EncodedCommand running as SYSTEM, started by the N-able Agent. PowerShell under the agent is normal, so look at the command line.
• wsp.exe or service.cfg written to the Windows Software Probe bin folder, plus unexpected stop/start cycles of the Windows Software Probe Service run from a .cmd file in %TEMP%.

5. If you find real indicators, rebuild. 4EverAble2Shell gives root, so a confirmed hit means the whole server is compromised, not just one process. A single suspicious request is not proof of compromise on its own. A matching request plus an xvd service and a busy miner is.

One question remains open. Huntress says it has not yet confirmed whether the Agent2Shell chains affecting Windows Agents and Probes also depend on Legacy API. Until N-able answers that, turning off Legacy API is necessary but may not be enough on its own, so keep watching N-able's advisory for Agent2Shell fixes.