MAG212 CYBER ORIGINAL ARTICLE

N-able N-central After HF2: Able2Shell, 4EverAble2Shell and the Legacy API Question

November 14, 2026 · El Mostafa Ouchen

N-central after the hotfix: Diagram of an N-central server with a Legacy API switch, showing hotfixed Able2Shell flaws, the 4EverAble2Shell path that works when the Legacy API is on, Agent2Shell commands to Windows endpoints, and outbound miner indic

From the MAG212 CYBER Weekly, 14 November 2026. Status labels: confirmed by vendor, reported by researchers, or unverified. Every command below is copied from official documentation and was not tested by MAG212; run it only on systems you are authorised to administer.

Status: Vulnerabilities confirmed by vendor: HF2 fixes seven CVEs, and N-able acknowledges that 4EverAble2Shell and Agent2Shell depend on the Legacy API [10]. Exploitation status is in conflict:

  • N-able reported scanning activity but “no evidence that any customer environment had been successfully exploited”, and Huntress has seen no exploitation in partner environments [10].
  • watchTowr saw exploitation attempts on honeypots [9].
  • N-able’s own 13 November IoCs include XMRig-delivery infrastructure [10].
  • The earlier draft’s claim of “live exploitation” (Huntback: 21 mining identities, 19 on HF2) is unverified, because the source could not be located.

What happened

About 04:14 UTC on 9 November (the evening of 8 November in the Americas), a researcher published proof-of-concept code for 33 alleged N-central vulnerabilities (“Able2Shell”) without notifying the vendor. N-able took hosted N-central offline in the Americas, Europe and APAC and told on-premises customers to shut down. Censys counted 1,728 internet-reachable hosts that day [9]. At 5:30 PM ET on 10 November, N-central 2026.4 HF2 (build 2026.4.1.26) fixed seven CVEs [10]:

  • CVE-2026-125883: XXE
  • CVE-2026-125878: OGNL injection
  • CVE-2026-125879: LPE to root via syslog-ng configuration
  • CVE-2026-125880: stored XSS
  • CVE-2026-125881: SSRF
  • CVE-2026-125882: RCE via upload path traversal
  • CVE-2026-91000: insecure IPC leading to LPE

At 1:10 AM ET on 12 November, the researcher released two more chains [10]:

  • “4EverAble2Shell”: unauthenticated RCE to root on the N-central server, working against HF2.
  • “Agent2Shell”: more than 10 issues in server-to-Agent/Probe communication, including two chains for unauthenticated command execution as SYSTEM on managed Windows endpoints.

At 6:30 AM ET, N-able said both require the non-default Legacy API to be enabled and exposed, and that hosted N-central is not vulnerable to 4EverAble2Shell [10]. N-able published IoCs at 10:25 AM ET on 13 November [10].

Who is affected

  • 4EverAble2Shell: on-premises N-central servers with the Legacy API enabled and reachable from the internet, including HF2 build 2026.4.1.26.
  • The seven HF2 CVEs: all builds before HF2.
  • Agent2Shell: managed Windows endpoints, where the Legacy API is enabled.

No CVE IDs exist yet for 4EverAble2Shell or Agent2Shell, and MAG212 found no HF3 [10].

Why this matters

An RMM server holds standing administrative access to every managed customer. Even with exploitation disputed, the combination of public PoCs, a fix that does not cover the newest chains and a non-default setting that decides exposure means MSPs must verify configuration, not just install a hotfix. Configuration drift, not missing patches, is the real risk here. (MAG212 analysis)

Diagram of an N-central server with a Legacy API switch, showing hotfixed Able2Shell flaws, the 4EverAble2Shell path that works when the Legacy API is on, Agent2Shell commands to Windows endpoints, and outbound miner indicators.
Diagram: MAG212 CYBER. Solid red = observed or vendor-confirmed; dashed amber = reported or unverified; green = recommended control.

How the attack works

