New Public Exploits Claim to Beat N-central's HF2 Fix. Turn Off the Legacy API Today, and Treat the Agent Chain to Windows SYSTEM as Unanswered

If you run N-able N-central on your own server, check today that the Legacy API is switched off, even if you already installed 2026.4 HF2. N-able's own incident notice, opened at 07:00 UTC on Thursday, November 12, says: "If Legacy API is enabled: Disable Legacy API now." It tells every other on-premises customer to "Confirm that Legacy API is disabled." HF2 is still required. It is no longer enough on its own if that setting is on.
The reason: the same researcher who published the first batch of N-central exploits on November 8 published two more sets early on November 12, and says both were reproduced on HF2, build 2026.4.1.26, the fix N-able released on November 10. One gives an anonymous attacker root on the N-central server. The other is a set of chains against the Windows Agents and Probes that N-central manages, ending in commands run as NT AUTHORITY\SYSTEM. N-able's notice addresses the first. In what we read, it says nothing yet about the second.
What N-able says
We read N-able's incident notice directly (event 202609 on its status dashboard). Quoted in full on the points that matter:
- "N-able is investigating a new public disclosure containing claims of additional vulnerabilities in N-central On-Premises 2026.4.1 HF2."
- "Based on our initial review, the server issue described depends on a non-default configuration in which the Legacy API is turned on and exposed to the public internet. Legacy API is turned off by default in the product and is not recommended."
- "N-able N-central Hosted Customers: Hosted environments are not affected by this issue."
- "Our Security and Engineering teams are assessing the claims, including which versions may be in scope."
The notice lists only the on-premises services as affected (Americas, APAC, Europe), status "Investigating". It links a support article, "How to disable Legacy API settings on On-Premises N-central servers", on N-able's customer portal. That page would not render for us, so we cannot quote its steps; use it from your own portal login.
One more N-able statement now reads differently. Its blog post of November 11, "Update on N-central 2026.4 HF2 and ongoing security response", said: "All identified vulnerabilities that could be exploited via an unauthenticated user have been addressed." The new server exploit is unauthenticated. Whether those two statements conflict depends on whether a non-default, internet-exposed Legacy API counts, and on what N-able had identified by then. N-able has not said.
What the researcher published
We read the two new README files in the researcher's public GitHub repository through the GitHub API. We did not download or run any exploit script. Both folders were added in a commit at 03:58 UTC on November 12.
- 4EverAble2Shell (server, root). The README says it is an "anonymous-to-root exploit chain verified against N-able N-central Appliance 2026.4.1.26 HF2". It abuses the bundled Apache Axis web-services component: a crafted SOAP fault makes Axis build a Java class from attacker data before checking its type, which runs a shell command as the nable service user, and two privileged helper functions then lift that to root. At 07:48 UTC, 48 minutes after N-able's notice went up, the researcher added one line: "Legacy API needs to be enabled; Forgot this was turned on during earlier testing for other vulnerabilities." So the researcher and N-able now agree on the precondition for the server chain.
- Agent2Shell (managed Windows machines, SYSTEM). The README describes chains "reproduced on N-able N-central Appliance 2026.4.1.26 HF2" that make an online Windows Agent run a command as NT AUTHORITY\SYSTEM "without a product credential or user interaction", plus a second chain that swaps a Probe's service executable to run a command. It also lists supporting weaknesses, including an appliance passcode that it says is the SHA-256 of the appliance ID, and several agent-protocol operations it says accept anonymous or cross-appliance requests. The chains need a target appliance ID. The README says anyone who has compromised one device with an agent on it holds those IDs, and that N-able's earlier fix removed the researcher's way to enumerate them without access. The README does not say Agent2Shell needs the Legacy API.
The Hacker News counts Agent2Shell as chaining more than ten zero-days. The README lists two RCE chains and thirteen proof-of-concept scripts in all; we have not checked which are distinct flaws.
The CVE underneath, and the catalog
The server chain rests on an Apache Axis 1.x flaw. CVE-2026-90436, published November 6, is titled "Apache Axis 1.x (EOL): unauthenticated remote class instantiation via SOAP fault exceptionName". Its record is marked "UNSUPPORTED WHEN ASSIGNED": Axis 1.x is end of life, all versions through 1.4 are affected, and the record notes that "authentication handlers configured on a service do not protect against it". The link between this CVE and the N-central exploit comes from The Hacker News and the description on Previdian's VULN-2026-0009 page, which names the "bundled Apache Axis component" but shows no CVE; the researcher's README names no CVE either.
CISA's Known Exploited Vulnerabilities catalog, which we downloaded directly (catalog version 2026.11.10), contains none of CVE-2026-90436, CVE-2026-125878 through CVE-2026-125883, or CVE-2026-91000. The N-central entries it does hold are the five we listed before: CVE-2026-18577, CVE-2026-18556 and CVE-2026-86218 from August and September 2026, and CVE-2025-8875 and CVE-2025-8876 from August 2025. No CVE has been assigned to 4EverAble2Shell or Agent2Shell in anything we read.
Is anyone using it
Three reports, from three different parties, none confirming a compromise:
- Previdian (its public VULN-2026-0009 page): exploitation attempts first recorded at 08:24 UTC on November 12, about 71 minutes after the 07:13 UTC public PoC entry on its timeline. The total: 4 attempts from 1 attacker IP in 1 country, seen by 1 sensor. That is one source address hitting one sensor, not a campaign.
- The Hacker News quotes Previdian's Ryan Dewhurst on "targeted N-central probing" and gives the source as 157.20.241[.]16. Previdian's own page keeps addresses behind a paid tier, so we could not confirm the address at source. Search your logs for it; we have not added it to our feed.
- watchTowr, per The Hacker News, is "seeing probes for 4EverAble2Shell targeting N-Centrals builds with the Legacy API enabled." We did not read the X post itself.
The Hacker News says there is "no evidence of successful exploitation as of writing", and N-able's notice does not claim any.
Exposure numbers, and what they do not tell you
BleepingComputer (Sergiu Gatlan, November 11) reports that Shadowserver's internet scan counted 1,338 exposed N-central servers on Monday, November 9, and "just over 148" afterwards. Those are Shadowserver's counts of N-central servers it could reach from the internet, not a count of servers with the Legacy API on, and not a count of vulnerable or compromised ones. We did not check Shadowserver's dashboard ourselves. The drop says many operators took N-able's advice to go offline. It does not say whether the ones coming back online after HF2 have the Legacy API off.
What to do
- Turn the Legacy API off, then confirm it. Follow N-able's support article from your portal. Then check from outside your network, not from the server itself, that the N-central web interface either does not answer or answers only from addresses you expect.
- Stay on HF2. It fixes the seven CVEs N-able assigned for the first batch, and the new exploits do not change that. Upgrade Agents and Probes as N-able's HF2 notes require. Do not roll back.
- Do not expose the server more than it has to be. For most MSPs, agents at client sites have to reach the server, so "off the internet" may not be possible. What you can do, in our view: allow administrative and API access only from your own administration network or VPN, and where your firewall allows it, limit inbound agent traffic to the public addresses of the client sites you manage.
- Assume Agent2Shell is live until N-able says otherwise. Its precondition is one compromised managed device. That makes every endpoint an N-central agent runs on part of the path to the others. Watch for processes started by the N-central agent services that you did not schedule, and for Probe service executables that change and then change back.
- Hunt for the server chain. In the N-central web server logs, look for unexpected requests to the Axis web-services paths under /dms/services/, especially ones returning HTTP 500, which is what the README's own output shows. Look for outbound connections from the server that it should not make, and for traffic from 157.20.241[.]16. If you find a hit with the Legacy API on, treat the server as compromised: rebuild it, and rotate every credential stored in or reachable from it.
- Watch N-able's incident page for the next hotfix. Get it only from N-able's own download portal.
What is not known
Which N-central versions the new exploits work on beyond HF2. Whether Agent2Shell works against hosted N-central: N-able's "not affected" covers "this issue", the server one. When a fix will ship, and whether CVEs will be assigned. Whether the source address in The Hacker News is the same one Previdian counted. How many internet-facing servers have the Legacy API enabled; nobody has published that.
Did our earlier posts get this wrong?
No. Our posts of November 9 and November 10 said, in their November 11 updates, to keep servers offline until HF2 was installed, and that "HF2 is not the last fix" because N-able had announced a follow-up. Neither said HF2 alone made a server safe. The advice has changed because of new data, so this is a new post, not a correction.
How we know, and how we checked
We read N-able's incident notice and its earlier HF2 notice through its status dashboard's JSON, N-able's November 11 blog post, the two new READMEs and the repository's commit history through the GitHub API, the CVE-2026-90436 record from the CVE Program, Previdian's public VULN-2026-0009 page, and the CISA KEV JSON. We read The Hacker News and BleepingComputer for the probing reports and the Shadowserver figures. We could not read N-able's Legacy API support article (it did not render), the researcher's or watchTowr's X posts, or the Shadowserver dashboard.
Our own edge: we searched every edge instrument for 30 days (since October 13) for requests to /dms/ paths, ServerUI and GenericAgent, and for the address 157.20.241[.]16. Zero matches in 327,067 edge blocks, 51,980 edge canary hits and 714 origin honeypot captures. That means nobody sent those requests to our domains. We run no N-central and have no N-central trap, so it says nothing about whether N-central servers are being scanned. Our corpus held no record of 157.20.241[.]16. We added no indicators to our feed: the one address in circulation is published by a news outlet quoting a vendor whose own page withholds it, and the researcher and N-able published none.
Sources
N-able, status dashboard incident 202609, "N-central Critical Security Incident - 2026.4.1 HF2 Release", November 12, 2026. N-able, status dashboard incident 202584 and N-central 2026.4 HF2 release notes, November 10 and 11, 2026. N-able, "Update on N-central 2026.4 HF2 and ongoing security response", November 11, 2026. The researcher's public GitHub repository, 4EverAble2Shell and Agent2Shell READMEs, November 12, 2026. CVE Program record CVE-2026-90436, published November 6, 2026. Previdian, VULN-2026-0009. CISA Known Exploited Vulnerabilities catalog, version 2026.11.10. The Hacker News, "New N-central Exploits Work Against Patched Servers, Enable Root RCE and Windows SYSTEM Access", Ravie Lakshmanan, November 12, 2026. BleepingComputer, "N-able releases security hotfixes for zero-day vulnerabilities", Sergiu Gatlan, November 11, 2026.
Every indicator in this post is in the feed. Free.
1.58M+ IOCs, STIX 2.1 / TAXII, 88% novel vs ThreatFox, exploited-CVE leads ahead of CISA. No credit card — a free API key in 30 seconds, and you can audit every claim above against the live endpoints.