Home Blog Latest macOS Update Patches Pre-Auth Remote Code Execution Screen Sharing Vulnerability Published: August 7, 2026 Latest macOS Update Patches Pre-Auth Remote Code Execution Screen Sharing Vulnerability By: Ryan Dowd Summarize with AI Summarize ChatGPT Claude Perplexity Google AI Key Takeaways Apple released patches on July 27 and August 6, 2026 to address vulnerabilities in the macOS Screen Sharing service. Two distinct Screen Sharing vulnerabilities surfaced within days of each other: CVE-2026-43760 and CVE-2026-65400. They are easy to confuse but differ in the one thing that matters most: whether the attacker needs credentials. CVE-2026-65400, the more serious of the two, exploits a flaw in the Screen Sharing service's implementation of Secure Remote Password (SRP), which ultimately allows pre-authenticated remote code execution on all supported macOS versions. This means that an attacker could run malicious code on the victim system without having to log in as a root user. Anybody who leverages Apple's Screen Sharing functionality on any supported macOS version needs to apply the most recent security updates immediately. macOS major version Patched build (6 Aug 2026) Earlier builds Tahoe (macOS 26) 26.6.1 Vulnerable - including 26.6* Sequoia (macOS 15) 15.7.9 Vulnerable - including 15.7.8* Sonoma (macOS 14) 14.8.9 Vulnerable - including 14.8.8* * Public PoCs affect versions prior to this. 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 Loading Gist... 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: Loading Gist... 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: Loading Gist... 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 base