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

UPDATE · originally covered CVE-2026-65400 — macOS Screen Sharing lets a network attacker authenticate without valid credentials, the second severe defect in the same daemon in two releases (2026-08-08)

the original entry carried Apple's own framing — an attacker on the network may be able to authenticate to Screen Sharing without valid credentials, no exploitation reported — and treated it as an authentication bypass. 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 reports achieving code execution by creating a launch daemon that runs an on-disk reverse shell at reboot or by modifying a 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 — a narrower reading than the original entry's more hopeful gloss on the protection question, since the launch-daemon and shell-startup paths are not covered by it.

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). This entry does not adjudicate between them. 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's contribution the original entry lacked is 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 strong 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. Any successful screen-sharing attach whose authentication type is the unencrypted variant, or whose session username is root or null, has no benign explanation on a managed Mac; an ordinary remote-support session by an administrator authenticates over the encrypted path as a named account. 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.