They came in on port 5900 and left with root: the miner was the least of it

The Dutch national cyber security centre updated its NCSC-2026-0280 advisory with a short, unpleasant note, picked up by the press on 14 August: they have seen active exploitation of the macOS Screen Sharing flaw on several systems with port 5900 reachable from the internet, and in every reported case the attacker had obtained root and left a Monero miner running. Underneath the miner, which is the visible part, sits someone with root on a company machine.

Apple had already fixed it. On 6 August it shipped out-of-band macOS Tahoe 26.6.1, Sequoia 15.7.9 and Sonoma 14.8.9, with a textbook sentence: an attacker on the network may be able to authenticate to Screen Sharing without valid credentials. It did not say the flaw was being exploited, and it did not say otherwise either. A little over a week later the Dutch notice arrived, and with it the part that never appears in security notes: what kind of machines those were.

A validator that says yes when it should say no

The technical write-up published by Huntress lays the bug bare. In screensharingd, the daemon behind macOS remote desktop, the implementation of SRP — the protocol that negotiates the password without sending it — has a frame-length validator that returns a stale success status. That is all it takes: the connection is then treated as authenticated. There is no password to guess and no account that needs to exist. It is a pre-authentication flaw, which is the worst place for one to be.

After that there is no privilege escalation, because you come in at the top already. The legacy VNC authentication path leans on two privileged helpers, SSFileCopySender and SSFileCopyReceiver, which run as root along that route. And the first is not any old root: SSFileCopySender carries the kTCCServiceSystemPolicyAllFiles entitlement, which is Full Disk Access bypassing TCC, the macOS system that asks whether a given app may read a given folder. The receiver does not carry it, and Huntress notes the likely reason: the TCC bypass implications were too obvious. Arbitrary read and write, and code execution as root. With that at hand, a Monero miner is the least ambitious option on the table.

And there is a second hole in the same service, with less press: CVE-2026-43760, post-authentication, where any user who got in through the legacy VNC method can read and create any file as root. In other words, the same component fails on both sides of the door.

The usual hardening did not cover this hole

There is one sentence in the Huntress write-up that has barely been repeated and is the most important of the whole case: standard hardening — removing accounts from the allowed users list, disabling legacy VNC — does not protect against CVE-2026-65400. Whoever had done their homework was exactly as exposed as whoever had not.

And this is a pattern, not a coincidence. Almost everything we call hardening consists of limiting who can get in: fewer users, fewer methods, fewer permissions. That does not cover a bug which specifically does not need you to get in. Only yesterday we wrote about a case from the same family in OpenSSH, where locking the agent disabled the very restrictions you had placed on it: the control existed, it was correctly configured, and the bug went round it. When the control and the bug do not share a path, the control is worth nothing however well set up it is.

Screen Sharing does not come switched on. Somebody switched it on

On a standard macOS install, Screen Sharing is off. Huntress points this out with explicit relief and adds the caveat that explains the rest of the case: it comes pre-enabled on a good part of hosted Mac services, those rented Mac minis used to build applications or to keep a reference machine around.

The figure going around for how many are exposed comes from a researcher's scan — Pedro Vilaça, who publishes as @osxreverser — and is reported by The Hacker News: roughly 40,000 machines with Screen Sharing open on the internet, almost half of them in the United States. Whoever ran the scan notes that most are residential addresses, so take it for what it is: a snapshot from one scan, not a census. But in that same list there are universities, some companies and even a server belonging to the makers of BBEdit. That is where it stops being a domestic slip and becomes an old decision nobody has looked at since.

What this looks like in a mid-sized company is almost always the same, and has nothing to do with macOS: someone asks to reach their office machine from home, someone leaves the meeting-room Mac reachable to save a trip upstairs, a supplier keeps its access after the project has ended. It gets opened for a good reason, the urgency is dealt with, and the firewall rule stays there, ownerless and with no expiry date.

The list almost nobody has