These are researcher-described paths from published PoCs:

  1. Unauthenticated SOAP request to the N-central server.
  2. Code execution as the service account.
  3. Escalation to root (one HF2 CVE covers LPE via syslog-ng config).
  4. Possible abuse of the RMM channel to push commands to managed endpoints as SYSTEM (Agent2Shell).

N-able’s IoCs show a miner-delivery path (jup.sh, xmrig.tgz) on attacker infrastructure. Whether customer servers actually ran it is not established in the sources MAG212 could reach.

What defenders should look for

N-able IoCs, 13 Nov, defanged [10]:

  • URLs: hxxp://157.20.241[.]16:8080/jup.sh, /xvgz, /xmrig.tgz, /ob/cronhit?h=jup_start_<rig>&persist=<method>, /ob/fcheck
  • Outbound connections: 157.20.241[.]16 (ports 8080 and 19202–19418), 139.99.69[.]109:10128, 79.76.51[.]56:39100

Huntress static-analysis indicators (not observed in the wild) [10]:

  • Server requests and files:
    • POSTs to /dms/services/ServerUI containing jline.internal.TerminalLineSettings or GenericAgentXMPPMessageExchange with SessionID −1
    • POSTs to /dms2/services2/ServerMMS2 containing RemoteExecutionTaskSubmit with sessionID −1
    • /var/opt/n-central/flag/flag_default.json as a symlink to /opt/nable/var/ncsai/scripts/ServerChild.sh
    • /var/opt/n-central/tmp/serverchild-<12hex>.{bak,sh,out}
    • ZIPs under /download/scheduled_tasks/output_files/ containing CodeDropMeta.xml
  • Windows endpoints:
    • powershell.exe -NoProfile -NonInteractive -EncodedCommand running as SYSTEM, spawned by the N-able Agent
    • wsp.exe or service.cfg written to Windows Software Probe\bin
    • taskkill /f /im wsp.exe run from a .cmd file in %TEMP%

False positives. RMM platforms legitimately run encoded PowerShell as SYSTEM, so match it against your scheduled automation before escalating. A single SOAP request can be a scanner probe.

Unverified (from the earlier draft only): /tmp/.xvd, /var/tmp/.xvd, xvd.service.

How to investigate

Follow Huntress’s guidance [10]:

  • Review activity from 11 November onward for unexpected admin accounts, scripts, scheduled tasks and remote sessions.
  • Record the build, Legacy API status and the firewall/ACL history for the exposure window.
  • Group managed endpoints by customer and tenant, and review any script pushes that change tickets do not explain.

Contain and remediate (in order)

  1. Confirm the Legacy API is disabled, using N-able’s KB procedure. If it must stay enabled, do not expose it to the internet, and do not rely on IP allowlisting alone [10].
  2. Apply HF2.
  3. Upgrade Agents and Probes as well as servers, because HF2 changes how they communicate [10].
  4. Block and hunt the IoC addresses.
  5. If you find compromise, rebuild the server from trusted media and rotate RMM, integration and customer credentials from a clean control plane.

Verify recovery

N-able warned that a patched build may not change the version number [9], so confirm patch state with N-able rather than by version string. Test from an external vantage point that the Legacy API path is unreachable. Confirm Agents and Probes check in, then run a harmless approved job on one canary endpoint per tenant.

Prevention and awareness

RMM consoles are a “keys to every customer” asset. Put them behind VPN or zero-trust access, log admin actions off-box, and give each MSP technician a separate identity protected by phishing-resistant MFA.

No command panels. No official N-able doc for checking or disabling the Legacy API was verified [10].

Related on MAG212 CYBER

Sources

  1. [9] Cloud Security Alliance Labs, “CSA research note: Able2Shell N-central zero-days”, 10 Nov 2026. link
  2. [10] Huntress, “N-able disables cloud services following disclosure of Able2Shell exploit chains”, 9 Nov, updated through 13 Nov 2026. link

Written and edited by El Mostafa Ouchen for MAG212 CYBER. Facts checked against the sources above as of 14 November 2026, 10:05 AM PST. Diagrams are original MAG212 CYBER illustrations.