N-able told on-premises N-central customers to install Hotfix 3 immediately on September 5, 2026. The next day it published a CVSS 10.0 pre-authentication remote code execution flaw that only Hotfix 4 fixes.
What happened
On September 5, 2026, N-able shipped N-central 2026.3 HF3, build 2026.3.1.13, alongside two CVE records, and told self-hosted customers they “should upgrade to N-central 2026.3 HF3 immediately to protect their environment.” Severity Daily covered that release, and the gap between its prose and its own CVSS vectors, the same day.
A day later the same channel carried the same instruction with a different build number in it. N-central 2026.3 HF4, build 2026.3.1.14, fixes CVE-2026-86218, which N-able scores at CVSS 10.0. HF3 does not fix it.
The CVE record reached NVD carrying a published value of 2026-09-06T03:17:17.373, and its lastModified field holds the same timestamp, meaning nothing has touched the record since it landed. Its vulnStatus is Received: NVD has not analyzed it. The description reads in full, and the missing sentence break is in the record as published: “N-central is vulnerable to a pre-auth remote code execution This issue affects N-central: before 2026.3.1.14.”
N-able is the CNA. The vector it assigned is CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:H/VA:H/SC:H/SI:H/SA:H, for a base score of 10.0, Critical. The weakness is CWE-96, static code injection. Across two retrievals of the NVD record using different URL forms, the record carries no cisaExploitAdd, no cisaActionDue, no cisaVulnerabilityName, and no cisaRequiredAction. There is no KEV listing and no federal deadline. It also carries no configurations block, so there is no CPE to match against.
The advisory URL the CVE record cites, on me.n-able.com, returns a JavaScript application shell and a CSS error to a non-browser client; no advisory text is retrievable there. Two other N-able hosts carry the release and render as readable text. The 2026.3 HF4 release notes on documentation.n-able.com and the release-note entry on status.n-able.com both say: “This hotfix includes security fixes for CVE-2026-86218 which is a critical-CVSS-rated vulnerability that could allow for pre-authenticated remote code execution on the N-central server.”
On exploitation, N-able says: “At this time, we have no confirmations that this vulnerability has been exploited in production environments, but unpatched systems remain at risk.” That is the same sentence it used for the HF3 pair a day earlier, with the plural changed to a singular.
On who has to act, the guidance splits by deployment. For hosted customers: “If you are on an N-central hosted instance (NCOD), patches have already been applied to your environment.” For everyone else: “Customers running on-premises N-central deployments should upgrade to N-central 2026.3 HF4 immediately to protect their environment.” On the endpoint side, N-able adds that “the hotfix itself does not require agents to be upgraded to protect you from CVE-2026-86218,” while still recommending current agents as general practice. The hotfix installs directly from 2025.4, 2026.1, 2026.2, 2026.3, and from any of the 2026.3 hotfixes, HF1 through HF3.
The two N-able hosts do not agree on when HF4 shipped. The release-notes page dates the build 05-Sep-2026. The status page dates its HF4 entry September 6, 2026, one day after its HF3 entry. Both are N-able’s own publications, and neither is obviously authoritative over the other.
Why it matters
An administrator who did exactly what N-able asked on Friday is not finished. HF3’s release note used the word “immediately.” HF4’s release note uses it again, one build later, for something strictly worse. The population most likely to be caught by this is the one that responded fastest to the first instruction, because it is the population that has already recorded the work as done.
The scoring difference between the two releases is the whole shape of the problem. Yesterday’s pair topped out at 7.7, and the higher-scored of the two carried PR:L and AT:P — the attacker needs an account and conditions outside their control. Today’s record is AC:L, AT:N, PR:N, UI:N. Nothing is required of the attacker except the ability to reach the server.
The second half of the vector is the part worth reading slowly. In CVSS 4.0 the subsequent-system metrics, SC, SI, and SA, describe impact on systems beyond the vulnerable component itself. N-able set all three to High. That is the vendor’s own scoring judgment, not an observation of anything in the field, and it should be read as such. But an RMM platform is a piece of software whose entire purpose is administrative reach into other people’s machines, and a vendor scoring subsequent-system impact at High on its own RMM server is making a statement about where a compromise of that server ends up. It does not end at the server.
This also arrives on a product with a recent exploitation history. CVE-2026-18577, described in its record as “An incomplete patch for CVE-2026-18556 allows for authentication bypass and account takeover in N-central Versions through 2026.3.1,” was added to CISA’s Known Exploited Vulnerabilities catalog with a cisaExploitAdd of 2026-08-03 and a cisaActionDue of 2026-08-06 — a three-day clock. Its cisaRequiredAction reads: “Apply mitigations in accordance with vendor instructions, ensuring compliance with CISA’s BOD 26-04 Prioritizing Security Updates Based on Risk guidance and CISA’s Forensics Triage Requirements. Follow applicable BOD 26-04 guidance for cloud services or discontinue use of the product if mitigations are unavailable.” N-central operators went through a federal emergency on this product five weeks ago, and for a good number of them HF1 was the answer. HF1 is now three hotfixes behind.
Then there is the version arithmetic, which is easy to get wrong in exactly the direction that hurts. Build 2026.3.1.13 is a security fix and a vulnerable build at the same time. A change record reading “patched N-central, September 5” is a true statement about the wrong flaw. Two emergency hotfixes in two days from the same release line also breaks the assumption underneath most patch cadences: an organization that batches upgrades weekly cannot get to a correct state by picking up the latest build on its normal schedule, because the latest build changed midweek and the release before it was itself sold as urgent.
The record state compounds it. With vulnStatus at Received and no configurations block, a 10.0 pre-authentication remote code execution flaw currently has no CPE. Any inventory tool that identifies affected software by matching CPE strings will return nothing for this CVE, and will keep returning nothing until NVD analyzes the record. That is not unusual for a record hours old, and it is the third N-central record in two days in the same state. Detection here has to be a build-number check, not a scanner result.
On mechanism, the record says CWE-96 and nothing else, and neither N-able page says more than “pre-authenticated remote code execution.” Static code injection describes attacker-controlled input written into something later executed as code, typically a template or a configuration file. That is as far as the public record goes, and it is not far enough to build a detection signature from.
What to do
On-premises N-central: upgrade to build 2026.3.1.14, HF4. HF3 is not sufficient, and neither is any earlier hotfix. The upgrade installs directly from 2025.4, 2026.1, 2026.2, 2026.3, and HF1 through HF3, so there is no intermediate step for anyone on a 2026 line. Verify the running build number afterward rather than trusting the change ticket, and do not expect a vulnerability scanner to flag this: query the build.
Hosted instances: N-able says NCOD environments are already patched. Confirm the build shown in the interface anyway.
Agents do not need to be upgraded to close this specific flaw, per N-able, so agent rollout scheduling is not a reason to delay the server upgrade.
Given a pre-authentication flaw at 10.0 on a product that was under confirmed attack in August, treat an internet-reachable N-central console as a standing exposure independent of this CVE. Restrict administrative access to known networks or a VPN where the deployment allows it, and review authentication logs across the window since HF3 shipped. There is no vendor indicator-of-compromise guidance for CVE-2026-86218 and no published detection, so log review is general rather than targeted.
Sourcing note
Checked: NVD records for CVE-2026-86218, CVE-2026-86206, CVE-2026-86207, and CVE-2026-18577 through the NVD API, with the 86218 record retrieved twice using different URL forms to confirm the absence of the CISA fields and the configurations block; the N-central 2026.3 HF4 release notes on documentation.n-able.com; and the N-central 2026.3 Hotfix 4 entry on status.n-able.com. Quotations of N-able’s language are taken from those two pages, which carry it identically.
Could not reach: the advisory page at me.n-able.com that the CVE record cites as its reference, which returns a JavaScript shell with no advisory text to a non-browser client. Statements here about what N-able has published are therefore based on the two readable N-able hosts, not on the cited advisory. CISA’s Known Exploited Vulnerabilities catalog feed returns 403 to automated fetching; the KEV dates for CVE-2026-18577 are taken from NVD’s republication of CISA’s own fields, which is the standing practice on this site.
Unresolved: N-able’s two hosts give different dates for the HF4 build, 05-Sep-2026 on the release-notes page and September 6, 2026 on the status page, and this story does not pick between them. The technical nature of CVE-2026-86218 beyond CWE-96 is not public. Whether the flaw was introduced in a specific release is not stated; the affected range is expressed as everything below 2026.3.1.14. No exploitation has been confirmed by N-able or by any third party as of publication.