The agent we install on your machines is also a door

On 3 August, CISA added CVE-2026-18577 to its exploited-vulnerabilities catalogue with a deadline of the 6th. It is a flaw in N-central, the console many IT providers use to manage their customers' machines. If you do not use that product, the temptation is to move on. Do not: if you have an IT provider, you have an agent of theirs running with privileges on every one of your machines. We install one. This post is about that, and it is not comfortable to write.

Four days, in order

Four days of timeline explain the rest. On 31 July, N-able spots "an uptick in licensing issues" among customers running N-central on their own premises, and puts its engineering and security teams on it. On 1 August, CVE-2026-18556 is published: an authentication bypass using an alternate path (CWE-288) affecting N-central through version 2026.1, already fixed in 2026.2. On 2 August, CVE-2026-18577 is published, and the NIST description fits on one line: "an incomplete patch for CVE-2026-18556 allows for authentication bypass and account takeover in N-central versions through 2026.3.1". Same score, 8.2 on CVSS 4.0. On 3 August, CISA adds it to the KEV with a deadline of 6 August. The fix is hotfix 2026.3.1.7.

The starting point is the most honest part of the whole story: the first thing anyone saw was not a security alert. It was licensing errors. Everything points to somebody being inside enough consoles that the licence counter started returning odd numbers — the vendor has not explained the exact link — and that was the signal. Not an EDR, not a SIEM, not a tip-off from anyone: the accounting.

And the scale belongs on the table before we go on, because it is what stops this being the story of one unlucky vendor. A fleet-management console does not administer one company: it administers those of all of a provider's customers at once. Whoever gets in there has not entered one network; they have entered every network that provider looks after. That concentration is exactly what makes the model viable — it is the reason having somebody external maintain your machines pays off — and it is also why attacking it is worth so much. We live off that concentration, so what follows is not written from the stands.

No malware needed. They used the product

According to the vendor's own account, after the authentication bypass the attacker used the Take Control feature — the remote control the product ships with — to connect to machines inside the managed environment. Huntress, watching the incident from inside its own customers, adds the detail: the sessions came from the default "MSP Support" account and left traces in Windows events 4102, 8192 and 8193. From there, high-level reconnaissance looking for key servers — "typically domain controllers" — and fast lateral movement across hosts.

And then the move that separates an opportunist from somebody who knows what they are doing. Quoting the vendor directly: "once on those devices, the attackers registered a new service for a CloudFlare tunnel, enabling persistence into an environment after access to the N-central server was revoked". Translated: they anticipated being locked out of the console and opened their own exit first. The indicators published are alarmingly modest: a service called Cloudflared — which is a legitimate Cloudflare tool — and a file named svchost.exe in a user's Documents folder, that is, a binary impersonating the name of a Windows process. And one figure worth giving even though it weakens the headline: Huntress says that, as of its latest update, it has seen neither of the two in its telemetry.

That is the pattern: the management tool doing exactly its job, under new ownership. An antivirus has nothing to flag when the remote session is opened by legitimate management software — signed, installed by the provider, allow-listed in every policy. It is the same reason we once wrote that patching is not cleaning: closing the way in does not evict whoever is already inside, and here the tunnel was put there precisely to outlive the closing.

The patch was not the end either

The KEV entry says it without decoration: this flaw "is the result of an incomplete patch for CVE-2026-18556". Which means the organisation that did its homework — saw the advisory, applied the fix, closed the ticket — stayed exposed anyway, and the gap between one and the other was not months: it was days. That a patch may not close what it claims to close is something we have already covered here and we will not rehearse the argument; what is new sits in CISA's own entry: the required action does not stop at "apply the patch", it points to the forensics triage requirements of its BOD 26-04 directive. That is the regulator stating in writing that updating does not close the case. "Patched" is not a state: it is the date you last looked.

The number that separates hosted from self-hosted

Huntress kept publishing the share of N-central servers it can reach through its own telemetry — that of its partners and customers, not a census of the global estate — that were still unpatched. One day's progression tells a whole story. At 00:45 ET on 3 August: 55.6% of the vendor-hosted cloud servers Huntress could see, unpatched. Thirteen and a half hours later, at 14:15: nearly all the cloud ones were current, the overall unpatched figure had dropped to 13.6%… and self-hosted was still at 28.6%.

Let us say what that figure means even though it does not entirely flatter us: in this specific incident, whoever had the console hosted by the vendor won hands down. Within hours their console was patched without anybody on their team having to wake up. Whoever ran it in-house — usually for good reasons: control, data, integrations — depended on a person reading an email on a Sunday. We run our own infrastructure and we argue that some workloads belong on-premises; that does not stop us acknowledging that for the management plane, the vendor's automatic update is a real, measurable advantage, and here it got measured.

The caveat, so as not to oversell the other side: that same automation means the vendor decides when your console gets touched. Neither option is free. What is not defensible is the third one, which is the usual one: running it in-house and patching it whenever you get round to it.

