Critical Apple Screen Sharing Flaw Lets Attackers Execute Commands as Root

Key Takeaways

• A critical logic flaw in macOS Screen Sharing allowed remote attackers to execute commands as root.
• The vulnerability, identified as CVE-2026-43760, affected macOS systems with Screen Sharing or Remote Management enabled and configured with the legacy VNC password option.
• The flaw stemmed from improper privilege handling when VNC authentication was used, allowing file-copy helpers to run as root.
• Apple issued patches for macOS Tahoe 26.6 and macOS Sonoma 14.8.8 on July 27, 2026.
• Disabling the VNC password option or Screen Sharing/Remote Management entirely provides immediate mitigation for unpatched systems.

Root-Level Access Achieved Through macOS Screen Sharing Flaw

A significant logic vulnerability within Apple’s macOS Screen Sharing feature has been uncovered, demonstrating how a component designed for visual access could be manipulated to grant full root command execution. This flaw, designated CVE-2026-43760, impacts the screensharingd service and its associated file-copy utilities, SSFileCopySender and SSFileCopyReceiver. Systems are vulnerable if they have Screen Sharing or Remote Management activated with the older VNC password option enabled.

The core issue resides in how the Apple Screen Sharing service manages two distinct authentication mechanisms. When users connect via Apple’s native authentication, the service correctly identifies them as a macOS user, ensuring any file-copy operations are executed with that user’s specific permissions.

VNC Authentication Bypass Leads to Privilege Escalation

However, a critical security lapse occurs when connections are established through the legacy VNC authentication method, which relies solely on a pre-configured “VNC viewers may control screen with password” credential. In this scenario, no direct macOS user identity is associated with the VNC password. Rather than appropriately restricting privileges, the file-copy helper processes continue to operate with root authority.

This design flaw created a dual vulnerability. On the data retrieval side, a remote VNC viewer could instruct SSFileCopySender to fetch any specified file path. Because the helper process ran as root, it would readily provide the contents of protected system files, such as /etc/sudoers, which a standard user account would ordinarily be unable to access directly.

Conversely, the SSFileCopyReceiver utility allowed a remote viewer to define a destination directory, filename, permissions, and file contents, all executed with root privileges.

Bynar researchers used this capability to write a new file directly into /private/etc/sudoers.d. This directory is critical because any properly formatted and permissioned file placed within it is automatically trusted by the sudo command, enabling custom sudo policies.

By leveraging this remote file-write primitive to craft a valid, root-owned sudoers policy, the researchers successfully granted a non-administrative account passwordless sudo access. This critical step allowed them to then execute a single command to establish an interactive root shell, entirely remotely, through the authenticated Screen Sharing session and its file-copy protocol. Notably, this exploit chain did not rely on memory corruption, buffer overflows, or complex exploit techniques.

Apple’s initial description of the flaw suggested it merely allowed an application to access sensitive user data. However, independent security researchers argue this significantly downplays the actual impact, given that the vulnerability facilitates arbitrary root file creation and remote command execution. Independent analysis has assigned the flaw a CVSS 3.1 score as high as 8.8 in scenarios where an unlocked session is already active, which contrasts with Apple’s official rating of 5.5.

Patches and Mitigation

Apple addressed this vulnerability in macOS Tahoe 26.6 and macOS Sonoma 14.8.8, with both updates released on July 27, 2026. Users who cannot immediately apply these updates are strongly advised to disable the “VNC viewers may control screen with password” option. Alternatively, if remote access is not essential, Screen Sharing and Remote Management should be disabled entirely. It is crucial to understand that simply changing the VNC password does not resolve the underlying authorization flaw.

This incident highlights a growing trend in cybersecurity research: as advanced memory-safety protections, such as Memory Integrity Enforcement and Pointer Authentication, make traditional exploitation techniques more challenging, attackers and researchers are increasingly focusing on logic and authorization bugs. These vulnerabilities exploit situations where individual operations function as intended, but an unintended entity gains control due to flaws in privilege management.

What You Should Do

• Update Immediately: Ensure your macOS systems are updated to macOS Tahoe 26.6, macOS Sonoma 14.8.8, or later versions.
• Disable VNC Password Option: If immediate patching is not possible, navigate to System Settings > General > Sharing > Screen Sharing (or Remote Management) and disable the “VNC viewers may control screen with password” option.
• Disable Screen Sharing/Remote Management: If remote access is not a requirement for your workflow, disable Screen Sharing and Remote Management services entirely in your Sharing settings.
• Review Access Policies: Regularly audit and restrict remote access permissions on your macOS devices.

Disclaimer: HackersRadar reports on cybersecurity threats and incidents for informational and awareness purposes only. We do not engage in hacking activities, data exfiltration, or the hosting or distribution of stolen or leaked information. All content is based on publicly available sources.