N-able's fourth N-central hotfix in five weeks fixes a pre-authentication remote code execution bug rated a perfect 10.0. Whether it's already been used against customers depends on which N-able page you read.

N-able shipped a fourth hotfix for its N-central remote monitoring and management platform on September 6, 2026 — the third distinct set of vulnerabilities patched in just over a month. This one is the worst of the bunch on paper: a pre-authentication remote code execution flaw, tracked as CVE-2026-86218, that carries the maximum possible CVSS score of 10.0.[1]

What makes this release notable isn't only the score. It's that N-able's own communications can't agree on whether anyone has actually used the bug yet.

What happened

Every on-premises N-central build below version 2026.3.1.14 needs the new hotfix — including servers that had already applied Hotfix 3 (2026.3.1.13) barely a day earlier.[2] N-able says hosted N-central (NCOD) customers were patched automatically and don't need to do anything.[2] On-premises administrators are told to upgrade immediately, with supported paths from 2025.4, 2026.1, 2026.2, 2026.3, and each of the 2026.3.1 hotfixes.[3] Agents don't need to be upgraded separately to be protected.[3]

The vulnerability was reported to N-able through its security disclosure program by a third-party researcher.[2] That's the normal, boring path most CVEs take. What happened after disclosure is where things get less normal.

What the vulnerability actually is

N-able's own hotfix notice describes CVE-2026-86218 as a vulnerability that "could allow for pre-authenticated remote code execution on the N-central server."[2] In plain terms: an attacker wouldn't need a valid login, a stolen token, or any prior foothold to potentially run code on the appliance. That's about as bad as an RMM vulnerability gets, since N-central sits at the center of an MSP's access to every managed customer endpoint.[4]

N-able assigned it a CVSS score of 10.0 — the ceiling of the scale — and Huntress, the security firm that first flagged the new hotfix publicly, independently confirmed the score was the highest of the three CVE sets patched across the five-week run.[1] I wasn't able to independently verify a specific CWE classification or full CVSS vector string for this CVE from a rendered vendor advisory page, so this article doesn't assert one. What's confirmed is the severity rating itself and the pre-auth RCE description, both stated directly by N-able and echoed by Huntress.[1][2]

Where N-able's story splits

This is the part worth slowing down for, because it's not a small discrepancy.

N-able's Hotfix 4 release notes and its documentation site both state plainly: "At this time, we have no confirmations that this vulnerability has been exploited in production environments."[2][3] That's a specific, careful claim — no confirmed exploitation.

But N-able's own incident notice on its uptime status page says something different. According to Huntress, which reviewed the notice directly and also quoted a member of N-able's team describing the same flaw in a public support forum, the incident page states the vulnerability "has been observed being exploited in the wild."[1] Huntress quotes an N-able staffer, Jason Murphy, telling partners that a third researcher "alerted us to a new vulnerability that has been exploited in the wild" and separately calling it "a zero day."[1]

So within N-able's own channels, you get two different answers to the same question depending on which page you're reading. Neither statement says who observed the exploitation, when, or against how many customers — and N-able hasn't attributed any activity to a specific threat actor.[1]

Huntress, for its part, says it can't settle the question either. The firm began investigating on September 4 after a customer's already-patched N-central production environment was compromised. It reproduced a working proof-of-concept exploit chain against build 2026.3.1.10 that may involve one or both of the flaws fixed in Hotfix 3 — but the appliance's logs had already rotated by the time Huntress got access, so it says it's "unable to say whether this new CVE was the vulnerability exploited" in that specific case.[1] In other words, there's a real compromise on record, a real PoC that reproduces it, and still no clean line connecting that incident to CVE-2026-86218 specifically.

That's a genuinely uncertain situation, not a settled one. Until N-able publishes something more specific — timestamps, indicators, or a direct statement reconciling the two pages — the honest position is that active exploitation of CVE-2026-86218 is claimed by the vendor in one place and explicitly denied in another, and third-party researchers can't independently confirm it either way.

The pattern behind this hotfix

Hotfix 4 is the fourth N-able has shipped for the 2026.3 line since August 2, and it addresses the third distinct set of vulnerabilities in that stretch:[5]

