Inside the screensharingd Bugs: How macOS Screen Sharing Went from Root File Access to Pre-Auth Compromise

In late July 2026, a cluster of vulnerabilities in macOS Screen Sharing turned what initially looked like a fairly constrained privilege problem into one of the more interesting macOS remote-attack stories in years. 

The important detail is that the public discussion actually covers several different bugs inside screensharingd,and they are easy to conflate. One required a legacy VNC password, another allowed authentication to be bypassed entirely, and a third related pre-authentication flaw forced Apple to ship an unusual out-of-band macOS update only days later.

The original disclosure: CVE-2026-43760

The story began publicly with Bynario researcher Alfredo Pesoli's July 29 write-up, "A root remote command execution on macOS with M5 in 2026?".

The vulnerability, CVE-2026-43760, concerned the way screen sharing handled Apple's legacy VNC authentication mode. macOS screen sharing supports both native authentication using a real macOS account and the older VNC password mechanism. The latter proves that a client knows the configured VNC password, but it does not identify an actual macOS user with a UID and GID.

That distinction became dangerous when file transfers entered the picture. screensharingd uses privileged helper processes named SSFileCopySender and SSFileCopyReceiver. Under normal Apple-account authentication, those helpers operate in the authenticated user's context. Under legacy VNC authentication, however, Bynario found that the helpers could retain root filesystem authority. A VNC-authenticated client could consequently make the sender read files as root or make the receiver create attacker-controlled files with root ownership.

Bynario demonstrated that the write primitive could be converted into root command execution by creating security-sensitive files such as a valid sudoers.d policy. The significant limitation was authentication: an attacker still needed the separately configured VNC password. This made CVE-2026-43760 a serious post-authentication authorization failure, rather than a true unauthenticated network takeover.

Apple had already patched CVE-2026-43760 in macOS Tahoe 26.6 and Sonoma 14.8.8 on July 27. Apple's advisory described its impact simply as an app potentially accessing "user-sensitive data," while Bynario argued that this description substantially understated the ability to perform privileged file creation and ultimately execute commands as root. The original Apple security bulletin is available in Apple's macOS 26.6 security content.

OSXReverser: "It's a pre-auth, stupid!"

On the same day as Bynario's publication, veteran macOS reverse engineer Pedro Vilaça, better known as fG! (also known as @osxreverser), published a much more provocative article: "It's a pre-auth, stupid!".

Vilaça had independently found a different flaw in screensharingd some time earlier and had not reported it to Apple. After installing macOS 26.6, he discovered that Apple's July update had nevertheless killed his bug. His central point was that the most dangerous issue in this area did not require the VNC password at all: a network attacker needed only to reach a Mac with screen sharing enabled.

Rather than publish the technical details, Vilaça released an intentionally limited and obfuscated proof-of-concept called navi_the_clown. It demonstrated arbitrary remote file disclosure from the vulnerable Mac but withheld the underlying protocol flaw and full exploitation chain. Because the file operation eventually ran through Apple's privileged file-copy infrastructure, the impact extended beyond files normally accessible to an ordinary user and could bypass TCC privacy controls on reads.

The particularly interesting part was that Apple's July security bulletin did not describe any screen sharing issue as a pre-authentication compromise. It contained three screen sharing Server entries on Tahoe, including CVE-2026-43760 and CVE-2026-43777, which Apple described only as a remotely triggerable denial of service fixed through improved input validation. Vilaça later stated that he believed the fix associated with that DoS path was what inadvertently killed his much more powerful authentication bypass. Apple has not publicly assigned Vilaça's pre-auth flaw its own CVE.

Reversing navi_the_clown

The missing technical explanation arrived shortly afterward when bl4sty reverse-engineered Vilaça's binary and published "Apple Screen Sharing Pre-Auth RCE".

The analysis traced the vulnerability to an almost absurdly small error in screensharingd's SRP frame-length validation. When an oversized authentication frame was received, an error path returned a stale success value left over from an earlier successful network read. The caller interpreted zero as authentication success and advanced into the authenticated RFB message loop even though the Secure Remote Password exchange had never completed. No session key had been established and the connection continued without the encryption normally installed after SRP authentication.

