Attackers Put Miners on 21 N-central Servers Within Nine Hours of a Public Exploit, 19 of Them on the Hotfix 2 Build, and Apache Does Not Expect to Release a Fixed Axis 1 for the Flaw That Starts the Chain

Attackers started installing cryptocurrency miners on N-able N-central servers within hours of a public exploit for the product, and most of the servers they reached were already on the vendor’s latest hotfix. On Thursday, November 12, a researcher (BleepingComputer, SecurityWeek and The Hacker News name him as Sean Bales) published a root-level exploit chain called 4EverAble2Shell for N-central, the remote monitoring and management (RMM) platform that managed service providers use to control their customers’ computers. Huntback, a deception-based security firm, counted 21 miner rigs named after N-central servers at 12:50 UTC, and 19 of them reported build 2026.4.1.26, which is Hotfix 2, the release N-able shipped on November 10 for the earlier Able2Shell flaws.

N-able’s incident page, as we rendered it at 10:09 UTC on Friday, November 13, still says in its main text, “Importantly, we have seen no signs of compromise.” The newest entry in the same page’s timeline, stamped 03:50 UTC on November 13, says the company has “identified additional Indicators of Compromise (IOCs)” and is working with those customers. The page does not reconcile the two.

Two more facts come from primary records rather than from the coverage. The first step of the chain is CVE-2026-90436, a flaw in Apache Axis 1.x that Apache published on November 6, marked “UNSUPPORTED WHEN ASSIGNED” and said it does not expect to fix in a release; none of the seven CVE titles N-able lists for Hotfix 2 mentions Axis. And MoneroOcean’s public statistics for the miner wallet still listed 21 rig names starting nc_ at 10:29 UTC on November 13, the same count Huntback reported, with 5 of them still submitting shares. This is a snapshot taken between 10:00 and 10:45 UTC on November 13. N-able calls the situation fast-moving, so check its page for anything newer. It follows our November 10 report on the first wave of Able2Shell disclosures.

The timeline, in UTC

Every time below is UTC. The last column says where each entry comes from, and entries marked our check are ours.

By my arithmetic from those stamps, the first full-chain request arrived about 5 hours 18 minutes after the repository commit, all 21 rigs were mining under 9 hours after it, and the first probe came 41 minutes after the commit that covered the Legacy API requirement. The CVE had been public for five and a half days when the exploit appeared and for four days when Hotfix 2 shipped. Lupovis, which runs its own decoys, told SecurityWeek the same thing from its side: “Every one is a real server that ran the chain to root.”

What the exploit chain needs

Three conditions have to line up, and the public record is uneven on each.

Step one: an Apache Axis 1 flaw that Apache does not plan to fix in a release

Axis 1 is an old Java SOAP engine. Previdian describes it as the “bundled Apache Axis component” in N-central, and Huntback says every request in the attacks went to /dms/services/ServerUI, the Axis SOAP endpoint. Apache’s CVE record says an inbound SOAP fault that names an exception class makes Axis load that class and, if a string element is present, instantiate it before checking the type. With “a suitable class on the application’s classpath this leads to remote code execution”. The fault is parsed “before any per-service handler chain runs, so authentication handlers configured on a service do not protect against it”.

The record covers “all Apache Axis 1.x versions through 1.4”, carries the marker “UNSUPPORTED WHEN ASSIGNED”, and ends with the project’s position: “As Axis 1 has been EOL we recommend you migrate to a different SOAP engine, such as Apache Axis 2/Java.” The alternative it offers is a build of Axis with a source patch applied, and it adds: “The Apache Axis project does not expect to create an Axis 1.x release fixing this problem.” The Hacker News describes November 6 as the date patches were released, while the record points to a source commit and not to a release. The finder is credited as José Apari-Pantigozo of OKIOK. The one score NVD lists, CVSS 3.1 9.8, comes from CISA’s entry in the CVE record (its ADP container), Apache’s own severity is the word “critical”, and NVD still showed the record as “Awaiting Analysis” on November 13.

Previdian’s chief executive told The Hacker News that this is the first documented exploitation attempt aimed at CVE-2026-90436. Any other product that embeds Axis 1.x and exposes a SOAP endpoint has the same first step, and whether it leads to code execution depends on the classes on that application’s classpath. We did not test any other product.

Step two: a root escalation with no CVE yet

