CVE-2026-65400 (macOS Screen Sharing) crosses into confirmed exploitation — NCSC-NL reports root obtained and a Monero miner planted on multiple systems with port 5900 reachable from the internet

UPDATE · originally covered UPDATE — CVE-2026-65400 is remote root, not just an auth bypass: two independent pre-auth bugs sat in screensharingd, working exploits were rebuilt from the patch in four hours, and the two research accounts disagree on which mechanism the CVE names (2026-08-11)

the flaw this pipeline reported twice as carrying no confirmed exploitation — first on Apple's advisory line alone, then on 2026-08-11 with the finding that the daemon runs as root and that working exploits had been rebuilt from the patch diff in about four hours — is now confirmed to be exploited. The Dutch national cyber security centre revised advisory NCSC-2026-0280 on 2026-08-12 to state that it had received a notification showing active abuse of the vulnerability observed on multiple systems where port 5900 was reachable from the internet, and that in all of those cases root access was obtained on the affected system and a Monero cryptocurrency miner was planted (NCSC-NL, 2026-08-12). The revision note the advisory carries for that version — that public proof-of-concept code is available and active abuse is known — ties the escalation directly to the public exploit work the 2026-08-11 entry described (NCSC-NL, 2026-08-12).

This closes the gap the prior entry left open. That entry set out the exposure — a pre-authentication path to root in a daemon that answers on 5900, exploits reconstructed from the binary diff within hours, a researcher scan finding roughly 40,000 Macs with Screen Sharing reachable from the internet, and hosted bare-metal Mac providers that had not folded the fix into their provisioning images — and could only say that no exploitation had been confirmed. It now has been, against exactly that population: internet-reachable port 5900.

Two things are worth holding steady against the temptation to escalate further. The observed outcome is cryptomining, not data theft or ransomware — which says something about who moved first, not about what the primitive permits, since the same pre-auth root gets an operator anything they want on the host. And the remediation has not changed: the fixed builds are macOS 26.6.1, Sequoia 15.7.9 and Sonoma 14.8.9, the same ones named on 2026-08-08 (BleepingComputer, 2026-08-14). Where an update cannot be applied immediately, disabling Screen Sharing in System Settings where it is not needed remains the vendor-path control (BleepingComputer, 2026-08-14).

Detection: neither source discloses a miner process name, pool infrastructure or persistence mechanism, so there is no artifact to hunt for beyond the generic. What does carry over is the sourced telemetry discriminator from the 2026-08-11 entry — a successful Screen Sharing attach whose authentication type is the weaker of the two the protocol offers, or whose session user resolves to root or to no user at all — which was a concern about a proof-of-concept when it was written and is now a description of activity someone has actually performed. On the outcome side, a Mac sustaining high processor load from a process with no corresponding user session, on a host that accepts connections on 5900, is the shape the confirmed cases took.

Triage: Screen Sharing sessions are ordinary on managed Mac fleets, and remote-support tooling produces them all day. The separators here are reachability and identity rather than the connection itself: a session sourced from outside the corporate network to a host whose 5900 listener is internet-facing, and a session that authenticates without resolving to a named user account. Legitimate administrative screen sharing arrives from known internal ranges or a VPN concentrator and binds to a real operator identity; neither holds for the confirmed cases, where the whole point of the flaw is authenticating without valid credentials.