Remote support: the file runs on the technician's machine

When somebody from your IT provider opens a remote session against one of your machines, what gets shared is a channel, not a screen. And a channel has two ends. Almost everything written about supplier risk assumes the danger flows downwards — they break into the provider and reach you from its console. The advisory CISA published yesterday describes the opposite direction, and the vendor itself spells it out: "ScreenConnect servers are not impacted". What is impacted are the machines support is given from.

What the advisory actually says

The ConnectWise bulletin is dated 8 September 2026 and carries one short sentence: "a condition in the ScreenConnect client may allow files to be transferred and executed through an active remote session without authorization or Host confirmation in certain circumstances". It is CVE-2026-84869, scored 9.9 with vector AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H. It is fixed in version 26.6.5. And here is the small print worth not skipping: the bulletin tells cloud customers no action is required… and then tells everybody that "after upgrading, make sure to reinstall your host clients and update your access agents". Because the flaw lives in the client, updating the server does not touch the technician's laptop.

The part that made us look twice is two lines further down, in the scope table: servers are not impacted; Host clients are. In ScreenConnect's vocabulary, the Host is whoever connects in order to help. That is, the technician's laptop. Our reading — and we flag it as ours — is that this inverts the direction everybody carries in their head: during a legitimate session, the machine that ends up executing a file nobody confirmed is not the customer's, but the one belonging to the person providing the service.

The workaround gives away the vector

When a vendor cannot hand you the patch straight away, the workaround it offers usually explains the flaw better than the advisory text does. Here the workaround is: go to Administration > Security > Roles and deselect the TransferFiles permission for session groups. No network filter helps, no firewall rule, no reboot. What gets switched off is a feature, and one of the ones used forty times a day. That was also the only defence available for five days: ConnectWise published an advisory about the file-transfer behaviour on Thursday 3 September, saying the CVE identifier and the official fix would arrive within that same week, and the patch did not land until the 8th.

The other end: two emergency patches in two days

Three days before ScreenConnect, on 8 September, CISA had added CVE-2026-86218 in N-able N-central to the same list: static code injection (CWE-96), unauthenticated remote code execution and a round 10.0. The fix is build 2026.3.1.14, published by the vendor on 6 September at 03:47. The day before, on the 5th, that same vendor had published another one: build 2026.3.1.13, closing CVE-2026-86206 (6.9) and CVE-2026-86207 (7.7), reported by Rapid7 and Huntress. Two emergency updates, on consecutive days, in the component from which an entire customer base's fleet is administered.

And it is no accident that it is the same product we wrote about on 4 August, when two consecutive authentication bypasses — the second one an incomplete patch for the first — had us explain from the inside why your IT provider's agent is attack surface. Back then the branch was on fix 2026.3.1.7. Five weeks later it is on 2026.3.1.14. We are not claiming a build number is a quality metric, because it is not; but those digits are maintenance windows somebody had to open, in the small hours, in production, without a fortnight's notice.

Two vendors, the same sentence, and CISA saying otherwise

N-able writes, about CVE-2026-86218: "we have no confirmations that this vulnerability has been exploited in production environments, but unpatched systems remain at risk". The ConnectWise bulletin, in its 8 September version, does not mention exploitation. And yet both advisories sit in CISA's KEV catalogue, which by definition lists known exploited vulnerabilities: N-central went in on the 8th with a deadline of the 11th, and ScreenConnect on the 11th with a deadline of the 14th, which is Monday.

We are not telling this to point fingers. A vendor states what its own telemetry can support, and it is honest not to overstate. We tell it because the useful signal came from somewhere else, and considerably earlier. On the N-central flaw, Arctic Wolf writes that "exploitation was observed prior to public disclosure, and independent researchers have reproduced the vulnerability". If you wait for the vendor to confirm, you act late. And the catalogue entry is not the start of the story either: since directive BOD 26-04 the required action no longer stops at "patch", it demands forensic triage — which translated means assuming you may not have got there first.

We counted them: fifteen so far in 2026

Two advisories from the same family in three days felt like a lot, so instead of opining we downloaded the file. The KEV catalogue is published as open JSON; the version we used is 2026.09.11, with 1,709 entries. Between 1 January and 11 September 2026 there are 225 additions. Of those, fifteen belong to programs whose job is governing computers that are not their own:

• N-able N-central — 3 (3 and 4 August, 8 September)
• SimpleHelp — 3 (two on 24 April, one on 29 June)
• Ivanti Endpoint Manager Mobile — 3 (29 January, 8 April, 7 May)
• ConnectWise ScreenConnect — 2 (28 April, 11 September)
• Ivanti Endpoint Manager — 1 (9 March) and BeyondTrust Remote Support / PRA — 1 (13 February)
• Microsoft Configuration Manager — 1 (12 February) and Quest KACE Systems Management Appliance — 1 (20 April)

Fifteen. Microsoft Windows, over that same period, comes to thirteen. No market-share statistic is needed to know which of the two sets is installed in more places. For comparison with last year: across the whole of 2025 that family — counting Motex's LANSCOPE Endpoint Manager as well — added up to eleven entries. We are at fifteen with three and a half months to go.

Two caveats, because without them the number misleads. First: KEV does not measure how many flaws a product has, it measures which ones CISA knows are being exploited; a heavily watched product shows up more. Second, and this is the important one: we drew the boundary of the family ourselves, so we are publishing all of it for you to argue with. Inside goes whatever administers or takes control of computers. Outside we left three things that border the category — SolarWinds Web Help Desk (three entries; it is ticketing), SolarWinds Serv-U (one; file transfer) and Ivanti Sentry (one; a gateway) — and, above all, the management planes of network gear, which are another family with the same problem: Cisco Catalyst SD-WAN Manager (four), Cisco Secure Firewall Management Center (three) and Check Point SmartConsole (one). Add those eight back and the number goes to twenty-three. The counting method is the same one we used when counting how old the catalogue's flaws really are: download the JSON and count with jq, so that anyone can redo it.

It is not that the code is worse. It is that the prize is better

The temptation is to conclude that these products are badly built. We do not believe that, and we certainly cannot prove it. What the six do have in common are three properties that, together, describe the ideal target: they concentrate privilege (one console commands the entire estate of many companies at once), they are reachable over the network because otherwise they would be useless, and they hold standing credentials for places nobody else enters without knocking. An attacker choosing where to spend their time compares blast radius.

And that is why the ScreenConnect flaw strikes us as the more interesting of the two, even if its score is a tenth lower. N-central's is the familiar story: break the concentrator, reach everybody below. The other one says that the support session — the one we open with a clear conscience because "we are the ones connecting" — can work in the opposite direction. And the technician's machine is, nearly always, the machine from which every other machine is reached. The same thing we once asked about who can switch off your servers, but looking inside our own house.

Three questions for your IT provider. Ours included

We are a managed services provider, so this is about us as much as anyone. We are not going to recommend a specific tool — switching brands does not change the category — but we will offer the questions we think are fair. If whoever serves you cannot answer them on one call, you have already learned something:

1. How long did it take you to apply the last emergency patch to your console? Not "do you patch?". The exact date of the last one, and who did it at three in the morning. If the answer starts with "well, we run the cloud version", that is a good answer: the vendor updates it and you find out afterwards. But then the next question is what happened in the meantime.
2. Are your technicians' machines managed the way mine are? After the ScreenConnect case this is no longer rhetorical. Laptops with full-disk encryption, managed EDR with somebody actually watching the console, no shared local admin accounts and no installing whatever it takes "just for this ticket".
3. What permissions does the role they connect to my company with actually carry? This week's workaround is unticking a box in a role. Which means roles exist and somebody decided how they are set. Do all technicians have file transfer and unattended access across the whole estate, or is it requested per ticket?
4. How do you know that EVERY Host client your technicians use is updated and reinstalled? This one is specific to this week's flaw and it is the one most people will get wrong. The server updates in one place; Host clients are scattered across people's laptops, and the bulletin asks for them to be reinstalled one by one. "It is in the cloud" does not answer this question.

