Security1 distinct publisher3 min readUpdated
Huntress says a public proof of concept needs only an IP address to pull any file off unpatched Macs, driving a helper process that carries Full Disk Access.
The Watch · Security desk
Compiled by The WatchSomething wrong?How this is made
Huntress has published a breakdown of two macOS Screen Sharing vulnerabilities, CVE-2026-43760 and CVE-2026-65400, and the second is the one that changes your week: a public proof of concept that needs nothing but the IP address of an exposed Mac to read any file on it [1][9]. Apple's security releases in the last week of July were followed by a run of disclosures and commentary about Screen Sharing bugs, and Apple then shipped a further patch that Huntress describes as comprehensively squashing a bug of significant consequence [2].
The architecture explains the blast radius. Screen Sharing speaks RFB, the protocol behind VNC and its derivatives [3], and supports two authentication paths: native Apple auth against a real macOS account, and legacy VNC, a single password bound to no user that drives whatever session is currently logged in [4]. Two privileged helpers, SSFileCopySender and SSFileCopyReceiver, handle the file operations. Under native auth they run in the user's context. Under legacy VNC they run as root [5].
On July 29, bynar.io detailed CVE-2026-43760, a confused-context condition that required an authenticated session and let any legacy-VNC user read and create arbitrary filesystem artifacts as root [6]. Bad, but with a precondition an operator can reason about: someone had to hold the VNC password.
CVE-2026-65400 removes the precondition. According to Huntress, Apple's service fixes appear to have partially closed a pre-authentication bug in screensharingd, intentionally or otherwise [7], and Pedro Vilaca (fG!) then published a post confirming the patch, along with an obfuscated proof-of-concept binary [8]. Against hosts at or below macOS 26.5.2, 15.7.7, or 14.8.7, which covers three supported release trains [15], the PoC discloses any filesystem artifact to anyone holding the address [9]. It works because it drives SSFileCopySender, which inherits the private Apple-signed entitlement kTCCServiceSystemPolicyAllFiles: Full Disk Access, TCC bypassed entirely [10]. Huntress reports the PoC succeeded against a service with legacy VNC authentication disabled and no local Apple user accounts enabled for access [11], which retires the two configuration mitigations most teams would reach for first. Huntress attributes the failure to errors in the daemon's implementation of Secure Remote Password, including its frame-length validator [12].
The inventory problem is larger than the patching problem. Apple describes Screen Sharing as a service that lets users of other computers "on your network" connect to view and control your Mac [14], and with the growth of hosted bare-metal Apple hardware, including on-demand Mac minis, SSH and Screen Sharing are commonly enabled by default on newly provisioned service [13]. Those machines are not on your network. They have routable addresses, and they were frequently stood up by a developer with a credit card rather than through a build process that would have turned the service off.
Watch for whether the obfuscated proof of concept is reverse-engineered into something reusable, since disclosure of arbitrary files as root includes credentials and keys that make the file-write primitive in CVE-2026-43760 largely academic [6][9][10]. Watch, too, for further findings in the same daemon: Huntress frames the SRP problem as errors in the implementation rather than a single logic slip [12].
Follow any of these and your For You feed starts watching them — no settings page required.
Ranked by verification strength, evidence, and original report placement.
The proof of concept, 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.
Huntress published a write-up titled "From Screen Share to Root Access: Breaking Down CVE-2026-43760 and CVE-2026-65400 on macOS", covering two macOS Screen Sharing vulnerabilities.
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, including references to bugs in the Screen Sharing server; a week later Apple released a patch to comprehensively squash a bug of significant consequence.
Screen Sharing on macOS uses the RFB (Remote Framebuffer) protocol, the primary protocol supporting VNC and its derivatives.
Screen Sharing allows two distinct authentication paths: native Apple authentication, a username and password associated with a user account on the system, and legacy VNC authentication, a single password not associated with any specific macOS user that allows interaction with the currently logged-in user.
The Screen Sharing system daemon is supported by two privileged user helpers that handle file operations, SSFileCopySender and SSFileCopyReceiver; under native Apple username:password authentication they are tied to execution in the user's context, but under legacy VNC they operate with root privileges.
Evidence-backed comparisons of source perspectives and observed adoption signals. Read the methodology
Which Builder, Operator, and Investor concerns the observed source mix emphasized—not a truth score.
Evidence, demonstrated adoption, hype gap, incentives, and confidence are assessed independently, each on its own current evidence. How these are measured.
Detailed single-vendor technical account
The account is specific and partly verifiable in kind: a codesign entitlement dump for SSFileCopySender, a named SRP frame-length validator defect, explicit affected version ceilings, two CVE identifiers, and a hands-on verification that the cron-based RCE chain fails under TCC. What is absent from the cluster is any Apple advisory, patch identifier, or independent publisher reproducing the findings, and the key assessment that Apple only partially fixed the pre-auth bug is hedged with 'appears to'.
Public exploit and patch exist; exposure unmeasured
Real-world uptake signals are present on the research and vendor side: a July 29 third-party disclosure, a public proof-of-concept binary, an Apple patch, and a follow-on PoC that Huntress tested. What is missing is the demand-side measurement that would raise this: no count of internet-exposed Screen Sharing hosts, no hosted-provider defaults evidenced by name, no patch-uptake data, and no in-the-wild exploitation telemetry.
Slightly overstated at the headline
The core arbitrary-file-read claim is well matched to the technical detail supplied, and the article volunteers its own limits: the cron-based RCE path failed against TCC and reportedly needs SIP disabled. The overstatement is at the framing level - 'any exposed Mac' elides that a patch already exists and that the version ceilings bound the affected population, while the unquantified assertion about hosted bare-metal defaults enlarges the perceived blast radius without data.
Security vendor research with visibility upside
The sole source is a commercial endpoint security vendor publishing threat research under its own brand, an established channel for demonstrating macOS expertise and generating inbound attention; the piece also amplifies named independent researchers whose reputational incentive runs the same direction. Offsetting this, the write-up sells no product in the supplied text, names no detection SKU, and actively debunks part of a third party's exploit chain, which is not the behaviour of pure promotion.
Moderate: plausible and specific, but uncorroborated
Confidence is limited chiefly by cluster structure rather than plausibility: one publisher, no Apple advisory, no independent write-up in evidence, and the patch-completeness assessment explicitly hedged. The specificity of the mechanism, version ceilings, entitlement evidence, and self-reported negative result raise it above a bare single-source rumour.
build
Unauthenticated root on macOS Screen Sharing: CVE-2026-65400 is already dropping miners1 distinct publisher
security
Apple patches a network-reachable Screen Sharing auth bypass in macOS Tahoe 26.6.11 distinct publisher
invest
Your Landed Cost Is Being Litigated By Companies With $306,000 Problems1 distinct publisher
build
GitLab bundles a zero-click GraphQL flaw with a CSRF bug, and only one needs a victim1 distinct publisher
Distinct publishers with included, body-backed reporting in this cluster.