macOS Screen Sharing (screensharingd) supports two authentication modes: native Apple ID/Remote Management authentication, which resolves a macOS user identity and scopes privileges accordingly, and a legacy VNC password method (RFB security type 2) that only proves knowledge of a shared secret and establishes no macOS user identity at all. CVE-2026-43760 is a confused-deputy logic flaw (CWE-284, Improper Access Control): the file-copy helper processes spawned to service Screen Sharing file transfers — SSFileCopySender (reads) and SSFileCopyReceiver (writes) — continue to run as root regardless of which authentication path was used, instead of dropping privileges for VNC-password sessions that have no associated user identity.

Researcher Alfredo Pesoli (@__rev) of Bynar.io/Bynario documented a three-phase exploitation chain in a July 29, 2026 writeup. Phase 1: the attacker issues a StartFileSend command with a protected path such as /etc/sudoers; because SSFileCopySender forwards the viewer-selected path directly ("session->path = send->path") without a permission check and runs as UID 0, the read succeeds where an unprivileged local user would get "Permission denied." Phase 2: the attacker issues a StartFileReceive command specifying an attacker-chosen destination directory, filename, POSIX mode, and file content; SSFileCopyReceiver, also running as UID 0 GID 80, creates the file with root ownership and the requested mode. In the researcher's proof, a policy file owned root:wheel with mode 0440 — "the mode matters: sudo accepts policy includes only when their ownership and permissions are safe" — was written to /private/etc/sudoers.d/99-screensharing-filecopy-proof, granting passwordless sudo. Phase 3: the attacker runs "sudo -n /bin/bash" and receives an interactive root shell. The researcher also wrote a callback script through the same file-copy channel to open Terminal and start it under the new sudo rule, demonstrating an automated, no-further-interaction path from file-copy abuse to a spawned root terminal — full remote root command execution requiring nothing beyond possession of the Screen Sharing VNC password. Discovery relied on differential-privilege reasoning rather than a crash: the identical file-copy operation ran as UID 502 and was denied under native Apple ID authentication, but ran as UID 0 and succeeded under legacy VNC authentication. The bug was found via Bynario's "Atlas" automated vulnerability-discovery workflow, which used GPT-5.5 for discovery and validation. Apple credits Pesoli, wdszzml, and the "Atuin" automated vulnerability discovery engine in its advisory.

Apple rated the issue 5.5; NVD/CISA-ADP independently scored it CVSS 3.1 8.6 (AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:L/A:L), and cybersecuritynews.com's independent analysis argued for up to 8.8 on hosts with an active, unlocked session. It is fixed in macOS Tahoe 26.6 and macOS Sonoma 14.8.8, both released 2026-07-27; there is no evidence in CISA's Known Exploited Vulnerabilities catalog (checked as of the catalog's 2026-08-14 snapshot) that CVE-2026-43760 itself has been exploited in the wild. Exploitation strictly requires Screen Sharing/Remote Management to be enabled with the legacy "VNC viewers may control screen with password" option active, plus attacker knowledge of that VNC password — the initial-vector question of how an attacker obtains the password is not addressed in the public research and is not assumed here.

CVE-2026-43760 sits in the same Screen Sharing subsystem as a separate, more severe flaw, CVE-2026-65400 — a pre-authentication Secure Remote Password (SRP) implementation bug (a stale-success frame-length validator) that lets a remote attacker bypass authentication entirely, not merely abuse an already-authenticated VNC session. Apple emergency-patched CVE-2026-65400 on 2026-08-06 (macOS Tahoe 26.6.1, Sequoia 15.7.9, Sonoma 14.8.9); the Dutch NCSC reported on 2026-08-12 that it was being actively exploited in the wild against internet-exposed Macs (port 5900) to gain root and install Monero cryptocurrency miners, and CISA raised its score from 7.1 to 9.8 Critical on 2026-08-14. That in-the-wild exploitation and miner activity is attributed to CVE-2026-65400, not to CVE-2026-43760, and is documented here only as directly relevant subsystem/timeline context.