CISA added the N-central pre-authentication remote code execution flaw to the Known Exploited Vulnerabilities catalog on September 8, 2026 with a September 11 due date, while N-able’s status page still says there are no confirmations of exploitation and N-able’s blog says the opposite.
What happened
On Tuesday, September 8, 2026, CISA added CVE-2026-86218 to the Known Exploited Vulnerabilities catalog. NVD’s record was rebuilt at 7:28 p.m. UTC the same day and now carries CISA’s fields verbatim: cisaExploitAdd of 2026-09-08, cisaActionDue of 2026-09-11, and the catalog name “N-able N-central Static Code Injection Vulnerability.” Federal civilian agencies have until Friday, September 11, 2026. The required action reads:
“Apply mitigations in accordance with vendor instructions, ensuring compliance with CISA’s BOD 26-04 Prioritizing Security Updates Based on Risk (see URL in Notes) guidance and CISA’s “Forensics Triage Requirements” (see URL in Notes). Follow applicable BOD 26-04 guidance for cloud services or discontinue use of the product if mitigations are unavailable. Stakeholders are responsible for evaluating each asset’s internet exposure and ensuring adherence to BOD 26-04 patching guidelines.”
Severity Daily covered the flaw on September 6, when N-able shipped its second N-central hotfix in two days and the newer build fixed a 10.0 that the older one did not. That story recorded that the CVE carried no KEV listing and no federal deadline, and that NVD had not analyzed the record. Both of those facts changed on September 8.
The record’s vulnStatus moved from Received to Analyzed, and NVD attached a configurations block where there had been none. It is worth reading, because it states the hotfix problem in machine-readable form. Five CPE entries are marked vulnerable: cpe:2.3:a:n-able:n-central:*:*:*:*:*:*:*:* with versionEndExcluding of 2026.3, then 2026.3 itself, then 2026.3:hotfix1, 2026.3:hotfix2, and 2026.3:hotfix3. NVD is saying that base 2026.3 and its first three hotfixes are all affected. Only build 2026.3.1.14 — Hotfix 4 — is not on the list.
That matters because N-able told on-premises customers on September 5, 2026 to install Hotfix 3 “immediately.” Anyone who did exactly what the vendor asked, on the day it was asked, is inside CISA’s affected set.
The vendor’s two answers
N-able has published two statements about CVE-2026-86218 that do not agree, and both are still live.
The release-note entry on status.n-able.com, dated September 6, 2026 at 3:47 a.m., announcing build 2026.3.1.14, says: “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 it says: “At this time, we have no confirmations that this vulnerability has been exploited in production environments, but unpatched systems remain at risk.”
The customer-facing post on n-able.com, dated September 6, 2026 at 4:30 a.m. UTC and last updated September 7, 2026 at 1:49 p.m. UTC, separates the two disclosures. Of the earlier pair, CVE-2026-86206 and CVE-2026-86207, it says: “At this time, we have no confirmations that the vulnerabilities have been exploited.” Of CVE-2026-86218 it says the reverse — that this is “a new vulnerability— one that has been exploited in the wild and is unrelated to the previously disclosed CVEs.” The same post tells customers already on HF3: “You’ll still need to upgrade to HF4 to be protected against this newly discovered vulnerability.” For hosted instances it says: “No action needed on your end; your instance has already been patched.”
So the vendor’s blog says exploited in the wild, and the vendor’s release notes say no confirmations, forty-three minutes apart, and the release-note wording has not been corrected in the three days since. CISA has now taken one side of that by listing the CVE as known exploited.
What the published exploitation evidence actually is
The public technical basis is a Huntress writeup, last updated September 6, 2026. Huntress states: “As of publication, Huntress has seen exploitation impacting one organization in our customer base.” One organization. Its investigation began September 4, 2026, on what it describes as a fully patched N-central production environment. It publishes indicators — two Tzulo VPN nodes, 23.234.100[.]105 and 23.234.97[.]68, a Cloudflare tunnel account tag 5568cd69c754b392121f1dbb8f900fda, and detection guidance covering .invalid appended to account names and a pattern of API endpoint probing.
It also publishes a limitation, and it is the important sentence: “due to limited historical logging available directly on the appliance, we cannot definitively confirm which specific exploit the threat actor used.”
Why it matters
Three days is the shortest remediation band CISA operates, and it arrives here on top of a vendor record that has been contradicting itself since Sunday. An agency reading its own sources on September 8 finds a release note saying no confirmed exploitation and a catalog entry saying known exploited. Both are current. The catalog wins on obligation, but the disagreement is not resolved anywhere a customer can see, and N-able has had three days to align them.
The evidentiary picture underneath deserves stating plainly rather than being flattened into “actively exploited.” The published, inspectable exploitation account is single-vendor, its scale is one customer environment, and the researcher who found it says it cannot confirm which exploit was used against that environment. None of that means the KEV listing is wrong — CISA does not publish its evidence, and it may hold more than Huntress does. It means the reader should not repeat “widespread exploitation” on the strength of what is currently public, because what is currently public is one organization and an honest caveat.
The CPE list is the operationally useful part of this update, and it is new. Until September 8 the record had no configurations block at all, which is why the HF3 problem could only be found by reading N-able’s prose. Now a vulnerability scanner that consumes NVD data can distinguish 2026.3:hotfix3 from 2026.3.1.14 without anybody reading a release note. That is the whole argument for structured records, and it took two days past disclosure to arrive — on a flaw with a three-day clock.
N-central is remote monitoring and management software, which sets the blast radius. An MSP appliance holds agent deployment rights across every client it manages, so a pre-authentication code-execution flaw on the server is a path to every downstream network at once. That is the reason a 10.0 in this product class is not the same 10.0 as a 10.0 in a single-tenant application, and it is the reason the forensic-triage half of the required action is not paperwork. The question an N-central operator has to answer this week is not only whether the box is on HF4; it is whether anything was done through it before HF4 existed.
Note also which asset class drew the short clock. CISA added four entries on September 8. The two Windows local privilege escalations rated 7.8 carry a cisaActionDue of 2026-09-22. This one and the Adobe Commerce flaw, both remotely reachable code execution rated 10.0, carry 2026-09-11 and the forensic-triage language. That is an observation about what CISA assigned, not a derivation of the rule: BOD 26-04’s authoritative mapping from its four variables to its four deadline bands is published only as untagged PNG images in Appendix A, and public transcriptions of that table disagree with one another.
What to do
On-premises N-central operators should be on 2026.3 HF4, build 2026.3.1.14. HF1, HF2, and HF3 are all listed as vulnerable in NVD’s analysis, and HF3 in particular is the trap, because it was the build N-able told customers to install immediately one day earlier. N-able says hosted instances are already patched.
Do not treat the upgrade as the end of it. Check against the Huntress indicators — the two listed IP addresses, the Cloudflare tunnel account tag, account names with .invalid appended, and unexpected probing of API endpoints — and check back to at least early September rather than to the date you patched. Because N-central holds credentials and deployment rights into managed environments, an appliance that shows any of those markers is a downstream investigation, not just a server rebuild.
Federal civilian agencies have until September 11, 2026, and the required action names the forensic-triage obligation alongside the patch.
Sourcing note
KEV dates and required-action text come from NVD’s record for CVE-2026-86218, which republishes CISA’s fields verbatim; lastModified is 2026-09-08T19:28:43.390 and vulnStatus is Analyzed. This record is a live example of the stale-copy hazard: three retrievals of it this evening returned three different lastModified values, and the two taken from a bare ?cveId= URL showed no CISA fields at all. The values above are from the retrievals that returned the September 8 copy, confirmed twice.
cisa.gov returns 403 to automated fetching from this container, so the catalog JSON and the September 8 alert page could not be read directly; the per-CVE dates here are from NVD and not from any press report. Vendor statements were read at status.n-able.com and n-able.com. The Huntress writeup was read directly. Help Net Security, on September 7, 2026, also reported the contradiction between N-able’s two statements; that is coverage, and the quotations above are taken from N-able’s own pages.
Unresolved: N-able has not corrected or explained the release-note sentence, and gives no date for when exploitation was first observed. The HF4 release timestamp is reported inconsistently — N-able’s blog URL and Help Net Security place it on September 5, 2026, while both N-able pages are stamped in the small hours of September 6 — which is consistent with a US evening release crossing into the next UTC day, but the company has not stated a release time.