• Hotfix 1 (2026.3.1.7), August 2 — CVE-2026-18577, an incomplete fix for an earlier flaw (CVE-2026-18556) that still allowed authentication bypass and account takeover. This one was confirmed exploited, and CISA added it to its Known Exploited Vulnerabilities catalog on August 3 with a CVSS score of 8.2 as rated by N-able.[6]
• Hotfix 2 (2026.3.1.10), August 6 — additional hardening for the same attack path, not a new CVE.[1]
• Hotfix 3 (2026.3.1.13), September 5 — two new flaws, unauthorized access to internal APIs through the access control filter and a related authentication bypass in internal-only APIs, which N-able says had no confirmed exploitation.[5]
• Hotfix 4 (2026.3.1.14), September 6 — CVE-2026-86218, the pre-auth RCE covered here.[2]

The August incident is the one with the clearest paper trail. N-able has said attackers used the original authentication bypass to gain administrative access to N-central servers, then abused the platform's built-in Take Control feature to reach managed endpoints and register Cloudflare tunnel services for persistence — meaning access survived even after the initial N-central route was closed.[1] Huntress's telemetry from that campaign showed attackers running reconnaissance against domain controllers, pulling process lists, and moving across multiple hosts within an affected organization shortly after gaining access.[1]

It's also not N-central's first rodeo with in-the-wild attacks. In August 2025, two other N-central flaws, CVE-2025-8875 and CVE-2025-8876, were added to CISA's KEV catalog the same day N-able shipped fixes for them.[7] Two summers in a row now, the same product has drawn active exploitation close to when patches became available — whether that reflects attacker interest specifically in N-central, or the broader trend of RMM platforms being high-value targets because of the downstream access they provide, is a fair question the public record doesn't fully answer yet.

What N-central administrators should actually do

Regardless of which of N-able's exploitation statements turns out to be more current, the practical guidance doesn't really change:

• Patch to 2026.3.1.14 now, even if you already applied Hotfix 3. Hotfix 3 does not protect against this vulnerability — N-able and Huntress both say the build has to move to HF4 specifically.[2][1]
• Restrict inbound access to the N-central console. Huntress recommends IP allowlisting or a VPN requirement, and for servers that are still reachable from the open internet, considering taking them offline until the hotfix is applied.[1]
• Audit N-central user accounts for anything unexpected. This is the one piece of detection guidance N-able has published across the recent releases — there are no indicators of compromise or interim mitigation beyond it for CVE-2026-86218 specifically.[2][3]
• Don't assume hosted (NCOD) means "no action." That's accurate for this particular fix, since N-able says hosted instances were patched automatically,[2] but it's worth confirming your instance type rather than assuming.

None of this changes based on whether active exploitation is eventually confirmed. A maximum-severity, unauthenticated RCE in a platform with administrative reach into every managed endpoint is worth treating as urgent on its own terms, independent of whether anyone has pulled the trigger on it yet.

Security takeaway

The technical fix here is straightforward: patch to 2026.3.1.14. The harder part is that N-able's own public communications don't agree on the thing customers most need to know to prioritize their response — whether this is theoretical risk or an active attack. That kind of internal inconsistency isn't unique to N-able, but it's a useful reminder for anyone reading vendor security advisories: different pages from the same company, published around the same time, can say genuinely different things, and it's worth checking more than one before deciding how urgently to move.

Sources & References

1. Huntress. "Rapid Response: Critical N-able N-central Vulnerability and Active Exploitation." Updated September 6, 2026. huntress.com/blog/n-able-vulnerability-exploitation
2. N-able Status. "N-central 2026.3 Hotfix 4 – CVE-2026-86218." September 6, 2026. status.n-able.com
3. N-able Documentation. "2026.3 HF4 Release Notes." Last updated September 5, 2026. documentation.n-able.com
4. The Hacker News. "N-able Issues Fourth N-central Hotfix in Five Weeks for Unauthenticated RCE Flaw." September 7, 2026. thehackernews.com
5. N-able Status. "N-central 2026.3 Hotfix 3 – CVE-2026-86206 and CVE-2026-86207." September 5, 2026. status.n-able.com
6. The Hacker News. "CISA Adds Exploited N-able N-central Flaw to KEV Catalog." August 2026. thehackernews.com
7. The Hacker News. "CISA Adds Two N-able N-central Flaws to KEV." August 2025. thehackernews.com