N-able N-central Able2Shell Zero-Days: Response and Hunting

N-able N-central is the remote monitoring and management platform many MSPs use to run scripts, push software and take remote control of every endpoint they manage. On November 9, 2026, an independent researcher published a GitHub repository called Able2Shell with working proof-of-concept code for 33 vulnerabilities in N-central, without coordinating with N-able first. Several need no login at all. The worst chain goes from an anonymous request to commands running on the N-central server and an enabled administrator account with a password the attacker chooses.

N-able responded the same day. It took its hosted N-central environments offline in the Americas, Europe and Asia-Pacific, told on-premises customers to take their N-central servers offline until further notice, and said it is developing and validating a hotfix. N-able says it has seen no active exploitation and no unauthorized data access. There are no CVE IDs and no fixed version yet.

An N-central server controls every device it manages, so a compromise of the server is a compromise of every customer behind it. With exploit code public, treat any N-central server that stayed reachable after November 9 as exposed until you have checked it.

What was published

The researcher tested on N-central Appliance 2026.4.0.31, a pre-release build, and writes that most if not all of the issues should also work on earlier versions, including the current release. The repository holds one Python proof of concept per issue, with output and screenshots. The issues that matter most for defenders:

The chains combine these. An anonymous attacker gets code execution as nable through the XXE chain, then root through the syslog installer or the pre-upgrade helper, which run files the nable account can write. The XXE proof of concept also cleans the staging logs it leaves behind, so do not rely on the absence of log entries.

What N-able has said

N-able opened a critical security incident on its status page at 15:15 UTC on November 9 and updated it at 19:59 UTC:

• Hosted N-central is offline in all three regions while N-able secures the environment. The hosted classic N-central console and its associated services are unavailable.
• On-premises N-central customers should secure their environments and keep their servers offline until N-able confirms they can be brought back.
• N-able.app stays online. The Ecoverse services under N-able Login (Asset View, Patching, Vulnerability Management, scripting, policies and tagging) remain available to hosted and on-premises partners who use N-able Login, and N-able added Take Control from the Assets view and on-demand Windows patching as previews.
• A hotfix is being developed and validated. N-able has given no restoration time and says it will update the status page every four hours or sooner.
• No exploitation: “we have no evidence of active exploitation or unauthorized data access.”

Who is affected

• Every on-premises N-central server, of any version, until N-able publishes a fix. The researcher tested a 2026.4 pre-release and expects earlier builds to be affected.
• Hosted N-central partners, whose environments N-able has taken offline. Hosted partners have no server to patch but should still run the endpoint hunts below.
• The customers of those MSPs. N-central agents run with SYSTEM or root rights on managed devices, so a compromised server can run anything on them.

N-able’s incident lists only N-central. The repository covers only N-central, and the other N-able products are not named in either.

What to do now

1. Keep on-premises N-central servers offline, as N-able instructs, or at minimum block all inbound access from the internet at the firewall. Do not bring them back until N-able publishes the hotfix and its guidance.
2. Preserve evidence before you change anything. Take a snapshot or disk image of the server and export firewall, proxy and VPN logs that cover it from November 8 onward.
3. Check the server with the steps below, from the console with the server isolated from the network.
4. Run the endpoint hunts across managed devices for anything the N-central agent or Take Control ran since November 8 that your team did not schedule.
5. Plan for rotation. If the server was reachable from the internet after November 9, assume the credentials it holds are known: N-central administrator and Technician passwords, asset discovery credentials, agent registration tokens, Ecosystem Agent keys, and any passwords embedded in Automation Manager policies or scripts. Rotate them once the hotfix is installed, starting with domain accounts that discovery or scripts use.
6. Keep critical work going through N-able.app, which N-able says is unaffected, and tell your customers that N-central monitoring and scheduled tasks are paused.
7. Install the hotfix as soon as N-able releases it, and limit the N-central web console to your own management networks afterward.

Checking an N-central server

Run these from the console with the server disconnected. They look for what the published chains leave behind. Treat any hit as a compromise of the server and of the customers it manages.

# 1. JSP files written to the web application tree since the disclosure
find /opt/nable/webapps -name '*.jsp' -newermt '2026-11-08' -ls

