N-central CVE-2026-86218: CVSS 10 Pre-Auth RCE

What is CVE-2026-86218?

It is a static code injection (CWE-96) in the N-central server, the remote monitoring and management (RMM) platform used by managed service providers (MSPs). N-able gives it a CVSS 4.0 score of 10.0, and NIST a CVSS 3.1 score of 9.8. No authentication is required. watchTowr reproduced the flaw and notes that changes made in N-central can propagate to all connected systems.

Which versions are affected and what is the fix?

N-central versions before 2026.3.1.14 are affected. The fix is Hotfix 4 for version 2026.3, released September 5, 2026, which supersedes Hotfix 3. Hotfix 3 does not cover this flaw. N-able has already patched its hosted environments; self-hosted deployments must be upgraded manually. The fix does not require upgrading the agents installed on endpoints.

Were there real attacks?

The evidence is split. An urgent N-able customer notice says the flaw "has been observed being exploited." The public advisory says it has no confirmation of exploitation in production. CISA listed the CVE in KEV on September 8, which signals active exploitation under its criteria.

Huntress investigated the compromise, on September 4, 2026, of a customer's production N-central environment that was otherwise up to date before Hotfix 4. With limited logging on the appliance, Huntress cannot say whether CVE-2026-86218 was the cause or rule out other flaws. Two other vulnerabilities, CVE-2026-86206 and CVE-2026-86207 (reported by Rapid7's Stephen Fewer), can be chained to bypass authentication and create a system administrator account. They are fixed by Hotfix 3.

This is the second major N-central episode in a short time: see our article on the CVE-2026-18577 authentication bypass.

Why do RMM platforms attract attackers so consistently? They hold privileged credentials, run code on every managed endpoint and are trusted by security tools, so one compromise reaches many organizations at once. That is why a single server flaw at a provider becomes a multi-customer incident.

How do you detect an N-central compromise?

The short answer: look for accounts and actions nobody requested, on the server and downstream.

• Unknown administrator accounts, recently created ones, unexplained role elevations.
• Server access logs: abnormal requests to the web interface before the patch date, from unexpected addresses.
• Modified deployment scripts and tasks, new automations, unusual remote-control sessions.
• Unexpected outbound connections from the appliance, tunnels or remote-access tools you did not deploy.
• Managed endpoints: mass command executions or software installs across the fleet in a single window.

N-able recommends reviewing server access logs before upgrading and restricting access to the management interface from untrusted networks.

What should you do right now?

1. Apply Hotfix 4 (build 2026.3.1.14) on every instance, including those you manage for customers.
2. Take the admin interface off the internet: access through a VPN or an allowlist.
3. If the instance was exposed before September 5, investigate before concluding: updating does not remove an administrator account the attacker created.
4. Rotate secrets stored in the platform (domain credentials, automation passwords, API tokens).
5. Centralize console logs into a SIEM with enough retention. The Huntress investigation shows what their absence costs.

What changes when an AI agent has access to a console like N-central?

An AI agent connected to an RMM has a mass lever: it can run scripts on hundreds of machines. If its rights are too broad, or if an attacker takes over the console, that lever becomes the attack vector. Four points deserve review.

Credentials in the agent's context. An agent that automates support or remediation often holds a console API token with wide rights. That token sits in its context or in its tool configuration. Compromising the server, or injecting an instruction into what the agent reads, opens the whole fleet.

Automatic actions without approval. An agent allowed to launch a deployment script across the fleet runs whatever the model proposes. An indirect prompt injection planted in a support ticket or an email can push it to run a command at scale. See our page on prompt injection.

The attacker-created admin account is also a user for the agent. If the agent trusts the console's user list or scheduled tasks, an account or task forged by the attacker can enter the agent's workflow and be treated as legitimate.

An agent as post-exploitation tooling. Agents installed on endpoints can be hijacked for reconnaissance and lateral movement, as described in our article on the Hermes agent in post-exploitation.

The defenses resemble those of privileged access: one token per task with minimal scope, a closed list of actions the agent may trigger, human approval for any fleet-wide action, tool-call logs tied to an identity, and monitoring of account creation. The risk maps to LLM06 (Excessive Agency) in the OWASP Top 10 for LLM Applications. See also our page on AI agent security.

How do you test your exposure?

List the admin consoles your agents can call, the tokens they hold and the bulk actions they can launch. Our Agent Red Team Express (EUR 1,900, 5 days) attacks a real agent with its tools: indirect injection, token abuse and unapproved actions, with reproducible evidence at the end.