CVE-2026-86218: The Third N-able N-central Attack Wave in Six Weeks

By Salman Khan, OSCP+, Founder of XHack, SRT (Synack Red Team member)

Read this in 30 seconds: CVE-2026-86218 is a maximum-severity, CVSS 10.0 pre-authentication remote code execution flaw in N-able N-central, the remote monitoring and management (RMM) platform thousands of MSPs use to administer client networks. It’s a static code injection bug, CWE-96, patched September 6, 2026 as Hotfix 4, and it’s the third distinct N-central attack wave since August 1.

N-able says it has no evidence of CVE-2026-86218 exploitation specifically, but Huntress reports observing exploitation attempts across all three waves in customer environments, and has documented at least one full compromise: attackers logging in through a default “MSP Support” account, targeting domain controllers, and standing up Cloudflare tunnels for persistent access. Roughly 1,500 N-central servers sit exposed to the internet. If your MSP or IT team runs N-central, patch to 2026.3.1.14 today, this isn’t a single bug, it’s the third chance attackers have had at the same platform in a month and a half.

A vulnerability in your antivirus is bad. A vulnerability in the tool that manages every one of your clients’ networks is a different category of bad. That’s what makes N-central’s last six weeks worth tracking closely even if your organization patched the moment each hotfix shipped. RMM platforms exist specifically to give one operator god-mode reach across many downstream networks at once, which is exactly why they’re such a disproportionately valuable target, and exactly why N-central has now been hit three separate times.

What CVE-2026-86218 Actually Is

N-able classifies CVE-2026-86218 as CWE-96, static code injection, rated a maximum CVSS 10.0. Static code injection happens when attacker-controlled input reaches a code path the application interprets and executes directly, rather than treating it as inert data. In N-central’s case, an unauthenticated HTTP request reaches exactly that kind of vulnerable path, letting an attacker run arbitrary operating system commands under the N-central server’s own process identity, no account, no prior access, no reconnaissance beyond finding the open web port.

That’s as bad as a single CVE gets: zero authentication, full code execution, on the server that has administrative reach into every endpoint it manages.

The Three-Wave Timeline

This is the part that should change how seriously your team treats the patch cycle, because CVE-2026-86218 isn’t an isolated event, it’s the third distinct N-central security wave in six weeks.

Aug 1-2   CVE-2026-18556  Authentication bypass, Hotfix 1 (2026.3.1.7)
Aug 6     CVE-2026-18577  Incomplete-patch bypass of CVE-2026-18556
                           Hotfix 2 (2026.3.1.10), later added to CISA KEV
Sept 5    CVE-2026-86206  Access-control filter bypass, internal API access
          CVE-2026-86207  Auth bypass enabling unauthorized admin creation
                           Hotfix 3 shipped same day
Sept 6    CVE-2026-86218  Pre-auth RCE, CVSS 10.0, static code injection
                           Hotfix 4 (2026.3.1.14), supersedes all prior fixes

Wave one was an authentication bypass that needed a second patch because the first one didn’t fully close it. Wave two chained an access-control bypass with an authentication flaw to let an attacker create their own administrator account. Wave three removed the need for authentication entirely. That’s not three unrelated bugs, it’s an escalating pattern against the same platform, and Huntress has confirmed observing exploitation attempts across all three waves in real customer environments, not just lab conditions.

What Real Exploitation Actually Looked Like

N-able states it has no evidence of CVE-2026-86218 specifically being exploited in production yet. Huntress’s own incident data tells a more concrete story about how attackers used the earlier waves, and it’s worth understanding because the pattern will likely repeat against this latest flaw.

In one confirmed compromise, attackers connected through N-central using the platform’s default “MSP Support” account, the kind of built-in credential that’s easy to overlook when hardening a deployment. Windows Event Logs on affected endpoints, event IDs 4102, 8192, and 8193, showed unauthorized remote-control sessions initiating. The attackers moved deliberately, targeting domain controllers specifically before disconnecting, and ran process enumeration to map what they’d landed on. Take Control session logs were left behind in C:\ProgramData\GetSupportService_N-Central\Logs\.

For persistence, attackers stood up Cloudflare-based tunnels, a technique that dresses malicious command-and-control traffic up as ordinary encrypted traffic to a legitimate CDN, making it far less likely to trip a naive network-monitoring rule. Once inside, the access N-central grants is the whole point of the compromise: unauthenticated, administrator-level control of the RMM console itself, sufficient to push scripts, jobs, and open remote sessions across every downstream endpoint the instance manages.

Known indicators from this campaign:

IPs:      173.249.252.200, 87.249.138.34, 37.19.210.32,
          23.234.100.105, 23.234.97.68
Domains:  mousears.synology.me
          wagoosh.direct.quickconnect.to
Tunnel:   Cloudflare tunnel tag 5568cd69c754b392121f1dbb8f900fda
Logs:     C:\ProgramData\GetSupportService_N-Central\Logs\
Events:   Windows Event IDs 4102, 8192, 8193

Why an RMM Compromise Is Worse Than a Normal Server Breach

An ordinary server compromise gets an attacker that server. An RMM platform compromise gets them every network the platform administers, which for N-central specifically means every client an MSP serves through it. That’s the entire value proposition of remote monitoring and management software turned against its own operators: one login grants reach across dozens or hundreds of otherwise-unrelated organizations at once.

