N-able N-central: 30+ Zero-Days Published, Platform Taken Offline
A researcher published 30+ N-able N-central zero-days with working exploits and no patch exists. N-able pulled its hosted RMM offline — what MSPs do now.
Published by Zero Hunt, an autonomous AI red team on an on-premise appliance running private AI: automated penetration testing for networks and infrastructure, black-box or gray-box, with a human approving every step that matters.
An RMM server is the one box an attacker most wants to own, because it already owns every endpoint it manages. On the night of Sunday, November 8, a security researcher published more than thirty alleged zero-days in N-able N-central — the remote monitoring and management platform thousands of MSPs run — with working proof-of-concept exploits and no patch in existence. By Monday, November 9, N-able had taken its entire hosted N-central estate offline across the Americas, Europe and Asia-Pacific and told on-premises customers to shut their servers down "until further notice." There is no fixed version to upgrade to, and no CVE to scan for. If you run N-central, your exposure question has to be answered without either.
Developing story — first published 22:36 CET (21:36 UTC), November 9, 2026. Updated as the vendor and CISA publish more.
What happened
The researcher, Sean Bales, released the bugs without coordinating with N-able and published a repository of proof-of-concept exploits, announced on LinkedIn. Per BleepingComputer's reporting, he says he went public because earlier reports he had filed against a different N-able product — two unrelated RCEs and a privilege-escalation flaw — went unfixed for five to six months, with roughly five follow-up emails over four to six weeks and no reply, and no bug-bounty payment. N-able did not address those specific allegations; after the disclosure its CEO and CTO reportedly contacted Bales and asked him to remove the repository.
The thirty-plus findings are not minor. They span authentication bypasses, credential disclosure, arbitrary file writes, directory traversal, cross-site scripting, XXE injection and remote code execution. The worst chain described is an unauthenticated XXE in the service-import functionality: it can steal a trusted local session, reset an account password, and run commands as the nable service user — and from there create an enabled Default Administrator account. A separate stored XSS runs commands as root when an administrator merely views malicious patch metadata, and a privilege-escalation flaw promotes code running as nable to root. All testing was done against a pre-release build, N-central Appliance 2026.4.0.31, which the researcher says was unpatched at the time of posting; he believes most or all of the flaws affect earlier versions too.
N-able's position, as of this writing, is that it has "not observed active exploitation of these vulnerabilities" and sees "no evidence of active exploitation or unauthorized data access," and that it is developing and validating a hotfix. Read that for what it is: a statement about the vendor's own telemetry, not a clean bill of health for an on-prem appliance it cannot see.
Why an N-central compromise is a fleet compromise
N-central is not an ordinary web application. It is the console an MSP uses to push scripts, deploy patches and run commands on every managed endpoint across every client network it touches. An attacker who reaches Default Administrator on one N-central inherits that reach. This is the MSP supply-chain blast radius, and N-central has sat in it before: in August an already-exploited authentication bypass (CVE-2026-18577) landed the platform in CISA's Known Exploited Vulnerabilities catalog, and before that SecurityWeek reported more than 870 instances still unpatched against two exploited 2025 flaws, per Shadowserver.
The architecture makes it worse. When Horizon3 patch-diffed last year's N-central fixes, they found that the leaked chain, "when combined, allow for an unauthenticated attacker to interact with legacy APIs and read sensitive files," and that "in nearly all deployments… the leaked credentials led to compromising the N-central database" — a database that stores integration secrets, domain credentials, API keys and SSH private keys in recoverable form. They also counted roughly 3,000 N-central instances exposed on the internet.
Remediation
There is no patch yet. Treat this as containment first, eradication later.
- Am I affected? If you run N-central in any form, assume yes until proven otherwise. Hosted / cloud: N-able has taken the environment offline; there is no customer action beyond watching the status page. On-premises: you are exposed, and the worst chains are unauthenticated against the web console.
- Patch — exact fixed version: none exists. N-able says a hotfix is in development and that it will post updates on its status page roughly every four hours. Do not wait online for it.
- Can't shut down? Compensating controls. Follow the vendor and take on-prem N-central offline until the hotfix lands. If a hard shutdown is genuinely impossible, at minimum remove the management console from the public internet — VPN or IP-allowlist only — because the critical flaws need no credentials. Network isolation does not fix the bugs; it removes the unauthenticated attacker's path to them.
- Hunt for compromise. Working from the published mechanisms, look for: an unexpected or newly enabled Default Administrator account; admin accounts whose passwords were reset without a matching change ticket; processes or commands spawned by the
nableservice account; and unexplained edits to patch or service-template metadata. Because N-central is the delivery channel, also review scripts and tasks recently dispatched to managed endpoints. Map it to ATT&CK: Exploit Public-Facing Application (T1190), Valid Accounts (T1078), Create Account (T1136), and the trusted-relationship fan-out an RMM enables (T1199 / T1219). - Eradicate + verify. If you find indicators, treat the appliance as untrusted: rebuild from a known-good image and rotate every secret the appliance held — integration and domain credentials, API keys, SSH keys — since the database stores them recoverably. When the hotfix ships, confirm it actually closes the unauthenticated path rather than trusting the version string.
What is not known yet
CVE identifiers have not been assigned. No fixed version exists, so there is nothing yet in CISA KEV for this disclosure. Independent confirmation of each of the thirty-plus flaws is still pending — BleepingComputer notes it has not verified them all. N-able's "no active exploitation" claim has not been independently corroborated, and whether the researcher's repository has been taken down is unclear. We will update as the hotfix, CVE assignments and any exploitation reports land.
Scanning a version tells you nothing here
Every detection playbook that keys on a CVE number or a patched build fails on this story, because there is neither. The only honest answer to "is my N-central exploitable" is to run the chain against it and see. That is what an autonomous AI red team does differently from a scanner: Zero Hunt's 10-agent swarm identifies the exact installed version, writes a working proof-of-concept for that environment rather than matching a signature, and runs it in an ephemeral, hardened container that never touches the appliance host — gray-box against your own gear, with a human approving every step and each finding signed at write time. It runs on-premise on private models, so pointing it at an RMM that holds your clients' credentials never ships those credentials to a third party. When there is no CVE to wait for, proving exploitability yourself — the same way the researcher did — is the fastest way to know whether you are the next headline. Continuous, governed validation of exactly this kind is covered in our guide to automated penetration testing.
And because a compromised N-central is a compromise of everything it manages, detection cannot stop at the appliance. Zero Hunt's AI Traffic Analysis — a deep-learning model with four inference heads running on the appliance GPU — watches for the fan-out itself: an RMM console suddenly pushing to hosts it has no business reaching, credential-laden sessions to never-seen ASNs, the staging and egress of a bulk data pull while it is happening. A vendor's "no evidence of active exploitation" is a statement about their visibility. The traffic on your own wire is the part you can actually verify.
Is this exploitable in your environment?
Zero Hunt answers that on your own network: an autonomous AI red team on an on-premise appliance, running on private AI, black-box or gray-box, with a human approving every step that matters. Proof of what is exploitable, the fix, and signed evidence — no data leaves your perimeter.