After code execution as the nable service account, the chain uses a local privilege escalation in one of N-central’s own privileged helpers to reach root, according to Previdian, which tracks it as VULN-2026-0009. Its page says “No CVE Assigned Yet” and that “The complete affected-version range and an N-central fixed build for this chain have not been verified.” Hotfix 2’s list includes two other local privilege escalations (a writable syslog-ng configuration and insecure IPC channels). The chain ran against Hotfix 2 builds, so whatever it relies on was not fixed there.

The Legacy API condition

The researcher’s repository got a commit titled “Legacy API Update” at 07:48 UTC, Tenable reports that the researcher later added that the chain requires the Legacy API to be enabled, and watchTowr says the same. N-able’s first notice called that a non-default configuration. N-able’s how-to for turning the setting off puts it under Administration, then Mail and Network Settings, then Network Security, in an option called LEGACY APIS that is set so that “Legacy APIs are disabled / blocked”. The article says it covers “N-central servers 2025.4+”.

Nobody has said whether the 21 servers had it on. Tenable writes that Huntback “does not say whether the Legacy API was enabled on those servers”, and one of the 21 runs build 2025.3.1.9, older than the 2025.4 that N-able’s how-to covers. In our reading, if the requirement is right, all 21 servers had that option on, which would make “non-default” a poor guide to exposure. If it is wrong, the mitigation N-able is pushing does not cover the chain. Nothing published so far settles which.

A second set: Agent2Shell

The researcher’s November 12 release also included Agent2Shell, which The Hacker News describes as more than 10 zero-day flaws that run commands on managed Windows agents as NT AUTHORITY\SYSTEM, assuming the attacker knows the target appliance ID. No source we read reports exploitation of Agent2Shell, and Tenable says Huntress has not confirmed whether those chains also depend on the Legacy API. N-able’s advice for the agent side is unchanged: keep upgrading Agents and Probes under the Hotfix 2 guidance.

What N-able has said

The incident page at 10:09 UTC on November 13

N-able’s status dashboard is a JavaScript page, so we rendered it in headless Edge. Incident 202613, titled “November 12 Update: Critical N-central Security Update”, is listed as a major outage with the status “Identified”. Its body says N-able is “restricting certain N-central features and integrations”, that “Legacy API is turned off by default in the product”, that the Intune integration has been switched off as a precaution, and that on-premises customers should “Ensure Legacy API access is disabled in your environment.” It closes by saying the teams are “developing additional remediation” and that this “remains a fast-moving situation”.

Three statements, three scopes

The statements about compromise sit in three places, and each has a different scope.

The same blog post adds that “Confirming whether any individual customer environment has been compromised requires an assessment of that specific environment.” The Hacker News and Tenable quote an earlier November 12 notice that said the issue “depends on a non-default configuration in which the Legacy API is turned on and exposed to the public internet”, and The Hacker News adds that N-able said hosted environments are not affected by this issue. The page as rendered does not contain the words “non-default” or “not recommended”. The dashboard shows one body text per event and we have no archived copy of the earlier body, so we cannot say when that wording was replaced; Tenable describes the quoted text as N-able’s first notice and the restricting-features text as a later November 12 update. The same pattern, a vendor page that changed within the day while an outlet kept the first text, came up in our Xen Orchestra report.

BleepingComputer’s article carries the contrast directly: N-able said it had seen no signs of compromise using the new flaws, “although security researchers have since reported successful exploitation of the vulnerability against production N-central servers.” Huntback says most of the 21 serve a login page with the managed service provider’s own branding, “behind certificates issued to that provider months ago”, which points to customer-run on-premises servers rather than N-able’s hosted service. That is our inference, because Huntback does not say which are which.

What Hotfix 2 does and does not cover

Hotfix 2 is a real fix for what it covers. N-able lists seven CVEs for it: XXE, OGNL injection, two local privilege escalations, stored XSS, SSRF and an upload path-traversal RCE credited to Nate Fair of Sprocket Security. Huntback’s point is that it was not enough against this chain: “Applying Hotfix 2 did not protect them.” N-able’s own pages say a follow-up hotfix is planned, and Tenable’s FAQ, updated on November 12, says N-able had not yet released a fix for the November 12 claims.

What the miner pool shows today

Huntback’s installer names every rig after the victim server’s address, and the wallet it published appears on MoneroOcean’s public statistics, which list each rig and the time of its last share. We read that list at 10:29 UTC on November 13 with the script below. It prints counts only. The rig names contain the victims’ addresses, so we did not record or publish them, and the script takes the wallet from Huntback’s indicator table as its first argument. We did not determine how the pool endpoint Huntback lists relates to MoneroOcean, so the shared wallet is the only link between the two.

