On Saturday 6 September 2026, N-able released N-central 2026.3.1.14 as an emergency patch for CVE-2026-86218: a CVSS 10.0 pre-authentication remote code execution flaw in on-premises deployments.
It was the fourth hotfix in five weeks, and it landed one day after the third.
Five weeks, four hotfixes
| Date | Build | Fixed |
|---|---|---|
| 2 August | 2026.3.1.7 | CVE-2026-18577 — an incomplete fix for an authentication bypass, exploited in the wild |
| 6 August | 2026.3.1.10 | additional hardening on the same attack path |
| 5 September | 2026.3.1.13 | CVE-2026-86206 and CVE-2026-86207 — API access control and authentication bypass |
| 6 September | 2026.3.1.14 | CVE-2026-86218 — pre-authentication RCE, 10.0 |
The chain begins with an incomplete fix. It ends, a day after the previous emergency patch, with a perfect-score pre-auth RCE.
If you patched on 5 September and closed the ticket, you are not patched. We have been here before with this product; on N-central, treat any hotfix as an increment rather than a conclusion.
The two statements, and how it resolved
For two days this was a vendor contradicting itself.
N-able's release notes and status post said there were "no confirmations that this vulnerability has been exploited in production environments". N-able's incident notice said the flaw "has been observed being exploited in the wild". Same company, same CVE, same week, and no explanation of which was current.
On 8 September it resolved, in favour of the worse statement. CISA added CVE-2026-86218 to the Known Exploited Vulnerabilities catalogue, with a patching deadline of 11 September for federal civilian agencies — three days, which is the shortest end of what CISA issues. N-able's own urgent customer notice now says the flaw "has been observed being exploited in the wild" and that the company is "actively investigating this matter and have taken additional steps to help protect customer environments".
So the advice in the earlier version of this article — that with the vendor's documents disagreeing you should act on the worse one — turned out to be the right call. That is not a boast. It is the general rule: when a vendor says two things, the expensive assumption is the safe one, because the cost of being wrong is asymmetric.
Still nobody can say which flaw was used
The one thing that has not resolved is the intrusion itself.
Huntress investigated an N-central environment compromised on 4 September that was up to date with the patches available at the time. It still cannot say whether CVE-2026-86218 or the earlier CVE-2026-86206 and CVE-2026-86207 were used, and it explains why in a sentence worth quoting:
Due to limited historical logging available directly on the appliance, we cannot definitively confirm which specific exploit
An appliance that manages other people's infrastructure does not keep enough of its own history for anyone to reconstruct what happened on it. That is a product decision, not an accident, and it is the reason four patched CVEs in five weeks cannot be sorted into "the one that got used" and "the rest".
Why 1,500 is the wrong number to look at
The Shadowserver Foundation tracks roughly 1,500 internet-exposed N-central servers, mostly in the United States and Europe.
Fifteen hundred sounds small. It is the wrong unit.
N-central is remote monitoring and management software — what a managed service provider uses to reach into every one of its customers' estates, to deploy agents, run scripts, push software and take remote sessions. One N-central server is not one organisation. It is one MSP and everybody that MSP manages, typically dozens to hundreds of businesses that have never heard the product's name.
A pre-auth RCE there does not get an attacker onto a server. It gets them the tool built to run code on everyone else's machines, with the credentials and the agent estate already in place.
The intrusion nobody can attribute
N-able has described an intrusion beginning 31 July in which "a limited number of customers were affected". No count has been published.
And in the compromise Huntress examined, the vector could not be established. That is the whole incident-response problem in one clause: with four candidate flaws patched in five weeks, working out which door was used requires evidence that nobody had retained.
What to do
- Confirm the running build is 2026.3.1.14. Not "we patched last week". Check the version, not the change ticket.
- Assume compromise if you were exposed. Exploitation is confirmed and CISA's federal deadline was 11 September. If your N-central was internet-facing and unpatched at any point since 31 July, hunt rather than assume.
- If you are an MSP customer, ask your provider today which build their N-central is on and when it was applied. You are downstream of a box you do not control.
- Take the N-central web interface off the public internet. Roughly 1,500 organisations have not, and no configuration of this product requires it.
- Extend log retention on management infrastructure before you need it. The reason nobody can attribute the September compromise is a retention setting somebody accepted by default.
- Assume agent-side actions are in scope. The question is not only what happened on the server, but what it told the agents to do.
What is not established
- Who is exploiting it. Confirmed exploitation, no named actor.
- What the vector was in the 4 September compromise. Huntress says its data cannot answer it.
- How many customers were affected by the 31 July intrusion. "A limited number" is the only figure given.
- How many of the 1,500 exposed servers are unpatched, as opposed to merely visible.
- Whether 2026.3.1.14 is the end of it. Three of the previous four were not.
