N-able Takes N-central Offline After a Researcher Publishes Over 30 Alleged Zero-Days With Exploits, With No CVE IDs Yet and Three N-central Flaws Already on CISA’s Exploited List This Year

N-able switched off its hosted N-central environments on Monday, November 9, and urged customers who run N-central on their own servers to switch them off too, after a security researcher published proof-of-concept exploits for what he says are more than 30 zero-day flaws in the remote monitoring and management (RMM) platform. BleepingComputer and SecurityWeek carried the story. We read N-able’s own incident page, CISA’s exploited-vulnerabilities feed and the National Vulnerability Database to separate what is established from what is claimed. This is a snapshot from between 10:00 and 10:30 UTC on Tuesday, November 10, before N-able’s hotfix has shipped.

Three facts frame it. N-able says it has seen no active exploitation, but that statement covers only what N-able has observed, the on-premises servers it wants switched off are run by its customers, and the exploit code has been public for more than 30 hours (the commit that added it is stamped 04:14 UTC on November 9, late on Sunday in US time). No CVE ID had been published for any of the new flaws when we checked, and CISA’s list is keyed to CVE IDs. And N-central already has three entries on that list from this year, all added within 36 days (August 3 to September 8), while in September N-able’s public hotfix post said it had no confirmation of exploitation days before CISA listed that flaw as exploited.

What N-able has said

N-able’s status dashboard is a JavaScript page, so we rendered it in headless Edge; its header read “Last Updated: Nov 10, 2026 10:09:58 UTC”. The vendor’s account is incident 202561, severity “Major Outage”, status “Investigating”, opened at 15:15 UTC on November 9 under the banner “N-central Critical Security Incident”. It describes the trigger as “a public disclosure and non-responsible communication of critical vulnerabilities in N-central found by an independent researcher”, so N-able’s own wording treats the reports as describing real critical flaws, although it has not said how many it has validated.

The instructions are plain. N-able “strongly advises” customers who run N-central on their own servers to take them offline “until further notice”, and the page adds: “Customers should keep their N-central servers offline until N-able provides further guidance confirming when they can safely be brought back online.” Hosted N-central is down in all three regions. What remains is the platform’s other half: “the Ecoverse services under N-able Login remain available and online including Asset View, Patching, Vulnerability Management, scripting, policies and tagging”, reachable through n-able.app, where N-able has added Take Control from the Assets view and an on-demand preview of Windows patching.

The reassurance is scoped to what N-able has seen. The incident text says “we have not seen any active exploitation of these vulnerabilities”, and the 05:00 UTC update adds “we have seen no indication that your environment has been impacted or compromised as a result of these vulnerabilities throughout this security incident”. The page publishes no indicators of compromise, no list of affected versions and no mitigation other than staying offline, and N-able says it will post updates “every four hours, or sooner if significant new information becomes available”.

A second, older incident on the same dashboard is easy to miss. It is ID 202484, opened November 3, and it tells on-premises customers to install N-central 2026.4 HF1, which carries AlmaLinux security updates for CVE-2026-98432, CVE-2026-111497 and CVE-2026-114406; hosted environments were already patched. We covered the first two when they broke, the Linux TCP flaw behind Anthropic’s remote-root exploit and the Brotli decoder flaw. The third is the Red Hat ca-certificates entry for the eMudhra weak-key certificate authorities. An administrator preparing an on-premises server for the new hotfix may need both, and the dashboard does not say whether the new hotfix includes HF1.

What the researcher published

Both outlets name the researcher as Sean Bales. He dubbed the flaws Able2Shell, and the exploits sit in a folder of a larger GitHub repository of his disclosures; we are not linking it. GitHub’s API shows a commit titled “N-Able 0-Days” stamped 04:14:21 UTC on November 9, which fits N-able’s “late Sunday night”, and a plain request for the folder still returned HTTP 200 at 10:13 UTC on November 10, although, according to Bales, N-able’s CEO and CTO asked him to take the repository down. We did not download, read or run any of the exploit code; everything below about its contents comes from the two news reports.

BleepingComputer lists the flaw classes as authentication bypasses, credential disclosure, arbitrary file writes, directory traversal, cross-site scripting, XML external entity (XXE) injection and remote code execution. It says Bales tested against “N-central Appliance 2026.4.0.31, a pre-release version of the software” and “believes most, if not all, flaws also affect earlier versions”. SecurityWeek adds that he describes four exploit chains that end in code execution as the nable user or as root. Bales told BleepingComputer that the unauthenticated XXE-to-RCE exploit is the most critical of the set and that the discovery was AI-assisted. N-able’s documentation site answered our scripted request for the 2026.4 HF1 release notes with HTTP 403, so we could not map build 2026.4.0.31 to a published release; the dashboard calls 2026.4 HF1 “now available”, which implies a generally available 2026.4 exists, but nothing we read says whether the repository’s targets are on that hotfix or before it.

