Screen Sharing is one of those macOS features that's been sitting in System Settings for so long most people forget it's a full VNC server, listening on TCP port 5900 the moment it's switched on. That familiarity is part of why CVE-2026-65400 is worth paying attention to: it's not an exotic zero-click chain, it's a straightforward authentication bypass in a feature a lot of Mac fleets have had enabled and forgotten about for years. BleepingComputer's reporting and Tech Times' coverage both trace the same chain: a Mac with Screen Sharing reachable from the internet, root obtained with no credentials, a Monero miner dropped on the box.
A stale success state, not a stolen password
The bug lives in screensharingd, the daemon behind macOS's remote desktop feature, in its implementation of the Secure Remote Password protocol used to authenticate a connection. A faulty frame-length validation path in that implementation can return a stale success state - the service ends up treating a connection as authenticated before any real authentication has taken place. There's no password to guess or steal, because the flawed logic never actually checks one properly in the vulnerable code path. Once past that gate, the attacker isn't landing in a limited user session; Screen Sharing on macOS runs with the privileges needed to grant full remote control, which here translated directly to root.
A quiet patch, then a much louder correction
Apple fixed the flaw on 6 August in macOS Tahoe 26.6.1, and in the parallel Sequoia 15.7.9 and Sonoma 14.8.9 security updates, rating it 7.1 on CVSS at the time - serious, but not top-tier. CISA carried that same score in its initial assessment. That changed on 14 August, when CISA revised the rating up to 9.8 after Netherlands' NCSC confirmed the flaw was being actively exploited on internet-facing systems, with the assessment updated to reflect no privileges required and full system compromise as the outcome. The eight days in between are the part worth sitting with: the technical facts of the bug didn't change between 6 and 14 August, but the working assumption about who was using it, and how, did - and that's exactly the kind of gap a purely CVSS-driven patch queue can miss.
Monero mining is the visible symptom, not the whole risk
A crypto miner is a strange thing to find reassuring, but in a way it is: it's loud, it burns CPU, and it tends to get noticed - which is arguably how this campaign came to light at all. Root access obtained through an authentication bypass doesn't have to be spent on mining. It's the same access a more patient attacker would use to install a backdoor, harvest credentials cached on the machine, or pivot into whatever network that Mac sits on - all without the fan noise that gave this particular campaign away. Halfteck covered a related pattern only weeks ago when an AI-discovered macOS flaw nearly got lost in Apple's own bug bounty triage; the lesson here is the mirror image of that one - severity assessed in isolation, before real-world exploitation data exists, can be wrong in either direction.
- Update immediately to macOS Tahoe 26.6.1, Sequoia 15.7.9, or Sonoma 14.8.9, whichever applies to your fleet.
- Confirm Screen Sharing is disabled on any Mac that doesn't need it: System Settings → General → Sharing → Screen Sharing.
- Check firewall and router configurations to ensure TCP port 5900 is not reachable from the internet on any managed device.
- Where remote access to a Mac is genuinely needed, use a VPN or SSH tunnel rather than exposing Screen Sharing directly.
- If a Mac has had port 5900 exposed at any point since early August, check for unexpected CPU load and unfamiliar processes consistent with cryptomining activity, not just for the miner itself.
A feature nobody thinks about is still a feature that's listening. If you'd like help auditing which services are quietly exposed across your endpoint estate, email sales@halfteck.com.