This is not about one vendor

It would be easy to close the post with "what a product". Easy and false. That same product was already in CISA's catalogue almost exactly a year ago: CVE-2025-8875 and CVE-2025-8876, both added on 13 August 2025. Two summers, three entries in the catalogue. That is not bad luck: it is what happens to anything that concentrates a lot of privilege over a lot of people. Manual telephone exchanges had exactly the same design problem: whoever worked the jacks could listen in on any conversation in town. That was no failing of the people doing the job, it was the topology. A century later the topology is identical and the jacks are a web console.

And the underlying trend has been measured. This year's Verizon breach report puts two figures side by side that describe this case exactly: 48% of breaches now involve a third party, 60% more than the year before; and 31% start with the exploitation of a vulnerability, the first time in nineteen years of the report that this vector has overtaken stolen credentials. A flaw in the software of a third party that manages you is both at once. This is no longer a textbook scenario: it is the busiest square on the board.

The uncomfortable part: we are that third party

We maintain IT fleets, and genuinely maintaining a fleet requires being able to reach it: an agent with privileges on every machine, inventory, patch deployment and remote control. There is no lightweight version of that. Anyone who tells you they manage your machines without privileged access to your machines either does not manage them or is not telling you the whole story.

The easy conclusion would be "get rid of the agent, then". That is worse. An unmanaged fleet is exactly what we described when writing about exposed BMCs that belong to nobody: privileged machines, no owner, no inventory and nobody updating them. Between a managed fleet with a concentrated, known risk and an unmanaged fleet with the risk scattered and invisible, the first defends itself better. But better, not by itself.

What we are not going to write is that our tooling is impregnable. Nobody who works in this field can sign that sentence with a straight face. What can be promised is what happens the day it fails, and that can be demanded in writing — from us and from anyone else.

Six things you can demand from your provider

• That the console is not sitting bare on the internet. If self-hosted, behind a VPN or with an allow-list of source addresses. If it is the vendor's cloud, with SSO and mandatory second factor for everyone, no "temporary" exceptions.
• That the vendor's default accounts have an owner or do not exist. The "MSP Support" account in this case is the perfect example: one that ships from the factory, that nobody created and that therefore nobody watches.
• That remote control leaves a log and that you can read it. Who connected, to which machine, when and for how long. If that exists but only the provider can see it, it is a log for the provider, not for you.
• That a cut-off path exists which does not depend on the provider. How that access gets revoked in one afternoon if needed. With the caveat this case teaches: cutting the console is not enough if somebody has already opened their own tunnel from inside; the cut has to come with a review of services and outbound connections on the machines.
• That detection lives on the machines, not just in the console. What gives this kind of incident away is not a file: it is a remote session at four in the morning, a new service, a hop towards a domain controller from a machine that had never touched one.
• That the provider commits to telling you, with a deadline. This is no longer just good manners: it is what the NIS2 transposition pushes down the supplier chain by contract. If your provider finds out on a Friday that its console was open, you should know on the Friday.

The question that actually works

Do not ask "is your management system secure?". Nobody is going to say no, and the answer tells you nothing. The question that works is dull and specific: "show me the last thirty remote sessions on my machines, with user, host, date and duration".

If it arrives within the hour, in a format that existed before you asked for it, there is an operation behind it. If it takes three days and comes hand-written in the body of an email, you already have the answer to the first question. And if you have no external provider because you run it in-house, the question is exactly the same — you just ask it of yourself.

We make our living from that privilege. The least we can do is not pretend it does not exist.

Sources (verified): CVE-2026-18577 added to the exploited-vulnerabilities catalogue on 03 Aug 2026, due 06 Aug 2026, flaw name and the phrase "the result of an incomplete patch for CVE-2026-18556"; earlier entries CVE-2025-8875 and CVE-2025-8876 added on 13 Aug 2025: CISA, Known Exploited Vulnerabilities Catalog. Descriptions, publication dates (01 and 02 Aug 2026), CWE-288 and the 8.2 CVSS 4.0 score for both CVEs: NVD. The rise in licensing issues on 31 Jul 2026, the use of Take Control, the direct quote about the CloudFlare tunnel, the indicators (Cloudflared, svchost.exe in Documents), affected versions and hotfix 2026.3.1.7: Help Net Security, 03 Aug 2026 and SecurityWeek, 03 Aug 2026. The "MSP Support" account, Windows events 4102/8192/8193, reconnaissance towards domain controllers and the unpatched-server percentages (55.6% at 00:45 ET; 13.6% overall and 28.6% of self-hosted at 14:15 ET on 03 Aug 2026): Huntress. 48% of breaches involving a third party (+60% year on year) and 31% starting with vulnerability exploitation, ahead of stolen credentials for the first time in 19 years of the report: Verizon, Data Breach Investigations Report 2026. The criteria, the reading of the case and the opinions are ours.