No CVE IDs have been assigned. SecurityWeek says so, and our NVD search at 10:16 UTC for records published since November 5 that mention N-central or N-able returned zero for both terms (the script is at the end).

The disclosure dispute is where the accounts diverge. Bales says he published without notice because earlier reports went nowhere: “I disclosed 2 unrelated RCEs for a different N-able product, along with a priv esc vulnerability 5 or 6 months ago. These have yet to be patched. I did not disclose any of the 0-days I posted last night,” he told BleepingComputer. He also claimed he received no payment through N-able’s bug bounty platform and that the executives who contacted him “did not threaten me or anything though. Only asked to take down the repo, work with them, etc.” N-able did not answer BleepingComputer’s questions about the earlier reports. Its public program page says it will acknowledge initial reports “within 48hrs of notification” and asks researchers to “not publicly disclose the reported vulnerability until we have mitigated the issue”; that page mentions a Hall of Fame, and neither it nor the policy page mentions rewards. The repository’s own description says its entries are “disclosed responsibly and vendors have been contacted”, while two later commits on November 9 are titled “Update responsible disclosure details” and “Add disclaimer to README.md”. We cannot verify either side’s account of the earlier reports.

Three N-central entries on CISA’s list in 36 days

CISA’s feed holds five N-able entries, all for N-central. The three from 2026 carry a three-day federal deadline; the two from 2025 had seven days. The script at the end prints CISA’s exact names for all five.

Set N-able’s own words beside those dates. In August, N-able’s own blog said that on July 31 its Adlumin MDR solution “detected unusual activity inside a customer environment and identified a threat actor actively exploiting a previously unknown vulnerability”, and that when “continued monitoring on August 6 surfaced a related attack path” it released Hotfix 2 the same day; Help Net Security quoted the notice as saying: “Hotfix 2 is required, even if you already applied the earlier hotfix.” In September, N-able’s public hotfix post, last updated September 5, said: “we have no confirmations that this vulnerability has been exploited in production environments, but unpatched systems remain at risk.” Help Net Security reported that a separate urgent notice sent to customers said the flaw “has been observed being exploited in the wild”, and CISA listed it on September 8. Huntress said, in the same report, that “logs on the compromised N-central server had already rotated”, so it could not say whether CVE-2026-86218 was the flaw used in a customer intrusion it had examined.

None of this shows the present statement is wrong. It does show that in September N-able’s public wording and its direct notice to customers differed, according to Help Net Security, and that CISA’s listing followed within days. Our reading is that a server which stayed reachable after about 04:14 UTC on November 9, the commit time of the exploit code, should be treated as exposed until its own logs say otherwise. We saw the same shape, public exploit text before a merged fix, in the Linux kernel local-root report.

The stakes are the usual ones for RMM: one server controls every managed endpoint. In the August intrusions, according to Help Net Security’s account of N-able’s report, the attackers used the legitimate Take Control feature to reach managed endpoints and registered a service for a Cloudflare tunnel to persist, and Sophos reported a new domain account named “veeam”. We have covered the same class of exposure, one tool with reach into many customer environments, in our ConnectWise Cloud Backup and Storm-0940 reports.

What to do while the hotfix is pending

The only concrete instruction from N-able is the one above: keep on-premises servers offline until the vendor says otherwise. The rest is our reading, not N-able guidance:

• Snapshot before you change anything. Keep the server’s logs and a snapshot or image of its disk before applying the hotfix or bringing it back, because the September Huntress case shows what rotated logs cost an investigation.
• Review accounts after patching. N-able’s own September advice was “auditing your N-central user accounts to ensure that there are no unexpected users”, and BleepingComputer describes one published chain as creating an enabled “Default Administrator” account, so look for users nobody on your team created.
• Review automation and endpoints. Check scripts and automation policies for changes, and check managed endpoints for new services or remote-access tools; the August attacks registered a Cloudflare tunnel service.
• Rotate stored credentials. The published list includes credential disclosure, so treat anything stored in or reachable from a server that stayed online as in scope. That is our inference; N-able has not said it.
• Use the interim tools N-able names. Patching, scripting and Take Control are available through n-able.app while the classic console is down.

