2026-08-08 · view entry permalink →
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
Apple's 2026-08-06 updates for macOS Tahoe 26.6.1, Sequoia 15.7.9 and Sonoma 14.8.9 fix CVE-2026-65400 in Screen Sharing, the VNC-based remote-desktop service built into macOS. Apple's description of the impact is unusually direct for a first-party bulletin: "An attacker on the network may be able to authenticate to Screen Sharing without valid credentials", with the cause given as "An authentication issue was addressed with improved state management" (Apple, 2026-08-06). NCSC-NL carried it to European constituents the following day, classing it CWE-287 (NCSC-NL, 2026-08-07). Apple publishes no severity score and reports no exploitation.
Taken alone this is a straightforward patch item on a client operating system. What raises it is the interval. One week earlier, macOS reverse-engineer fG! published an account of a separate defect in the same screensharingd daemon: a pre-authentication bug that lets an unauthenticated caller "download any file from a vulnerable macOS machine" given its full path, with /etc/sudoers offered as the worked example. He states "I know the bug was fixed by the DoS entry" in the preceding Apple bulletin, and argues that entry understates what the bug actually was (fG!, 2026-07-29). He is explicit that this is not the bug the other research team reported. That characterisation is his and Apple has not endorsed it, so it is context rather than a finding.
The operational consequence does not depend on adjudicating that dispute. Two independent, severe authentication and state-handling defects have now surfaced in the same daemon across consecutive release cycles, one of them described publicly in enough detail to be actionable. An estate that took 26.6 and deferred 26.6.1, or that reads bulletin severity labels as a patch-prioritisation input, ends up with the wrong picture in both directions.
Detection concept and hardening are the same lever: Screen Sharing listens on TCP/5900 and is discoverable over mDNS, so the exposure to hunt for is any managed Mac with the service reachable from a segment it does not need to serve, inventory it from network telemetry rather than from configuration policy, because the setting is per-device and users enable it. There is no known persistent artifact specific to CVE-2026-65400: Apple frames it as an authentication-state defect, not a post-exploitation primitive, so a successful attack looks like a legitimate Screen Sharing session, and the discriminator available is the session's source rather than anything about the session itself. Where the service is genuinely required, restrict it to a defined set of management sources or a VPN path. On the related daemon bug fG! is precise about the limits of the platform's own controls, and the limits cut both ways: he records that it "doesn't care about TCC either", but also that "It would be perfect if it could bypass SIP. That one it doesn't do" (fG!, 2026-07-29), so System Integrity Protection does constrain that particular chain, and the file-download primitive it describes is a read, not a write.
An attacker on the network may be able to authenticate to Screen Sharing without valid credentials
An authentication issue was addressed with improved state management.
screensharingd, the program answering those connections, runs as root, the account that can do anything, so an attacker did not stop at your account. They could breach every other account on the machine and install whatever they wanted.
Where the first bug is a stale return value, the second is a state machine desync. Anybody could probably reproduce it from the patch now, but we are withholding the details until more people have upgraded.
The daemon's frame-length validator erroneously returns a stale success status, so the connection is treated as authenticated.
As this is a pre-auth bug, the usual hardening does not help: removing allowed user accounts, disabling legacy VNC password authentication, or rotating the VNC password have no effect.
Het NCSC heeft een melding ontvangen waaruit blijkt dat er actief misbruik van deze kwetbaarheid is waargenomen op meerdere systemen waarop poort 5900 vanaf het internet bereikbaar was.
In al deze gevallen was root toegang verkregen op het getroffen systeem en een Monero crypto miner geplaatst.
Publieke PoC code beschikbaar en actief misbruik bekend
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.
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.