And now the uncomfortable part, which is answering them ourselves. We do not publish which remote control console we use, and the reason is not security through obscurity, which does not work: it is that saying so turns this conversation into a brand comparison, and the brand is precisely what does not matter. What we can put in writing is the usual. Our monitoring is Zabbix with SmokePing, the network's source of truth is NetBox and internal automation runs on self-hosted n8n. None of the four is glamorous and none is a remote support console, but they all share the only thing that matters here: they are inventoried, they have an owner with a first and last name, and they have an update window, just as if they belonged to a customer. The day an internal tool drops off the inventory, what you have is a machine with authority over other machines and nobody watching it.

What this post does not fix

The two cases have to be separated, because "we have it in the cloud" works for one and not the other. With N-central it is true: the vendor patched the hosted environments and whoever sits there had nothing to do. With ScreenConnect it is not, and that is the trap in the advisory: the flaw is in the client, so the managed server is up to date while the technician's laptop keeps the old version until somebody reinstalls it by hand. The flip side, for both: the window in which the system was vulnerable did exist, somebody else managed it, and you did not see it. And the patch does not undo whatever happened before it, which is what we wrote two days ago about the Cisco patch that closes the door but does not give you back the blueprint. An honest clarification about the above: we are not claiming the ScreenConnect CVE is being exploited. What is documented is the mechanism, by a different route. In August, Huntress published three incidents at unrelated organisations — on the 20th and the 24th — in which modified ScreenConnect clients, installed through social engineering and not by exploiting any vulnerability, packed a four-stage VBScript chain into a file-transfer message; connecting to one of those clients caused the Host system to receive and execute the same chain. That required a modified client. What the vendor described in September is a condition of the normal one. And no, we are not telling you to switch tools either: we are telling you the category has an uncomfortable property, and it is worth looking at before somebody else does.

Note on sources

Everything was checked on 12 September 2026. ScreenConnect: ConnectWise's security bulletin of 8 September 2026 and its public disclosure for CVE-2026-84869 (verbatim description, 9.9 with vector CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H, versions prior to 26.6.5, "ScreenConnect servers are not impacted", Host systems impacted, and the workaround of deselecting TransferFiles under Administration > Security > Roles). N-central: N-able's notice of 6 September 2026 at 03:47 (hotfix 4, build 2026.3.1.14, CVE-2026-86218, the sentence about the absence of exploitation confirmations, and the note that cloud environments are already patched) and the one from 5 September (hotfix 3, build 2026.3.1.13, CVE-2026-86206 and CVE-2026-86207, credited to Rapid7 and Huntress). Our own count: the public JSON file of CISA's KEV catalogue, version 2026.09.11 released on 11 Sep 2026 at 19:32 UTC, 1,709 entries, downloaded with curl and counted with jq; from it come the 225 additions in 2026, the fifteen in the remote management and access family with their per-product breakdown and dates, the thirteen for Microsoft Windows over the same period, the eight network management planes we declare as excluded, the eleven in 2025, and the dates and deadlines of this week's two entries (CVE-2026-86218 added on the 8th, due the 11th; CVE-2026-84869 added on the 11th, due the 14th), plus the reference to directive BOD 26-04 and its forensic triage requirements, which appear in the required-action field itself. The CVSS scores for CVE-2026-86206 and CVE-2026-86207 come from the analysis published by Rapid7. The quote about exploitation prior to disclosure is from Arctic Wolf ("Exploitation was observed prior to public disclosure, and independent researchers have reproduced the vulnerability"). ConnectWise's earlier advisory of Thursday 3 September, announcing that the CVE and the fix would arrive that same week, is reported by SecurityWeek (7 Sep 2026). The three August incidents involving modified ScreenConnect clients (20 and 24 August, unrelated organisations, initial access via a Quick Assist tech-support scam, a phishing-delivered MSI installer and a fake refund form; a four-stage VBScript chain packaged into a file-transfer message and executed by the Host system on connection) are from Huntress, which states explicitly that they do NOT exploit CVE-2026-84869. The following is OUR reading, not the sources': that the scope declared by ConnectWise inverts the usual direction of supplier risk; that a role-permission workaround reveals the vector to be a product feature; the definition of the product family counted and its boundary, declared above along with what we left out; the comparison with Windows; and the six questions. The cover photograph is "Disassembled iMac at a computer repair service", by Ivan Radic, published on Wikimedia Commons under a Creative Commons CC BY 2.0 licence and cropped by us for the cover format.