CRITICAL: N-able N-central CVE-2026-86218 Pre-Auth RCE Under Active Attack

Pour one out for the MSPs who spent August patching N-central, because they got to do it again this weekend.

N-able released Hotfix 4 for N-central 2026.3 on September 5, closing CVE-2026-86218, a pre-authentication remote code execution flaw carrying a CVSS 4.0 base score of 10.0. That is a perfect score, the kind vendors and researchers usually argue their way down from. It is also the fourth emergency hotfix for the same product in five weeks, on a platform whose entire purpose is holding privileged agents on every endpoint its customers manage. If you run N-central on-premises and you are not on build 2026.3.1.14, stop reading and go fix that. This article will still be here in twenty minutes.

What actually broke

CVE-2026-86218 is classed as a static code injection weakness, CWE-96, which in practice means attacker-supplied input reaches somewhere it gets treated as code rather than as data. The attack requires no credentials, no user interaction, and no particular cleverness. N-able's own description is that the flaw could allow for pre-authenticated remote code execution on the N-central server, and every version prior to 2026.3.1.14 is affected.

Given that N-central is an RMM console, code execution on the server is not the end of the attack. It is the beginning of one, because that server sits upstream of agents running as SYSTEM on every managed workstation and domain controller across every client tenant. That distinction matters more than the CVSS number does. A 10.0 on a public web application is a bad day for one organization. A 10.0 on an MSP's management plane is a bad day for that MSP and every downstream customer it touches, which is exactly the shape of the Kaseya VSA incident that this industry still cites in sales meetings five years later.

Five weeks, four hotfixes

The timeline is worth walking through, because it explains why a lot of shops are patch-fatigued and behind. It started August 1 with CVE-2026-18556, followed by Hotfix 1 and build 2026.3.1.7 on August 2. That patch turned out to be incomplete, which produced CVE-2026-18577 and Hotfix 2 at build 2026.3.1.10 on August 6. Things then went quiet for roughly a month.

On September 4, Huntress detected a compromised N-central server in a customer environment. On September 5, N-able shipped Hotfix 3 at build 2026.3.1.13, addressing two access control flaws, CVE-2026-86206 rated 6.9 and CVE-2026-86207 rated 7.7, which chained together into a working authentication bypass. Within a day it became clear that Hotfix 3 did not close everything, and Hotfix 4 arrived carrying the fix for CVE-2026-86218.

Huntress reportedly learned of the pre-auth RCE not through a vendor advisory but through a Discord post by an N-able employee in the MSPGeek community. Whatever your view on disclosure etiquette, a community chat server is not the notification channel a critical RMM vulnerability deserves.

The exploitation question

N-able's public release notes state the company has no confirmations that this vulnerability has been exploited in production environments. The direct notice sent to customers said the flaw has been observed being exploited in the wild. Those two statements cannot both be comfortable, and the gap between them erodes trust faster than the bug itself does.

The honest read sits somewhere in the middle. Huntress confirmed a genuine compromise of a production N-central server, but the logs on that box had already rotated by the time investigators arrived, so nobody can say with certainty which of the four recent CVEs was the entry point. Treat that ambiguity as a reason to move faster rather than slower. When a vendor ships four hotfixes in five weeks and an incident response firm finds a backdoored console in the middle of it, the academic question of which CVE did it is not yours to solve.

What the intrusions look like

The observed activity follows a pattern familiar to anyone who has worked an RMM compromise. Attackers reach administrative access on the console, then probe the remoteControlAction endpoint using the getPierDetails method to enumerate connected devices. From there they create accounts, and the tell is oddly specific, because the fraudulent users have been created with .invalid appended to the email address. If you find a console user whose address ends in .invalid, you are not looking at a typo.

After that, operators have used the built-in MSP Support default account to open Take Control remote sessions, requested process listings from managed hosts, and moved deliberately toward domain controllers rather than wandering the estate at random. Persistence has come from deploying cloudflared as a service, occasionally masquerading under an svchost.exe filename, which yields outbound tunneling that most egress filters wave through because the traffic terminates at Cloudflare.

Infrastructure seen in these intrusions includes 173.249.252.200, 87.249.138.34, 37.19.210.32, 68.235.46.214, 37.153.90.88, 92.118.112.181, 185.156.46.150, 23.234.94.43 and several neighbors in the 23.234.x range associated with Tzulo VPN. Domains have leaned on consumer dynamic DNS, including mousears.synology.me and two quickconnect.to hosts. At least one Cloudflare tunnel has been tracked under the tag 5568cd69c754b392121f1dbb8f900fda.

Patch, then go looking

Patching is the first move and it is not optional. On-premises customers need N-central 2026.3 HF4 at build 2026.3.1.14. Cloud-hosted instances were updated by N-able directly, though verifying your build rather than assuming it is good practice regardless.

The second move is assuming you may already be a victim, because the flaw was exploited before the fix existed and applying a patch evicts nobody. Audit every user account in the console and hunt for anything created recently, anything you cannot map to a real human being, and anything carrying that .invalid suffix. On the server side, the logs worth pulling are envoy_proxy_HTTPS.log, the ncentraldms syslog, and ui_access_control.log, where you want sessions originating from the addresses above alongside URL-encoded oddities in API paths, particularly stray %2F sequences used to slip past path handling.

On managed Windows endpoints, look inside C:\ProgramData\GetSupportService_N-Central\Logs\ at the BASupSrvc archives and correlate their timestamps against remote control sessions nobody scheduled. Windows Application event IDs 4102, 8192 and 8193 record remote control activity and are a fast way to spot a session that ran at three in the morning against a domain controller. Then hunt for cloudflared on any system that has no business running it.

The exposure numbers argue for urgency. Shadowserver tracks roughly 1,500 internet-facing N-central servers, concentrated in the United States and Europe. Back in early August, when the first two CVEs landed, about 13.6 percent of reachable servers were still unpatched, and among self-hosted deployments specifically that figure sat at 28.6 percent. Prior N-able flaws, CVE-2025-8875 and CVE-2025-8876, already earned places on CISA's Known Exploited Vulnerabilities catalog, so the product has history and attackers know it.

The larger lesson is that management planes deserve to be treated as crown jewels rather than as plumbing. An N-central console has no business answering requests from the open internet without a VPN or an identity-aware proxy standing in front of it, and the fact that roughly 1,500 of them accept unauthenticated connections from anywhere on earth is the real root cause here. CVE-2026-86218 will be patched and forgotten by October. The architectural decision to expose the console is what produces the next one.

The business angle

Every MSP that got paged this weekend just lived through the argument for patch management as a billable, SLA-backed service rather than a checkbox on a stack diagram, and clients who watched their provider scramble are unusually receptive to that conversation right now. Package the response you just performed, emergency patching plus account auditing plus IOC sweeps, as a retained incident readiness offering instead of absorbing it as unpaid weekend labor.

There is also a straightforward compromise assessment engagement waiting for anyone running N-central, because patching never answers the question of whether someone was already inside. Selling a one-time hunt across console logs and endpoint telemetry is an easy yes for a client who just read a headline with the words CVSS 10.0 in it, and that engagement reliably surfaces the segmentation and egress filtering gaps that turn into the next project.