Apple macOS Screen Sharing (screensharingd) pre-authentication improper authentication, CVSS 7.1, fixed in macOS Tahoe 26.6.1, Sequoia 15.7.9 and Sonoma 14.8.9. NCSC-NL advisory NCSC-2026-0280 revision 1.0.1 (2026-08-12) records active abuse observed on multiple systems with port 5900 reachable from the internet, root access obtained in all of them and a Monero cryptocurrency miner planted.

Apple's advisory says an attacker on the network may be able to authenticate to Screen Sharing without valid credentials. Three things published since change what a defender should do about it.

It is remote root, and the exploit is a weekend's work. Calif pulled the 26.6 and 26.6.1 binaries, diffed them, and had a working exploit against a live 26.6 machine about four hours later (Calif, 2026-08-10). The severity is higher than the advisory line implies because screensharingd, the daemon answering those connections, runs as root, so an attacker does not land in the account they authenticated as, but can reach every account on the machine and install what they like. Huntress, analysing the same patch independently, describes the result as arbitrary file read and write as root, reached through the daemon's privileged file-copy helper processes, and lists code execution through a launch daemon that runs an on-disk reverse shell at reboot or a modified shell startup file that fires when a terminal is opened (Huntress, 2026-08-07). Huntress also notes that an earlier public proof-of-concept's cron-based path did not work as implemented, because the cron location it wrote to is protected, and that its author later scoped that path to systems with System Integrity Protection disabled. The launch-daemon and shell-startup paths are not limited that way.

There were two pre-auth bugs, not one, and only one got a CVE. Calif reports that screensharingd carried two independent critical flaws sitting in the same source file. The first was found by the researcher fG! (@osxreverser), never reported to Apple, and killed by Apple in the 26.6 release of 2026-07-27 alongside less severe reported bugs; it has no CVE to this day, and none of the three Screen Sharing entries in that July advisory was described as pre-authentication (Calif, 2026-08-10). Calif characterises that first bug as a single wrong return: a length check bailing out early on an oversized frame and handing back the success code from the preceding read, which the caller reads as an authentication step having passed. The second bug is CVE-2026-65400, fixed out of band on 2026-08-06, and Calif states it needs one thing the first did not: a valid account name, which is not a secret because macOS prints usernames on the login window. Both, in Calif's account, are pure logic errors: no heap grooming, no address-space defeat, no race to win, and no crash; one or two packets in the right order.

The two accounts of the root cause do not agree, and the difference is worth knowing. Huntress roots CVE-2026-65400 in the Secure Remote Password implementation, stating that the daemon's frame-length validator erroneously returns a stale success status so the connection is treated as authenticated, and that the session then continues without cryptographic protection (Huntress, 2026-08-07). Calif assigns that same stale-return mechanism to the first, uncredited bug, and says CVE-2026-65400 is instead a state-machine desync whose details it is withholding until more machines have updated (Calif, 2026-08-10). The practical consequence of the disagreement is a defensive one: a reader who has only seen the Huntress write-up may conclude the mechanism is fully public, when the more granular account says the mechanism behind the CVE that is actually patched this month has not been published.

Exposure. Calif cites the scan by the researcher who started the affair, which found around 40,000 Macs with Screen Sharing reachable from the internet, mostly residential addresses but including university and company hosts (Calif, 2026-08-10). Huntress reports a separate concern for managed estates: providers of hosted bare-metal Macs commonly provision these services enabled, a search of internet-wide scan data shows tens of thousands of potentially vulnerable hosts, and at the time of writing some providers had not folded the latest updates into their base images, so newly provisioned hosts were still coming up on the previous, vulnerable version (Huntress, 2026-08-07).

Detection. Huntress describes a telemetry-level discriminator drawn from Apple's Endpoint Security event stream. On a screen-sharing attach event, a legitimate authenticated session reports its authentication type as RSA-SRP, while a session established through this bug reports the weaker SRP value, because no cryptography is applied to it. The session username is the second signal: root is a suspicious indicator, since that account is disabled by default on macOS and few administrators would enable it and then use it for Screen Sharing, and an attacker guessing at account names produces attach events with a null session username, noisy enumeration that is itself worth alerting on. At the process layer, execution of the daemon's file-copy sender helper with a user and group identifier of 0 and 80 accompanies information-disclosure attempts, though Huntress notes those values do not stay static once the attacker enumerates another local account.

Triage: Screen Sharing is a real administrative tool, so the session itself is not the signal; the authentication type is. Huntress ties the unencrypted variant to sessions established through the bug and calls a root session username a suspicious indicator that few administrators would produce, while an ordinary remote-support session by an administrator authenticates over the encrypted path as a named account (Huntress, 2026-08-07). Where that telemetry is unavailable, the fallback discriminator is exposure rather than behaviour: a Screen Sharing listener answering from an untrusted network at all is the condition this bug needs.

CVE-2026-65400 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 advisory's revision note for that version records that public proof-of-concept code is available and active abuse is known (NCSC-NL, 2026-08-12).

The confirmed cases fall in the exposed population set out on 2026-08-11: Macs with Screen Sharing reachable from the internet on port 5900.

Two things are worth holding steady against the temptation to escalate further. The reported outcome is a planted Monero miner, and NCSC-NL has not said whether the attacks went beyond it (BleepingComputer, 2026-08-14). That reflects what these attackers did, not 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: NCSC-NL has not shared details of the attacks beyond root access and a planted miner, so it has published no miner process name, pool infrastructure or persistence mechanism (BleepingComputer, 2026-08-14). No source says whether the confirmed cases showed the authentication-type and session-user discriminator Huntress described for the bypass it analysed (Huntress, 2026-08-07). The confirmed cases ended with a Monero miner planted after root access (NCSC-NL, 2026-08-12), so sustained high processor load on a host that accepted connections on 5900 is worth checking.

Triage: Screen Sharing sessions are ordinary on managed Mac fleets, and remote-support tooling produces them all day. The separators 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, in the bypass Huntress analysed, a session whose user is root or null (Huntress, 2026-08-07). Legitimate administrative screen sharing arrives from known internal ranges or a VPN concentrator and binds to a real operator identity. The confirmed cases were on hosts whose port 5900 was reachable from the internet (NCSC-NL, 2026-08-12).