"""pool_check.py WALLET: count the rigs one Monero wallet lists on MoneroOcean's public stats API.

Take the wallet from the indicator table in huntback's write-up. This operator's installer
names every rig nc_<victim address>, so the names on the wallet are a list of infected
servers. The script prints counts only and never prints a name.
Python 3.9 or later, standard library only. It sends one GET to the pool's public API.
"""
import json
import statistics
import sys
import time
import urllib.request
from datetime import datetime, timezone

wallet = sys.argv[1]
url = f"https://api.moneroocean.stream/miner/{wallet}/stats/allWorkers"
request = urllib.request.Request(url, headers={"User-Agent": "Mozilla/5.0"})
with urllib.request.urlopen(request, timeout=40) as response:
    data = json.load(response)

now = time.time()
rigs = {name: stats for name, stats in data.items() if name != "global"}
nc = {name: stats for name, stats in rigs.items() if name.startswith("nc_")}
minutes = sorted((now - stats["lts"]) / 60 for stats in nc.values())

print("checked at", datetime.now(timezone.utc).strftime("%Y-%m-%d %H:%M UTC"))
print("rig names on the wallet:", len(rigs))
print("names starting nc_:", len(nc))
print("  last share within 10 minutes:", sum(m <= 10 for m in minutes))
print("  last share 10 minutes to 6 hours ago:", sum(10 < m <= 360 for m in minutes))
print("  last share more than 6 hours ago:", sum(m > 360 for m in minutes))
print("  minutes since last share, min / median / max:",
      round(minutes[0], 1), "/", round(statistics.median(minutes), 1), "/", round(minutes[-1], 1))
print("  pool-reported hashrate of the nc_ rigs (H/s):", round(sum(stats.get("hash") or 0 for stats in nc.values())))

Run as python pool_check.py WALLET, it printed this at 10:29 UTC (the numbers move, so a later run will differ):

checked at 2026-11-13 10:29 UTC
rig names on the wallet: 638
names starting nc_: 21
  last share within 10 minutes: 5
  last share 10 minutes to 6 hours ago: 5
  last share more than 6 hours ago: 11
  minutes since last share, min / median / max: 0.7 / 363.7 / 1075.7
  pool-reported hashrate of the nc_ rigs (H/s): 1786

Our reading: no new nc_ names appeared between Huntback’s count and ours, 21 hours 39 minutes later, and most of the 21 have gone quiet, with 11 last sharing more than six hours earlier (the longest gap is 17.9 hours). The pool cannot say why a rig stopped. The miner may have been removed, the server may have been switched off, or the operator may have relabeled it. Five of them were still submitted shares at 10:29 UTC, so at least that many servers were running the miner 21 hours 39 minutes after Huntback counted them. The count is a floor in another sense too: the exploit is public, so another operator can use it with a different wallet or payload, and Huntback says the miner is the only payload it has seen. Huntback reads the same wallet’s other rig names, for Jpom, FreePBX, MLflow, Apache Flink, PaperCut and other products, as an operator that picks up new exploits within hours of their publication.

What to do now

These steps come from N-able’s pages and Huntback’s write-up unless marked as ours.

1. Check the Legacy API setting. On an on-premises server, log in as Product Admin, open Administration, then Mail and Network Settings, then Network Security, and make sure LEGACY APIS is set to disabled or blocked. N-able’s how-to is written for 2025.4 and later and says nothing about older builds.
2. Keep servers that are not upgraded off the internet, and upgrade. N-able’s November 11 post says on-premises customers should upgrade to Hotfix 2 “and keep their servers inaccessible to the internet until the upgrade has been successfully completed”, and that Agents and Probes must be upgraded too. Hotfix 2 does not cover 4EverAble2Shell, so it is necessary and not sufficient.
3. Look for the miner. Huntback lists files under /tmp/.xvd or /var/tmp/.xvd, an xvd.service unit, an /etc/cron.d/xvd file or a cron line ending # xvkeep, leftover serverchild-* files in /var/opt/n-central/tmp, and a symlink at /var/opt/n-central/flag/flag_default.json. It also lists processes with --rig-id nc_ or --donate-level 1 on the command line, and outbound connections to 157.20.241[.]16 (ports 8080 and 19202 to 19418), 139.99.69[.]109:10128 or 79.76.51[.]56:39100, defanged here. For logs it suggests looking for POST requests to /dms/services/ServerUI whose body carries a SOAP fault with an exceptionName element; ordinary access logs usually do not record request bodies, so in our note the path alone is a weak signal. The script below covers the file and cron entries.
4. Treat a hit as a full compromise. Huntback’s words are “Treat a hit as a full compromise, not a cleanup job.” Our addition: assume that the credentials and API keys the server holds are exposed, and plan to rotate them with your incident responder and N-able support.
5. Watch N-able’s incident page for the follow-up hotfix and for any change to the guidance.

