Latest macOS Update Patches Pre-Auth Remote Code Execution Screen Sharing Vulnerability

Acknowledgments: Special thanks to Bryan Masters and Stuart Ashenbrenner for their contributions to this investigation and write-up.

TL;DR:

If you're running Screen Sharing on macOS and exposing it to the public internet, then we need to talk. While it's generally frowned upon to expose remote access protocols to the world, we understand that some use cases may require it. You do you!

With the uptick in hosted bare-metal Apple devices, such as the Mac mini available for on-demand workloads, SSH and Screen Sharing are commonly enabled by default on any newly provisioned service.

Apple's security releases announced in the last week of July were followed by a flurry of activity, public disclosures of newly patched bugs, and commentary on the scale of the CVEs listed. With this come references to bugs related to the Screen Sharing server. A week later, Apple  released a patch to comprehensively squash a bug of significant consequence.

Background

Apple quaintly describes Screen Sharing on macOS as a service that "allows users of other computers on your network to remotely connect to your Mac to view your desktop and control your Mac."

Screen Sharing on macOS uses the RFB (Remote Framebuffer) protocol, which is the primary protocol supporting VNC and its derivatives.

Two distinct authentication paths are allowed:

• Native Apple authentication: A typical username and password auth type, associated with a user's account on this system

• Legacy VNC authentication: A single password that is not associated with any specific user on macOS, but allows interaction with the currently logged-in user

For you visual learners out there, here's the Screen Sharing configuration panel in macOS Tahoe:

Figure 1: Screen Sharing settings on macOS Tahoe

The Screen Sharing system daemon is supported by two privileged user helpers that handle file operations: SSFileCopySender and SSFileCopyReceiver. Under the native Apple username:password authentication path, they are tied to execution in the user's context; however, under legacy VNC, they operate with root privileges.

On July 29,  bynar.io disclosed their research on one of the patched vulnerabilities, CVE-2026-43760, which exploited a confused-context condition; their write-up ultimately relied on an authenticated session for the conditions to allow the exploit to work.

This allowed for any user authenticated via the legacy VNC method to read and create any filesystem artifact as root.

Given the nature of the service and the compounded complexity of supporting dual authentication methods, it appears numerous researchers were spending time (and tokens) on this vector.

While addressing service vulnerabilities last week, Apple, intentionally or otherwise, appears to have partially fixed a pre-authentication vulnerability in screensharingd.

Root access without having to authenticate 

Following Apple's July security release, and the published research by bynar.io, Pedro Vilaça (aka fG!) published a blog post confirming that a pre-authentication bug in the daemon's authentication mechanism had been patched by Apple. This post was also accompanied by an obfuscated proof-of-concept binary that enabled anyone with the IP address of a Screen Sharing-enabled macOS host running ≤ macOS 26.5.2 (or ≤ macOS 15.7.7, ≤ macOS 14.8.7) to exploit the bug on unpatched systems to disclose any file-system artifact.

When we say "any artifact,"we mean it. As this proof of concept (PoC) leveraged the file operations supported by the SSFileCopySender helper process, it inherited the coveted private Apple-signed entitlement kTCCServiceSystemPolicyAllFiles, which grants Full Disk Access and bypasses TCC protections entirely.

User@MacBook-Pro ~ % codesign -d --entitlements - /System/Library/CoreServices/RemoteManagement/screensharingd.bundle/Contents/Support/SSFileCopySender.bundle/Contents/MacOS/SSFileCopySender

Executable=/System/Library/CoreServices/RemoteManagement/screensharingd.bundle/Contents/Support/SSFileCopySender.bundle/Contents/MacOS/SSFileCopySender

The PoC, tracked as CVE-2026-65400, successfully exploited a Screen Sharing service with both legacy VNC authentication disabled and no local Apple user accounts enabled for access.

Screen Sharing uses Secure Remote Password (SRP) for its native Apple authentication path, which, as mentioned above, authenticates against a real macOS user account. The screensharingd system daemon appears to have errors in its SRP implementation: The daemon's frame-length validator erroneously returns a stale success status, so the connection is treated as authenticated. The connection also continues without cryptographic protection, resulting in a cleartext session.

Ultimately, this allows an attacker to read and write arbitrary files as root. Analysis of fG!'s original blog post resulted in a new PoC distinguishing read and write functions, as well as combining them into remote code execution: a privileged reverse-shell script plus a cron job that calls back to an attacker-controlled listener.

