Vulnerability ManagementIncident ResponseThreat Intelligence
"Fully patched" is one of the most reassuring phrases in security operations. It is what an MSP tells a client after an advisory lands, what an IT lead writes in the incident channel, and what a board slide says in green. It is also a statement about a vendor's knowledge on a particular day, not about your exposure.
On September 4, 2026, a remote monitoring and management (RMM) server running N-able N-central was compromised. It was on the latest hotfix N-able had shipped. When Huntress went to work out how the attacker got in, the answer was not there: the logs on the server had already rotated, so nobody could say which of several vulnerabilities was used.
That one detail — not the CVSS score, not the CVE count — is the part of this story most worth taking back to your own estate.
N-central is the platform MSPs, MSSPs and large IT departments use to push scripts, install software and open remote sessions on every machine they manage. A foothold on the server is a foothold on the fleet. The sequence below is assembled from N-able's own advisories, Rapid7, Huntress and CISA:
| Date (2026) | What happened |
|---|---|
| Jul 31 | N-able notices an unusual volume of licensing errors from on-premises customers — the first sign of attack, per The Hacker News |
| Aug 1 | Exploitation of CVE-2026-18577 (CVSS 8.2) observed in the wild — an incomplete fix for an earlier authentication bypass, CVE-2026-18556, per Rapid7 |
| Aug 2 | Hotfix 1 (build 2026.3.1.7) |
| Aug 3 / Aug 5 | CISA adds CVE-2026-18577, then CVE-2026-18556, to the Known Exploited Vulnerabilities catalog |
| Aug 6 | Hotfix 2 (build 2026.3.1.10) supersedes Hotfix 1 after attackers found a variation around its checks |
| Aug 27 | Rapid7's Stephen Fewer reports two new flaws, CVE-2026-86206 and CVE-2026-86207, to N-able |
| Sep 4 | A Huntress customer's N-central server on build 2026.3.1.10 is compromised |
| Sep 5 | Hotfix 3 (build 2026.3.1.13) fixes the two Rapid7 flaws |
| Sep 6 | Hotfix 4 (build 2026.3.1.14) fixes CVE-2026-86218, a pre-authentication remote code execution flaw rated CVSS 10.0 |
| Sep 8 | CISA adds CVE-2026-86218 to KEV with a federal patch deadline of September 11; Rapid7 publishes its analysis |
| Sep 9 | N-able's advisory update says it has observed "a handful of successful exploits against N-central customers" |
Count the builds. Anyone who did everything right in August — applied Hotfix 1 within a day, then Hotfix 2 when told it was required — was running a server that was vulnerable to a pre-auth, maximum-severity zero-day by early September. The Shadowserver Foundation tracks nearly 1,500 N-central servers exposed to the internet, mostly in the United States and Europe.
The August wave shows what these footholds are for, and none of it required malware in the conventional sense.
After taking over a server, the attackers used N-central's own Take Control remote-access feature to connect to managed endpoints, then registered Cloudflare Tunnel (cloudflared) as a service so they would survive reboots. Huntress saw a single self-hosted instance used to reach nine downstream organisations, one endpoint in each. Help Net Security's roundup of what Huntress and Sophos observed adds the rest of the playbook: a new domain account named veeam, password resets on existing domain administrator accounts, additional remote-access tools, Microsoft and Sophos security software disabled with EDR-evasion tooling, and reconnaissance aimed squarely at domain controllers.
Read that list from the managed endpoint's point of view. A remote session opened by the RMM. A service installed. An account created with the name of the backup product the MSP probably also manages. Every one of those is something a legitimate technician does on an ordinary Tuesday. watchTowr, which reproduced CVE-2026-86218, made the same point about strategic value: changes made in N-central propagate to everything connected to it, which is exactly why ransomware operators want it.
The September compromise is where the story stops being about a vulnerability and starts being about evidence.
Huntress could not rule out the Rapid7 authentication-bypass chain, could not confirm CVE-2026-86218, and could not exclude something else entirely — because the N-central server's own logs had rotated before anyone looked. What Huntress could see came from the other end: records in N-central's interface, and entries in the Windows Application logs of managed endpoints showing Take Control sessions starting and stopping (Huntress points defenders at event IDs 8192 and 8193, alongside sessions attributed to an "MSP Support" user).
Huntress also reports that it first learned of CVE-2026-86218 from a post by an N-able employee in the MSPGeek Discord in the early hours of September 6, ahead of the formal advisory. And BleepingComputer noted that N-able's public advisory initially said it had no confirmation of exploitation in production, while its notice to customers described the flaw as exploited in the wild. Three days later the public advisory caught up.
There is one more thread worth pulling, carefully. N-able's August advisory lists 23.234.94.43 among its indicators. Its September advisory tells customers to review logs for scanning from 23.234.64.0/18 — a range that contains that address. Both advisories also flag the same odd artefact: newly created user accounts with .invalid appended to the email address. That is not attribution, and shared hosting ranges are common. But it is consistent with the same operator returning to the same product a month later, and it means anyone who closed an August investigation should reopen it with September's indicators.
We wrote last week about an implant that edited the traffic counters its victims were watching. That was an adversary deliberately corrupting a witness. What happened here is more mundane, and far more common.
No one needed to tamper with anything. A management server kept a finite window of local logs, as servers do, and the window closed before the investigation opened. The attacker's choice of exploit — the single most useful fact for every other N-central operator trying to scope their own exposure — was lost to ordinary log rotation.
For a tool that holds administrative reach into hundreds or thousands of other networks, the log retention setting is not a disk-space decision. It is the setting that decides whether the question how did they get in? has an answer.
If you run N-central, or an MSP runs it for you:
.invalid email addresses, unexpected administrator accounts, scanning from 23.234.64.0/18, and the August indicators N-able published.cloudflared registered as a service; svchost.exe running from a user's Documents folder; new domain accounts and domain admin password resets.To be plain about the boundary: Obiguard SOC does not patch N-central, and it does not have an N-central connector. What it addresses is the part of this incident that was lost — the evidence, and the signal that arrived before anyone knew there was a CVE.
The earliest warning in this entire saga was a volume anomaly. N-able's first indication of the August attacks was an unusual spike in licensing errors. SOC detects alerts from log volume and rule matches out of the box, without detection rules to write first — which is precisely the class of signal that shows up days before an advisory does. Logs reach SOC through an OpenTelemetry Collector, so the RMM server and the Windows endpoints it manages can forward events as they happen; once an event has left the appliance, the appliance's rotation schedule no longer decides what an investigation can see.
Legitimate tooling needs context, not signatures. A Take Control session is not malicious. A Take Control session at 03:00 into a domain controller, followed within minutes by a new service install and a new domain account, is a sequence — and in SOC's Live Logs those events sit side by side, filterable by source and full text, rather than split between an RMM console, an endpoint agent and a domain controller's event log. The analyst looking at one of those events can see the other two without opening three tools.
Triage leaves a record. Dismissing a finding in SOC requires a comment and is written to the organisation's audit log. When a client asks an MSP who looked at the unusual session into our tenant, and what did they decide?, that is an answer rather than a recollection.
One adjacent note. If your team has given an AI agent API credentials to your RMM or ticketing platform, that agent's sessions raise the same attribution question as a technician's — and that is what Governance AI and its audit ledger are for.
The MSP model works because it concentrates trust. One console, one set of credentials, reach into every client. That concentration is the product, and it is why a single N-central server gave one attacker a route into nine organisations in August.
What the last five weeks demonstrated is that the patch cycle cannot carry that trust on its own. The first fix was incomplete. The second was followed by a zero-day. The organisations that did everything the advisories asked were still exposed, and at least one of them now cannot say how. None of that is negligence on the customer's side. It is what patching looks like when the attacker is finding the next bypass faster than the vendor ships the last one.
So the question for anyone who ran N-central this summer is not are we on Hotfix 4? It is could we show, today, what our RMM did on August 1?
Explore Obiguard SOC or talk to us about keeping the evidence from your most privileged tools longer than the tools themselves do.
Obiguard sits in front of every AI request your organization makes — screening prompts and outputs against the guardrails, compliance frameworks, and audit trails that stories like this one make necessary.
See how it works →