A read-only host check we tested

The script changes nothing, takes an optional folder as a root so that it can be tested on a copy, and exits with status 1 if it finds an indicator. It does not look at processes or network connections. We ran it against an empty tree and against a tree with planted files, including a real symlink. We have no N-central server here, so it has not been run on one.

#!/usr/bin/env bash
# nc_hostcheck.sh [ROOT]
# Read-only check of a Linux host for the file and persistence artefacts that huntback lists
# for the 4EverAble2Shell miner chain. ROOT defaults to the real filesystem; pass a folder to
# test against a copy. It changes nothing. Exit status 0 means no indicator was found.
ROOT="${1:-}"
found=0
hit() { echo "FOUND: $1"; found=$((found + 1)); }

for p in /tmp/.xvd /var/tmp/.xvd /etc/systemd/system/xvd.service /etc/cron.d/xvd; do
  if [ -e "$ROOT$p" ] || [ -L "$ROOT$p" ]; then hit "$p"; fi
done

# huntback lists a symlink here, so a plain file with this name is not reported
if [ -L "$ROOT/var/opt/n-central/flag/flag_default.json" ]; then
  hit "/var/opt/n-central/flag/flag_default.json (symlink)"
fi

for f in "$ROOT"/var/opt/n-central/tmp/serverchild-*; do
  if [ -e "$f" ]; then hit "${f#"$ROOT"}"; fi
done

if grep -rIl -- "# xvkeep" "$ROOT/var/spool/cron" "$ROOT/etc/cron.d" 2>/dev/null | grep -q .; then
  hit "a cron entry tagged # xvkeep"
fi

echo "indicators found: $found"
[ "$found" -eq 0 ]

On the empty tree:

indicators found: 0
exit 0

On the planted tree:

FOUND: /tmp/.xvd
FOUND: /etc/cron.d/xvd
FOUND: /var/opt/n-central/flag/flag_default.json (symlink)
FOUND: /var/opt/n-central/tmp/serverchild-ab12.bak
FOUND: a cron entry tagged # xvkeep
indicators found: 5
exit 1

What we could not establish

• Whether any of the 21 servers had the Legacy API turned on, and whether the chain works with it off. N-able, watchTowr and the researcher say it needs the option on; nobody has published a test of that.
• What the default was on the server running build 2025.3.1.9, which is older than the builds N-able’s how-to covers.
• Whether N-able will assign a CVE to the escalation step. Previdian shows none.
• Whether Agent2Shell has been used against any server or agent.
• Who runs the miners. Huntback ties the 21 rigs to one operator by wallet and names no one.
• Whether CISA will list any of these flaws. The newest feed we could read, catalog 2026.11.10 released at 19:03 UTC on November 10, lists none of them, and its five N-able entries are all older (August 2025, and August 3 to September 8, 2026).
• How many servers were hit in total. Names appear only for hosts that ran this installer under this label, so 21 is a floor.

The checks we ran

• We rendered N-able’s dashboard and the incident 202613 page in headless Edge at 10:09 UTC on November 13 and again at 10:24 UTC, and read N-able’s November 11 blog post, the Hotfix 2 release notes and the Legacy API how-to.
• We read Huntback’s and Previdian’s pages, Tenable’s FAQ, The Hacker News, BleepingComputer and SecurityWeek in full.
• We read Apache’s oss-security post, the CVE.org and NVD records, and the date of the fix commit through GitHub’s API.
• We listed the commit titles and times for the researcher’s exploit folder through GitHub’s API. We did not open, download, run or link any exploit file.
• We read watchTowr’s post on X through the public mirror api.fxtwitter.com.
• We read CISA’s Known Exploited Vulnerabilities JSON feed.
• We ran the pool script above and tested the host script on made-up folders.
• We sent no request to any N-central server or to any address in the indicator list. The pool lookup is a read of a public statistics API.

Sources

• Huntback, 4EverAble2Shell is already mining Monero on live N-central servers
• Previdian, VULN-2026-0009
• N-able status dashboard, incident 202613, N-able blog, Hotfix 2 release notes and Legacy API how-to
• Tenable, Able2Shell FAQ
• The Hacker News, BleepingComputer and SecurityWeek
• Apache on oss-security, NVD record for CVE-2026-90436 and the Axis 1 fix commit
• watchTowr on X
• CISA Known Exploited Vulnerabilities feed