Huntress reviewed this PoC at the time of disclosure and found that the implemented vector was ultimately unsuccessful because it relied on the ability to create a new cron job in /var/at/tabs/root, a location protected by TCC. While SSFileCopySender has Full Disk Access permissions when signed in, SSFileCopyReceiver has no such entitlements, likely due to the obvious TCC bypass implications of granting such an ability.
bl4sty's write-up was later updated to include a caveat that the above method will only work on a system with System Integrity Protection (SIP) disabled.

Remote code execution is achieved through a number of mechanisms, introducing varied opportunities for success:

• Creation of a LaunchDaemon that will trigger execution of an on-disk reverse shell upon reboot

• Modification of persistence within a shell startup file (e.g., .zshenv), which will trigger upon opening Terminal.app

Individual Screen Sharing properties, such as the removal of allowed user accounts or VNC password auth, do not affect this bug's success. One must admire the simplicity of this vulnerability.

How do I know if my Mac is exposed?

While the Screen Sharing service is not enabled by default (fortunately!), certain cases raise concern. As Apple silicon has grown in popularity, various providers are offering hosted bare-metal Apple Mac services, which commonly come provisioned with these services enabled. Given the knowledge of ASNs and non-standard ports that these providers leverage, a cursory search on Censys reveals tens of thousands of potentially vulnerable hosts.

Further compounding this issue, at the time of writing, some of these providers have not yet incorporated the latest Apple updates into their base provisioning image and are regularly exposing newly provisioned hosts running the vulnerable (n-1) versions to the internet. Additionally, the latest IPSW (Apple's restore image) for macOS Sequoia and Sonoma ending at 15.6.1 and 14.6.1, respectively. This means any device built with older (but supported) macOS versions will be provisioned vulnerable and stay that way until it can be updated.

The takeaway here is: Update all of your macOS devices across the board, even if you don't think Screen Sharing has been enabled. If you cannot patch immediately, make a point to disable Screen Sharing. 

Detection opportunities

Endpoint Security (ES) is Apple's C API for monitoring system events. Its primary use is to allow security vendors to monitor for potentially malicious activity. Security vendors, including Huntress, leverage this source (amongst others) as a telemetry stream to identify suspicious and malicious activity.

ES_EVENT_TYPE_NOTIFY_SCREENSHARING

Apple introduced Screen Sharing _ATTACH and _DETACH events in macOS 13.0.

When subscribed to ES_EVENT_TYPE_NOTIFY_SCREENSHARING_ATTACH via eslogger, Apple's tool for subscribing to user-specified ES events, we can observe the following for successful exploitation:

Notably, the session username root is a suspicious indicator, as this user on macOS is disabled by default, and few administrators would both enable that user and use it for Screen Sharing.

When comparing the output to a legitimate connection:

We also observe the authentication_type: RSA-SRP, in contrast to our malicious authentication_type: SRP (as noted earlier, no cryptography is applied to sessions established via this bug).

Figure 2: ES_EVENT_TYPE_NOTIFY_SCREENSHARING_ATTACH emitted by the ES Framework alongside a codified alert based on authentication_type

FS EVENTS

If you are collecting filesystem events via ES, you will also observe other ES_EVENT_TYPE_NOTIFY_ events _LOOKUP, _OPEN, _GETEXTATTR, _FSGETPATH, _GETATTRLIST, _STAT, _CLOSE, etc., with the executable property …SSFileCopySender and target path detailing the filesystem artefact that is being manipulated / leaked.

ES_EVENT_TYPE_NOTIFY_EXEC

If atomic filesystem events aren't something you have access to, you will find some luck in observing process execution events via ES with the following command line:

/System/Library/CoreServices/RemoteManagement/screensharingd.bundle/Contents/Support/SSFileCopySender.bundle/Contents/MacOS/SSFileCopySender 0 80

/

Information disclosure exploitation attempts will result in execution with attributes <UID> <GID>, which will be 0 80 in initial instances. These values will not remain static; however, if a threat actor enumerates another user on the system, they can circumvent this detection.

You should expect to see at least one root event, as this enumeration must occur in that context first. If a threat actor attempts to guess a valid account, the Screen Sharing events will include the attribute session_username: null, providing further opportunities for noisy enumeration.

Remediation

Patch now. Update to macOS 26.6.1, 15.7.9, or 14.8.9 (released 6 August 2026). These are the only builds that fully address the pre-authentication bug, and close CVE-2026-65400.

If you cannot patch immediately, disable Screen Sharing. 

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.

Full Disclosure Timeline