# 2. Anything else new under the web root, including the tmp folder the test-email flaw writes to
find /opt/nable/webapps/ROOT -type f -newermt '2026-11-08' -ls

# 3. syslog-ng program() destinations, which the Audit Export and syslog installer chains add to run commands as root
grep -rn 'program(' /etc/syslog-ng/

# 4. Files the nable account can write that root later runs (syslog and upgrade helpers)
find / -xdev -user nable -newermt '2026-11-08' -type f 2>/dev/null | grep -v '/opt/nable/var/log' | head -200

# 5. Shell history and processes started by the nable account
ps -o user,pid,ppid,lstart,cmd -u nable

Then check the console itself once you can open it safely:

• Users: look under Administration for any administrator or Technician account created, re-enabled or given a new password since November 8. The XXE chain creates an enabled administrator account with the attacker’s username and resets an existing account’s password.
• Audit Export: a server address you do not recognize, or one with extra characters after the IP, points to the syslog-ng injection.
• Patch details: patch entries with script or HTML in their names or descriptions point to the stored XSS. Do not open them while logged in as an administrator.
• Scheduled tasks, scripts and Automation Manager policies created or changed since November 8.

Threat hunting queries

The queries below are examples written in KQL for Microsoft Defender for Endpoint and Microsoft Sentinel. Adapt them to your own platform, tables and field names, and test them before you rely on them. Run them from November 8, 2026. Set ncentral to the public and private addresses of your N-central server.

Hunt 1: inbound connections to the N-central server from the internet

let ncentral = dynamic(["203.0.113.10", "10.0.0.10"]);
CommonSecurityLog
| where TimeGenerated > datetime(2026-11-08)
| where DestinationIP in (ncentral)
| where not(ipv4_is_private(SourceIP))
| summarize Connections = count(), Ports = make_set(DestinationPort), First = min(TimeGenerated), Last = max(TimeGenerated)
    by SourceIP, DeviceVendor, DeviceAction
| order by Connections desc

Agents connect to the server too, so expect your customers’ addresses here. Look for sources that are not customer sites, VPN egress or N-able, especially after 04:00 UTC on November 9.

Hunt 2: outbound connections from the N-central server

let ncentral = dynamic(["203.0.113.10", "10.0.0.10"]);
CommonSecurityLog
| where TimeGenerated > datetime(2026-11-08)
| where SourceIP in (ncentral)
| where not(ipv4_is_private(DestinationIP))
| summarize Connections = count(), Ports = make_set(DestinationPort), Urls = make_set(RequestURL, 20),
    First = min(TimeGenerated), Last = max(TimeGenerated)
    by DestinationIP, DestinationHostName
| order by First asc

The XXE chain makes the server fetch a DTD file from a host the attacker controls, so an N-central server opening HTTP connections to an unfamiliar address is a strong lead. The proof of concept requests /external.dtd and /repo/Repository.xml on its callback host. An attacker can rename them, so treat the paths as a hint, not a rule.

Hunt 3: commands the N-central agent ran on managed Windows devices

