macOS Screen Sharing Flaw (CVE-2026-65400) Let Hackers Get Root Without a Password

Apple has shipped an out-of-cycle patch closing one of the more alarming remote-access flaws to surface this year: a pre-authentication bug in macOS’s Screen Sharing service that let a network attacker gain root access without ever supplying a username or password.

The fix, distributed on August 6, 2026, as macOS Tahoe 26.6.1, Sequoia 15.7.9, and Sonoma 14.8.9, arrived just ten days after an earlier update inadvertently exposed the path to this exact issue.

It began on July 27, when Apple’s routine security release patched CVE-2026-43760, a post-authentication flaw disclosed by Ryan Dowd that allowed anyone logged in via legacy VNC to read and write files as root.

macOS Screen Sharing Flaw (CVE-2026-65400)

Two days later, reverse engineer Pedro Vilaça (fG!) published research showing that the same update had quietly disturbed a separate, far more dangerous bug: a pre-authentication flaw in the screensharingd daemon itself.

Because both bugs involve the same service and similar root-level file access, they were easy to conflate, but only one required zero credentials.

The root cause traces to Screen Sharing’s implementation of Secure Remote Password (SRP) authentication. When screensharingd received an oversized data frame during the handshake, its length validator returned a stale “success” code left over from a previous check instead of throwing an error.

That single miscalculation convinced the daemon the login had succeeded, skipping the password check, key exchange, and encryption setup entirely, dropping the attacker into a fully privileged, unencrypted session.

From there, the built-in file-copy helper handed over arbitrary file read and write as root, inheriting Apple’s kTCCServiceSystemPolicyAllFiles entitlement, which bypasses TCC protections outright.

Researcher bl4sty later demonstrated that the primitive could be chained to full remote code execution via LaunchDaemons or shell startup persistence, provided the target is still running with System Integrity Protection disabled.

“What makes CVE-2026-65400 genuinely dangerous isn’t its complexity it’s the opposite. This is a textbook confused-state bug hiding inside a protocol most admins assume is ‘secure by default’ because it uses SRP.

The real lesson for defenders is that legacy remote-access daemons on any OS deserve the same scrutiny as internet-facing web apps, especially now that bare-metal Mac hosting has turned Screen Sharing into an accidental attack surface.”

Screen Sharing isn’t enabled by default, but the rise of hosted bare-metal Apple Silicon services Mac minis rented for on-demand workloads has changed the calculus.

Many providers ship Screen Sharing and SSH pre-enabled, and some hadn’t updated their provisioning images before this disclosure, meaning newly spun-up hosts landed on the internet already vulnerable.

A quick scan of internet-facing hosts on non-standard ports tied to known cloud-Mac ASNs reportedly turns up tens of thousands of potentially reachable Screen Sharing instances.

Apple’s advisory credits the fix to “improved state management” and confirms it closes CVE-2026-65400 across all three supported macOS branches.

Because this is a pre-authentication flaw, typical hardening measures, such as removing user accounts, disabling legacy VNC passwords, and rotating credentials, offer no protection. Security teams should:

Update immediately to macOS 26.6.1, 15.7.9, or 14.8.9.
Disable Screen Sharing entirely if patching isn’t immediately possible.
Monitor Endpoint Security telemetry for ES_EVENT_TYPE_NOTIFY_SCREENSHARING_ATTACH events showing authentication_type: SRP (unencrypted) rather than the legitimate RSA-SRP, and flag any session logging in as the disabled root account.

There’s no evidence of in-the-wild exploitation yet, but with public proof-of-concept research already circulating, that window is unlikely to stay closed for long.