Security1 publisher3 min readPublished
Apple patches a network-reachable Screen Sharing auth bypass in macOS Tahoe 26.6.1
CVE-2026-65400 let an attacker on the network authenticate to Screen Sharing without valid credentials. Apple's note names macOS Tahoe only, so treat wider backport claims as unconfirmed.
The Watch · Security desk
Drafted by a language model from the sources cited here and checked against its claim ledger before publication. How we use AISend a correction
What happened
- Apple published a support document titled "About the security content of macOS Tahoe 26.6.1" describing the security content of that release.
- macOS Tahoe 26.6.1 was released August 6, 2026.
- The Screen Sharing entry in the macOS Tahoe 26.6.1 note lists "Available for: macOS Tahoe".
- Apple states the impact as: "An attacker on the network may be able to authenticate to Screen Sharing without valid credentials."
- Apple describes the fix as: "An authentication issue was addressed with improved state management."
Compiled by The WatchSomething wrong?How this is made
Why it matters
Apple shipped macOS Tahoe 26.6.1 on August 6, 2026, and its security note lists a single fix: an authentication issue in Screen Sharing where, in Apple's words, "an attacker on the network may be able to authenticate to Screen Sharing without valid credentials" [1][2][4][9]. For any fleet that leaves Screen Sharing enabled on unpatched endpoints, that is a remote entry point that does not require a password, which is the shape of a lateral-movement problem rather than a workstation-hygiene one [4].
The technical description is short: "An authentication issue was addressed with improved state management" [5]. Apple credits CVE-2026-65400 to Alfredo Pesoli (@__rev) via Bynario Atlas (bynar.io) [6]. That is the whole disclosure. There is no attack-complexity note, no indication of whether the bypass needs a partial credential, and no statement that Apple is aware of a report of exploitation, which Apple does include in its advisories when it applies [10]. Apple's standing policy is that it does not disclose, discuss, or confirm security issues until an investigation has occurred and patches are available, so the absence of detail is the norm and not a signal about severity [7].
One correction worth making before it propagates. The advisory's "Available for" line names macOS Tahoe and nothing else, and the document as supplied references no Sonoma or Sequoia build [3][11]. If the same fix went back to older supported releases, that would come from separate Apple release notes, which are indexed on Apple's security releases page rather than in this document [8][11]. Until those are read directly, treat "the flaw spans supported releases" as an assumption, not a finding. The practical consequence for planning is the opposite of reassuring in either direction: if Sonoma and Sequoia were patched, the exposure window covered your whole estate; if they were not, you do not yet know whether they are affected and unfixed.
What this changes operationally is small and cheap. Screen Sharing is a per-host toggle, so the question is how many Macs in your inventory have it on, and whether any of them sit on networks where an untrusted device can reach them [4]. "An attacker on the network" is the qualifier that decides the blast radius: flat office VLANs, shared guest segments, and VPN pools that terminate alongside laptops all satisfy it, while a host reachable only from a jump path does not [4]. Because the flaw is an authentication state problem rather than a credential-strength problem, password policy, unique local accounts, and MDM-managed admin rotation do not mitigate it [5].
Watch for three things. First, whether Apple's release notes for Sonoma and Sequoia carry the same CVE-2026-65400 entry, which would confirm the cross-version scope and set the real patch deadline [6][11]. Second, whether the researcher or Bynario Atlas publish write-up detail, since a state-management bypass in a screen-sharing authentication handshake is the kind of bug that gets a working proof of concept quickly once described [5][6]. Third, your own telemetry: successful Screen Sharing sessions on hosts where nobody should be connecting are the cheapest detection available while patching proceeds [4].