Able2Shell: 33 flaws, one hotfix, two new chains – N-central for the fourth time this year

As of 13 November 2026, 4 p.m. CET. The situation is changing daily; N-able has announced a further hotfix.

Summary

• On 9 November an independent researcher published 33 vulnerabilities in N-able N-central on GitHub, with working exploit code (“Able2Shell”), without prior coordination with the vendor. Four chains lead to code execution or root on the N-central server; tested against appliance 2026.4.0.31.
• N-able took the hosted platform offline worldwide and advised operators of self-hosted installations to do the same. On 10 November, 2026.4 HF2 (build 2026.4.1.26) shipped with seven CVEs; agents and probes must be updated too.
• On 11 November two further exploit sets against HF2 followed: 4EverAble2Shell (unauthenticated root) and Agent2Shell (commands as SYSTEM on managed Windows endpoints). According to N-able, both require the Legacy API, which is not enabled by default.
• On 13 November N-able published indicators of real attacks: an XMRig miner fetched from 157.20.241[.]16. Huntback reports at least 21 compromised servers, 19 of them already on HF2.
• It is the fourth critical N-central situation this year – after CVE-2026-18556 in August and CVE-2026-86218 in September.

Timeline.

The seven CVEs in HF2.

N-able has not mapped which of the 33 findings these seven CVEs cover. The rest have no CVE IDs and no fix so far. Tenable lists some of the flaws as “Vulnerability of Interest”; as far as we can tell nothing has been added to CISA’s KEV catalogue yet.

What HF2 does not solve.

4EverAble2Shell uses the Legacy API – an older interface N-able describes as not recommended and not enabled by default, but which is frequently switched on in grown installations because some script once needed it. If it is enabled and reachable from the internet, there is currently no patch against the chain. Previdian links the chain to a flaw in Apache Axis (CVE-2026-90436); N-able has not confirmed this.

Agent2Shell is, in our view, the more serious part: more than ten findings in the communication between the N-central server and the Windows agents and probes. Two chains allow an attacker who can reach the server to execute commands on managed endpoints – as SYSTEM. That is the path from a compromised management server into every customer network attached to it. Huntress rightly points out that IP allowlists do not help here: the affected endpoints are the same ones agents and probes check in through, so they are reachable from every allowed network.

That the first observed attackers only installed a crypto miner is no reason for relief. In the September incident, attackers used N-central to spread scripts and tools into downstream customer environments. A miner is what an attacker does when they do not yet know what they have.

What to do now.

1. Disable the Legacy API. On every on-prem server, including those on HF2. N-able has published a guide. If it is needed: do not make it reachable from the internet.
2. Apply HF2, then agents and probes. Build 2026.4.1.26; the hotfix changes server-agent communication, so the server alone is not enough. N-able does not always bump the version number for live hotfixes – check the build number, not the version display.
3. Disconnect the server from the internet as long as the Legacy API was enabled or the further hotfix is pending. The most severe chain needs no credentials.
4. Hunt, do not hope. On every server reachable from the internet since 8 November:

In XIEM the server indicators map to Wazuh FIM on /var/opt/n-central and log rules on the SOAP endpoints named above; the endpoint indicators to Sysmon event 1 with the N-able agent as parent process and FIM on the probe directory. A hit means: treat the server and every customer environment attached to it as compromised.

1. If you are an MSP customer: ask whether your provider uses N-central, whether the Legacy API was enabled, when HF2 was applied and whether a hunt for the indicators took place. The answer belongs, in writing, in your supplier documentation.

The disclosure question.

The researcher – according to SANS a penetration tester with several certifications – says he reported vulnerabilities to N-able earlier this year, felt ignored, found dozens more with the help of AI and published everything at once. N-able speaks of “non-responsible communication”. Both are right, and that is the problem: a vendor whose product surfaces critical flaws four times in twelve months has a structural problem; a researcher who publishes full access to thousands of customer networks as leverage hits not the vendor but its customers. For operators, the question of blame changes nothing about the task.

The second part is the remarkable one: finding dozens of flaws in a product with AI assistance within weeks was a research project in 2024. In 2026 it is one annoyed individual. The time between “product is insecure” and “exploit is public” is not getting longer.

Context.

An RMM is the tool a service provider uses to manage all systems of all customers – by definition with SYSTEM rights, by definition reachable from the internet, by definition with access to scripts, credentials and remote sessions. Whoever compromises it has not one network but all of them. The SANS editors pose the exercise question every MSP should be able to answer: how do you investigate and recover when the tool you normally investigate and recover with can no longer be trusted?

For entities subject to NIS2, their MSP is a supplier in the sense of Article 21, and the RMM is its most critical system. How the provider acted this week is a question of supply-chain security – and the answer belongs documented. For MSPs themselves, the conclusion from September is unchanged: never expose the RMM console directly to the internet, access only via VPN or identity proxy, egress of the RMM server restricted to what is needed and logged, agent communication in its own segment. What that looks like is in the post on north-south and east-west.