Almost every company has a list of machines. Very few have the other list, which is the one that mattered here: what listens from outside, on which IP, on which port and by whose decision. The first of those inventories comes out of your estate management system; the second has to be fetched from the network edge, and it changes every time somebody touches a port forward.

It is the same thing we wrote about with the remote management agents IT providers install. Everything that exists to reach a machine from far away — an agent, a remote desktop, a tunnel — is both the convenience and the door, and it was almost always installed by someone who is no longer in the conversation.

What you can see from the endpoint, if anyone is watching

A managed detection service does a very concrete job here, and it is not the one usually sold. It does not prevent the bug: once the daemon considers you authenticated, there is nothing left to prevent. What it does is stop the intrusion being invisible while it lasts. macOS publishes Screen Sharing events through its Endpoint Security framework, and the Huntress analysis gives three signals worth turning into a rule:

A miner gives itself away: it burns CPU, it heats up and it does not stop. The trouble with a miner is that it trains you to think the attacker was after your electricity bill. With Full Disk Access, that same machine held SSH keys, browser session tokens, the keychain and whatever had synced down from the cloud. And we wrote a few days ago about ransomware families whose first move is to stop the security agent: if whoever gets in has root, having an agent installed and having an agent alive stop being the same thing. That is why it matters that someone watches the telemetry from off the machine, not just that the icon is in the menu bar.

What we would do this week

When this is not about you

If there is not a single Mac in the company, this is not your problem and we are not going to manufacture one for you. If there are Macs but none of them publish anything outward, you can wait for your usual maintenance window: the exploitation observed needs 5900 reachable from the internet. Just do not stretch it, because the Huntress timeline records proof-of-concept code published by researchers shortly after the patches in this family of bugs. And we are not going to sell you the idea that an EDR would have prevented this, because it would not: it would have made noise, and sometimes noise is all there is.

Out of the whole case, what stays with us is not the CVE. CVEs come and go, and this one has had a fix since 6 August. What stays is that the bug only did damage where there was an open port nobody remembered opening — and no security bulletin is going to warn you about that. It is a list you have to build yourself, and it expires every time somebody solves an emergency on a Friday afternoon.

Sources (verified on 17 August 2026): the update to the Dutch NCSC-2026-0280 advisory about active abuse on systems with port 5900 reachable from the internet, with root obtained and a Monero miner planted in every reported case, reported on 14 August by BleepingComputer (14 Aug 2026), Security Affairs and SC Media; the 6 August 2026 patch in macOS Tahoe 26.6.1, Sequoia 15.7.9 and Sonoma 14.8.9, Apple's wording ("an attacker on the network may be able to authenticate to Screen Sharing without valid credentials", fixed with "improved state management"), credit for the finding to Alfredo Pesoli (Bynario Atlas) and the absence of any mention of exploitation at patch time, per Apple's security note as reported by Security Affairs and 9to5Mac; the technical detail of the SRP frame-length validator returning a stale success status, the SSFileCopySender and SSFileCopyReceiver helpers running as root along that path (with the kTCCServiceSystemPolicyAllFiles entitlement on SSFileCopySender only; the receiver does not have it), CVE-2026-43760 as the post-authentication flaw, the fact that Screen Sharing is not enabled by default but is pre-enabled on many hosted Mac services, the uselessness of standard hardening against CVE-2026-65400, the timeline recording proof-of-concept code published by researchers, and the three Endpoint Security detection signals, from the Huntress analysis; the approximate figure of 40,000 machines with Screen Sharing open on the internet (almost half in the US, most of them residential addresses, with universities and some companies on the same list), from a scan by researcher Pedro Vilaça (@osxreverser) reported by The Hacker News; the two CVSS vectors and their dates (6 and 14 August 2026), from the NVD record, which explains the discrepancy with the 7.1 score published by SC Media on 14 August. Quotations translated from English are our own translations. The reading of the two inventories, the thesis that hardening and the bug do not share a path, and the checklist are ours, not the sources'.