CVE-2026-86218: N-central's Third Zero-Day in Weeks

Three patch cycles in six weeks is not a coincidence, it’s a pattern. CVE-2026-86218 is a pre-authentication remote code execution flaw in N-able N-central, rated CVSS 10.0, the maximum score the scale allows. If you run N-central on-premises, the fix is Hotfix 4 (version 2026.3.1.14, released September 5, 2026), and you need to apply it today, not after you finish reading this. CISA added the CVE to its Known Exploited Vulnerabilities catalog within days, which means the “is anyone actually using this” question is already answered.

We wrote about the first two rounds of this back in August, when CVE-2026-18576 and its incomplete follow-up CVE-2026-18577 gave attackers a way into N-central without credentials. If you haven’t already closed that gap, our patch guide for CVE-2026-18577 is still the right starting point, since some of the same detection steps apply here. But CVE-2026-86218 is a different animal, and worth separating from what came before.

What’s actually different this time

The August bugs were authentication bypasses. An attacker who exploited CVE-2026-18576 or CVE-2026-18577 got in the front door without a key, but they still had to walk through the application afterward. CVE-2026-86218 skips the door entirely. It’s a static code injection flaw (CWE-96) that lets an unauthenticated attacker execute arbitrary code on the N-central server directly. No login, no session, no valid request pattern to abuse. That’s the difference between “we left a window unlocked” and “there’s a hole in the wall.”

CVSS 10.0 isn’t a marketing number. It requires the maximum on every axis the scoring system measures: network-reachable, no privileges needed, no user interaction, and a complete loss of confidentiality, integrity, and availability on the affected system. The August bugs scored high too, but neither hit a perfect 10. This one does, and CISA’s KEV listing around September 8 confirms it isn’t just theoretically exploitable, someone is already using it.

The timeline, laid out

Here’s what N-able has shipped against N-central since the start of August, in order:

Cycle	CVE(s)	What it was	Severity	Fix
1	CVE-2026-18576	Authentication bypass (alternate path/channel)	High	Initial patch
2	CVE-2026-18577	Auth bypass, the gap left over when the first patch didn’t fully close it. KEV-listed Aug 3.	High	Hotfix 2026.3.1.7
3a	CVE-2026-86206, CVE-2026-86207	Chainable auth-bypass pair; lets a remote attacker create an unauthorized System Administrator account	Critical	Hotfix 3 (~Sep 5)
3b	CVE-2026-86218	Pre-auth RCE via static code injection (CWE-96)	Critical, CVSS 10.0	Hotfix 4, version 2026.3.1.14 (Sep 5)

Three cycles, roughly six weeks, and the trend line goes the wrong direction: each round has been at least as severe as the last, and the most recent one maxed out the scale. That’s the shape of a vendor still finding the edges of a hardening effort, not a one-off bad month.

Two bugs, one hotfix window, no shared cause

It’s tempting to lump CVE-2026-86206, CVE-2026-86207, and CVE-2026-86218 together because they landed in the same patch window, but researchers tracking them describe CVE-2026-86218 as independent of the other two. CVE-2026-86206 and CVE-2026-86207 are a chainable pair: exploited together, they let a remote, unauthenticated attacker create a System Administrator account with no legitimate access to start from. Stephen Fewer, a senior principal security researcher at Rapid7, found and reported them, and Huntress built a working proof-of-concept to demonstrate the chain end to end.

CVE-2026-86218 doesn’t need that account-creation step. It’s a direct code execution path. Two teams working the same product in the same season turning up two unrelated critical bugs isn’t evidence of a conspiracy, it’s evidence that N-central has had more eyes on it lately than it probably wants. That’s a reasonable side effect of three consecutive disclosures: once a product is under this kind of scrutiny, more bugs surface, related or not.

watchTowr, another firm that has looked closely at N-central’s exposure, makes the point plainly: compromising an RMM platform gives an attacker access to every computer and downstream system that platform manages. That’s not incidental risk, it’s the product working as designed, just for the wrong operator. An RMM tool’s entire value is centralized control over a fleet of endpoints, and every vulnerability in it inherits that same blast radius.

The compromise Huntress couldn’t fully explain

On September 4, 2026, Huntress investigated a customer’s N-central production environment and found it compromised, despite being fully patched at the time. That detail matters and it’s worth being precise about what it does and doesn’t mean. Huntress could not definitively confirm which exploit chain the attacker used, because logging on the N-central appliance itself was limited. It’s an honest gap in the investigation, not a confirmed link between that specific incident and CVE-2026-86218.

Two things can both be true: the incident is real and troubling, and the causal chain to any single CVE in this cluster is unproven. Report it as an open question, because that’s what it is. What it does tell you, regardless of which bug turns out to be responsible, is that “fully patched” and “not compromised” are not the same claim for N-central right now. If you have an internet-facing N-central server, patch status alone doesn’t clear you. You still need to look for signs of prior access.

What to actually look for

Across the August and September campaigns, Huntress has observed a consistent set of post-compromise behaviors, and they’re specific enough to hunt for directly rather than guessing:

• Reconnaissance targeting Domain Controllers reachable from the compromised N-central server. Attackers aren’t stopping at the RMM box, they’re using it as a launchpad into the domain.
• Cloudflare tunnels stood up for persistent access. Tunnel traffic blends into normal HTTPS egress, so it survives longer than an obvious reverse shell.
• Attacker-created accounts with “.invalid” appended to the email address. It looks like an evasion or anomaly-detection sidestep, and it’s specific enough to search your account list for right now.

If any of those show up in your logs, this stops being a patching task and becomes an incident. Call it that internally, because the two have different playbooks and starting the wrong one wastes the time you don’t have, and the real cost of getting that call wrong is a lot higher than an hour of log review.

What MSPs should do this week

Patch first. N-central 2026.3 Hotfix 4 (2026.3.1.14) is available now. If you’re on hosted N-central, N-able already applied it for you; confirm your version number in the console rather than assuming. If you’re on-premises, this is not a change-management-ticket-next-sprint item. Open the admin console today and apply it.

Then hunt, even if you patched immediately. Pull the list of administrative accounts and flag anything unfamiliar, especially anything with an “.invalid” suffix. Check remote-access session logs for activity nobody on your team started. Review outbound network connections from the N-central server for Cloudflare tunnel endpoints you didn’t provision. None of this takes more than an hour for a typical deployment, and an hour is cheap next to a client-wide breach.

Finally, treat N-central’s patch cadence as a signal about the whole RMM category, not just this one product. SimpleHelp’s supply chain bug earlier this year made the same point from a different angle: tools that sit with privileged access across your entire client base carry a shorter trust radius than tools that don’t, and their patch history deserves its own line item in your risk review, not a footnote.

Three critical disclosures in six weeks doesn’t mean N-central is uniquely broken among RMM platforms. It means the platform you’ve centralized trust in just had a rough stretch, and the honest response is to verify, not assume. Patch today, hunt this week, and put a recurring fifteen-minute check on your calendar for every privileged tool in your stack that you haven’t looked at since the last incident made you look.