Shadowserver data cited in coverage of this vulnerability puts roughly 1,500 N-central servers directly reachable from the internet right now. Every one of those is a potential single point of failure for however many downstream client networks it manages, exactly the same blast-radius math that made SolarWinds’ 2020 compromise a watershed incident rather than just another breach.

Who’s Affected and What’s Patched

All N-central builds before 2026.3.1.14 are affected by CVE-2026-86218, both on-premises and previously cloud-hosted (NCOD) deployments, though N-able states hosted NCOD instances have already been patched on customers’ behalf. On-premises operators need to apply Hotfix 4 (2026.3.1.14) directly, with upgrade paths available from multiple prior versions. Agents deployed to managed endpoints do not need separate upgrades to be protected from this specific CVE, only the N-central server itself.

As of early August data, 13.6% of reachable N-central servers remained unpatched against the earlier waves overall, rising to 28.6% among self-hosted, internet-reachable instances, a meaningful chunk of the exposed population that had three separate opportunities to patch and hadn’t fully closed the gap even before this latest, most severe flaw.

What To Do Right Now

1. Patch to 2026.3.1.14 immediately if you run N-central on-premises. This supersedes Hotfixes 1 through 3, so a single upgrade closes all three waves at once if you’ve fallen behind on any of them.
2. Disable or rotate the default “MSP Support” account if it’s still active in your deployment. That’s the specific credential Huntress observed being used in a confirmed compromise.
3. Hunt for the IOCs above across every N-central deployment you operate, the IPs, domains, Cloudflare tunnel tag, and the Take Control log path, regardless of whether you believe you were exploited via CVE-2026-86218 specifically or an earlier wave.
4. Check Windows Event IDs 4102, 8192, and 8193 on endpoints managed through N-central for unauthorized remote-control session indicators.
5. Review outbound Cloudflare tunnel traffic from your N-central server and any endpoint it manages. That’s the persistence mechanism observed in real compromises tied to this platform.
6. Don’t treat “no evidence of exploitation” as “not urgent.” N-able’s own statement covers CVE-2026-86218 specifically, not the platform’s exploitation history overall, and Huntress’s data shows real attackers already treating N-central as a repeat target.

How XHack Approaches Management-Plane Software Like N-central

Brand note: a standard vulnerability scan checks whether your RMM platform is running a patched version and calls it done. That misses the actual risk calculation, which is what an attacker reaches once they’re inside your management plane, not just whether the version number is current.

The XHack AI agent maps the downstream blast radius of management-plane software specifically, what credentials, endpoints, and client networks a compromised RMM instance can actually touch, because that’s the number that matters when the software in question exists to administer other people’s infrastructure. For MSPs and IT teams running centralized management tools, human-led VAPT tests exactly this kind of single-point-of-failure risk, and XHack doesn’t store your findings on our servers either, your engagement data stays local and fully deletable by you.

FAQ: CVE-2026-86218 Questions Answered

What is CVE-2026-86218?

CVE-2026-86218 is a maximum-severity, CVSS 10.0 static code injection vulnerability in N-able N-central that allows unauthenticated attackers to execute arbitrary code on the N-central server. It was patched September 6, 2026, as Hotfix 4 (version 2026.3.1.14), and it’s the third distinct N-central vulnerability wave disclosed since August 1, 2026.

Is CVE-2026-86218 being actively exploited?

N-able states it has no evidence of CVE-2026-86218 specifically being exploited in production environments. However, Huntress has reported observing exploitation attempts across all three N-central vulnerability waves this year in real customer environments, including at least one confirmed full compromise tied to the earlier authentication-bypass flaws.

Why is a vulnerability in RMM software more dangerous than a typical server bug?

Because an RMM platform like N-central exists specifically to give one operator administrative reach across many downstream client networks at once. Compromising the RMM server itself can grant an attacker the ability to push scripts, jobs, and remote sessions to every endpoint it manages, turning one breach into a multi-organization incident, the same blast-radius pattern seen in the 2020 SolarWinds compromise.

How do I know if my N-central deployment has been compromised?

Check for connections from the known indicator IPs (173.249.252.200, 87.249.138.34, 37.19.210.32, 23.234.100.105, 23.234.97.68), review Windows Event IDs 4102, 8192, and 8193 on managed endpoints for unauthorized remote-control sessions, inspect C:\ProgramData\GetSupportService_N-Central\Logs\ for Take Control session logs, and look for outbound Cloudflare tunnels, particularly one tagged 5568cd69c754b392121f1dbb8f900fda.

What should I do if I can’t patch N-central immediately?

At minimum, disable or rotate the default “MSP Support” account, since that’s the specific credential observed being abused in a confirmed compromise, and restrict internet exposure of the N-central web interface to the smallest possible set of trusted management IPs while you schedule the Hotfix 4 upgrade.

The Bottom Line

CVE-2026-86218 caps off the third N-central attack wave in six weeks, and each wave escalated rather than repeated: authentication bypass, then admin-account creation, then unauthenticated remote code execution with a perfect CVSS score. With roughly 1,500 servers still reachable from the internet and confirmed real-world exploitation of the earlier waves already on record, this isn’t the moment to patch and move on. Rotate the default accounts, hunt the IOCs, and treat your RMM platform’s security posture as the single point of failure it actually is for every network it touches.