What we could not establish

• The CVE IDs and severity scores, which do not exist yet.
• The real count. “More than 30” is the researcher’s figure, and N-able has not said how many reports it has validated.
• The affected versions. BleepingComputer gives the tested build and the researcher’s belief about earlier ones; the incident text names none.
• What the hotfix covers, its build number, and when hosted environments return.
• Any third-party evidence of exploitation. We found none in the two news reports or on N-able’s page; Huntress’s blog was blocked to our scripted requests.

The checks we ran

This standard-library script (Python 3.13.14, Windows 11) reads CISA’s feed and asks NVD for new records. The NVD API allows five requests per 30 seconds without a key, so the script waits seven seconds between requests. We ran it at 10:16 UTC on November 10; its output will change as CISA and NVD publish.

# nc_check.py
import json
import time
import urllib.parse
import urllib.request

UA = {"User-Agent": "Mozilla/5.0 (Windows NT 10.0; Win64; x64) Chrome/130.0.0.0 Safari/537.36"}


def get_json(url):
    req = urllib.request.Request(url, headers=UA)
    with urllib.request.urlopen(req, timeout=60) as resp:
        return json.load(resp)


KEV = "https://www.cisa.gov/sites/default/files/feeds/known_exploited_vulnerabilities.json"
feed = get_json(KEV)
print(f"KEV catalog {feed['catalogVersion']}, released {feed['dateReleased'][:19]}Z, {feed['count']} entries")
rows = [v for v in feed["vulnerabilities"] if v["vendorProject"] == "N-able"]
print(f"N-able entries: {len(rows)}")
for v in sorted(rows, key=lambda v: v["dateAdded"]):
    print(f"  {v['cveID']:<15} added {v['dateAdded']}  due {v['dueDate']}  {v['vulnerabilityName']}")

NVD = "https://services.nvd.nist.gov/rest/json/cves/2.0"
for term in ("N-central", "N-able"):
    query = urllib.parse.urlencode({
        "keywordSearch": term,
        "pubStartDate": "2026-11-05T00:00:00.000",
        "pubEndDate": "2026-11-10T23:59:59.000",
    })
    data = get_json(f"{NVD}?{query}")
    print(f"NVD records published since Nov 5 matching {term!r}: {data['totalResults']}")
    time.sleep(7)

Its output:

KEV catalog 2026.11.09, released 2026-11-09T19:54:37Z, 1773 entries
N-able entries: 5
  CVE-2025-8876   added 2025-08-13  due 2025-08-20  N-able N-Central Command Injection Vulnerability
  CVE-2025-8875   added 2025-08-13  due 2025-08-20  N-able N-Central Insecure Deserialization Vulnerability
  CVE-2026-18577  added 2026-08-03  due 2026-08-06  N-able N-central Authentication Bypass Using an Alternate Path or Channel Vulnerability
  CVE-2026-18556  added 2026-08-04  due 2026-08-07  N-able N-central Authentication Bypass Using an Alternate Path or Channel Vulnerability
  CVE-2026-86218  added 2026-09-08  due 2026-09-11  N-able N-central Static Code Injection Vulnerability
NVD records published since Nov 5 matching 'N-central': 0
NVD records published since Nov 5 matching 'N-able': 0

Limits: we did not download, read or run any exploit code, we do not link the repository, and nothing here was tested against an N-central server. GitHub was read through its API for commit metadata and with one plain request for the folder’s status. N-able’s documentation site (HTTP 403 for the 2026.4 HF1 release notes) and Huntress’s blog (a Cloudflare block) would not open for scripted requests, so the September account rests on N-able’s own hotfix post and on Help Net Security’s reporting. The dashboard will have changed since 10:09 UTC, and N-able’s hotfix target falls after this snapshot.

Sources

• BleepingComputer, Lawrence Abrams, November 9, 2026
• SecurityWeek, Ionut Arghire, November 10, 2026
• N-able status dashboard (incidents 202561 and 202484, read at about 10:10 UTC on November 10)
• N-able, N-central 2026.3 Hotfix 4, CVE-2026-86218
• N-able, N-central Security Update, August 6, 2026
• N-able Vulnerability Disclosure Program and Vulnerability Disclosure Policy
• Help Net Security, September 7, 2026 and August 10, 2026
• CISA Known Exploited Vulnerabilities feed (catalog 2026.11.09)
• NVD records for CVE-2026-18577, CVE-2026-18556, CVE-2026-86218 and CVE-2026-114406