That transformed Vilaça's arbitrary-file-read demonstration into something significantly more powerful. The same post-authentication Screen Sharing file-copy protocol could be reached without providing a password or, for this first bug, even a valid username. The privileged file-copy helpers then supplied root-level read and write primitives. bl4sty subsequently demonstrated paths from those primitives toward root code execution, while also correcting the original write-up when one persistence mechanism was found to depend on System Integrity Protection being disabled. A later path using writable, non-SIP-protected locations was validated against SIP-enabled macOS.

In other words, the critical flaw was not memory corruption, a race condition, or some elaborate PAC bypass. It was essentially a wrong return value in an authentication state machine.

Then Apple patched another pre-auth bug

The July 27 fix was not the end of the story. On August 6, 2026, Apple unexpectedly released macOS Tahoe 26.6.1, Sequoia 15.7.9, and Sonoma 14.8.9 specifically to address another Screen Sharing authentication vulnerability, CVE-2026-65400. Apple's advisory finally used much stronger language: an attacker on the network could potentially authenticate to Screen Sharing without valid credentials. Apple said it fixed the issue through "improved state management" and credited Alfredo Pesoli via Bynario Atlas. See Apple's CVE-2026-65400 advisory.

Importantly, CVE-2026-65400 was not simply a new CVE number for OSXReverser's stale-return bug. Calif later diffed macOS 26.6 against 26.6.1 and concluded that Apple had fixed a second, independent pre-authentication problem in the same general authentication code. The first flaw was the stale return value uncovered through reversing navi_the_clown; the second involved a different state-machine desynchronization. Calif reported producing working exploits for both bugs by comparing Apple's patched and unpatched binaries. Their analysis is available as "No Country for Old Passwords".

That distinction explains the otherwise confusing timeline. macOS 26.6 had already killed OSXReverser's original pre-auth bug on July 27. The emergency 26.6.1 release on August 6 closed CVE-2026-65400, another authentication bypass that remained exploitable even on 26.6.

The episode also demonstrated how quickly a patch itself becomes a roadmap: once Apple shipped small, targeted fixes, researchers were able to diff the binaries and reconstruct the vulnerabilities in a matter of days, or, in Calif's case, hours.

From vulnerability research to real-world malware

The story did not remain academic for long. On August 12, the Netherlands National Cyber Security Centre updated NCSC-2026-0280 to report active exploitation of CVE-2026-65400. According to the NCSC, multiple compromised Macs had TCP port 5900 exposed directly to the Internet. In every reported case, the attacker had obtained root access and installed a Monero cryptocurrency miner.

Microsoft Threat Intelligence subsequently reported telemetry showing similar attacks. After compromising a Mac through Screen Sharing, the attackers were observed establishing additional persistence rather than continuing to rely only on the original vulnerability. They transferred scripts and an SSH public key, modified system configuration, removed evidence such as command history and logs, changed macOS Packet Filter settings, and deployed XMRig 6.26.0 for cryptocurrency mining. The XMRig executable was placed in a hidden location as .config/sysmond, ad-hoc code signed, and launched while masquerading under the legitimate-looking name com.apple.airportd. Persistence was then established with a KeepAlive LaunchDaemon so that the miner would automatically return after termination or reboot. Microsoft's original reporting can be found in its Threat Intelligence post on the exploitation.

The payload being a cryptocurrency miner should not distract from the severity of the initial compromise. XMRig was simply the attackers' chosen method of monetization. A pre-authentication entry point that results in root-level access gives an intruder the ability to install almost any subsequent payload, establish additional remote-access mechanisms, steal credentials or data, or use the Mac as a foothold for further movement through a network. The incidents reported by NCSC-NL therefore provided an important confirmation that the screensharingd flaws were not merely interesting exploitation research: Internet-facing Macs were actually being compromised.

Primary sources

• Bynario — A root remote command execution on macOS with M5 in 2026?
• fG! (OSXReverser) — It's a pre-auth, stupid!
• bl4sty — Apple Screen Sharing Pre-Auth RCE
• Calif — No Country for Old Passwords
• Apple — macOS 26.6 security content
• Apple — macOS 26.6.1 CVE-2026-65400 security content
• NCSC-NL — NCSC-2026-0280
• Microsoft Threat Intelligence — CVE-2026-65400 exploitation and XMRig activity