Apple macOS Screen Sharing — attacker on the network can authenticate without valid credentials; authentication-state issue fixed in macOS 26.6.1 / 15.7.9 / 14.8.9

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.