DeviceProcessEvents
| where Timestamp > datetime(2026-11-08)
| where InitiatingProcessFolderPath has_any (@"\N-able Technologies\", @"\BeAnywhere Support Express\")
| where FileName in~ ("cmd.exe", "powershell.exe", "pwsh.exe", "wscript.exe", "cscript.exe", "mshta.exe",
                      "rundll32.exe", "regsvr32.exe", "certutil.exe", "bitsadmin.exe", "curl.exe", "net.exe", "net1.exe")
| summarize Devices = dcount(DeviceName), Runs = count(), Example = any(ProcessCommandLine),
    First = min(Timestamp), Last = max(Timestamp)
    by InitiatingProcessFileName, FileName, CommandHash = hash_sha256(ProcessCommandLine)
| order by First asc

Your own scripts and patching show up here as well. Compare each command with what your team scheduled. Commands that appear across many devices at once, after November 9, and that nobody on your team recognizes are the ones to chase.

Hunt 4: local accounts and admin group changes made through the agent

DeviceProcessEvents
| where Timestamp > datetime(2026-11-08)
| where InitiatingProcessParentFileName has_any ("agent.exe", "BASupSrvc.exe") or InitiatingProcessFolderPath has @"\N-able Technologies\"
| where ProcessCommandLine has_all ("net", "user", "/add") or ProcessCommandLine has_all ("localgroup", "administrators", "/add")
    or ProcessCommandLine has_any ("New-LocalUser", "Add-LocalGroupMember")
| project Timestamp, DeviceName, AccountName, ProcessCommandLine, InitiatingProcessFileName, InitiatingProcessCommandLine
| order by Timestamp asc

Hunt 5: web shells on the N-central server

For servers running Microsoft Defender for Endpoint on Linux:

DeviceFileEvents
| where Timestamp > datetime(2026-11-08)
| where FolderPath startswith "/opt/nable/webapps"
| where FileName endswith ".jsp" or FolderPath has "/ROOT/tmp"
| project Timestamp, DeviceName, ActionType, FolderPath, FileName, InitiatingProcessAccountName, InitiatingProcessCommandLine
| order by Timestamp asc

Timeline

• November 3: N-able makes N-central 2026.4 HF1 available for on-premises servers. It fixes AlmaLinux CVEs, not these issues.
• November 9, 04:14 UTC: the Able2Shell repository is published on GitHub with proof-of-concept code for 33 issues, tested on N-central 2026.4.0.31.
• November 9, 15:15 UTC: N-able opens a critical security incident, takes hosted N-central offline and tells on-premises customers to take their servers offline.
• November 9, 19:59 UTC: N-able says a hotfix is still in development and it has no evidence of exploitation or unauthorized data access.

Frequently Asked Questions

Do the N-central Able2Shell vulnerabilities have CVE IDs? Not yet. Neither N-able nor the researcher has published CVE IDs. We will add them here when they are assigned, along with the fixed version.

Are the N-central zero-days being exploited? N-able says it has seen no active exploitation and no unauthorized data access as of November 9. Working exploit code is public, though, and an anonymous chain to code execution is included, so exploitation of any N-central server left reachable from the internet should be expected.

Does N-central 2026.4 HF1 fix these vulnerabilities? No. HF1, released on November 3, carries AlmaLinux security updates for CVE-2026-98432, CVE-2026-111497 and CVE-2026-114406. It predates the disclosure. Keep the server offline until N-able releases the hotfix for Able2Shell.

Can we still manage endpoints while N-central is offline? Partly. N-able says N-able.app stays online for partners who use N-able Login, with Asset View, Patching, Vulnerability Management, scripting, policies and tagging, plus Take Control from the Assets view and on-demand Windows patching as previews. Monitoring, alerting and scheduled tasks that run through N-central itself stop until the server is back.

Our N-central server is only reachable over VPN. Do we still need to shut it down? N-able’s guidance covers all on-premises servers, so follow it. A server that was never reachable from the internet is at much lower risk, but anyone on the internal network, or a compromised device that can reach the console, can still use the anonymous flaws.

Are other N-able products affected? N-able’s incident names only N-central, and the Able2Shell repository covers only N-central. N-able has not said anything about its other products.

What should we tell our customers? That N-central management of their devices is paused on the vendor’s instruction, that N-able reports no exploitation, and that you are checking the server and their devices for anything unexpected. Share the outcome of the hunts above when they finish.

How ThreatDefence is responding

Across all monitored environments, including partners that run N-central, our SOC is:

• reviewing every command the N-central agent or Take Control started since November 8 that the partner did not schedule
• alerting on new local administrator accounts and admin group changes made by remote management agents
• flagging N-central consoles reachable from the internet

If you run N-central for your customers and want help checking your server or managed devices, or with an incident, contact us. Read more about our SOC for MSPs and MSSPs and endpoint threat visibility.

Sources

• N-able Uptime, IMPORTANT: N-central Critical Security Incident (November 9, 2026, updated 19:59 UTC)
• Sean Bales, Able2Shell – N-Central N-Able, GitHub repository (November 9, 2026)
• Sean Bales, Able2Shell announcement, LinkedIn (November 9, 2026)
• N-able Uptime, N-able N-central 2026.4 HF1 Security Update Available for AlmaLinux CVEs (November 3, 2026)
• N-able, N-central 2026.4 Hotfix 1 release notes (November 2, 2026)
• N-able documentation, N-able.app overview