macOS Screen Sharing Bug Under Active Exploitation Gives Attackers Full Control of Macs

A flaw in macOS Screen Sharing is handing attackers full remote control of Macs across the open internet, and they are getting in without a password. The bug, tracked as CVE-2026-65400, lives in screensharingd, the background service behind Apple's built-in remote desktop feature. Apple shipped a fix on August 6, but within days the Dutch national cyber agency was reporting live compromises, and by mid-August U.S. authorities had pushed the flaw's severity rating to the top of the scale.

Here is the sentence to carry into your next patch meeting: any Mac with Screen Sharing reachable from the internet on TCP port 5900 can be logged into as a local account without the password, unless it already runs macOS Tahoe 26.6.1, Sequoia 15.7.9, or Sonoma 14.8.9. That combination, an exposed port plus an unpatched build, is the entire attack. Once inside, an intruder has the same reach a legitimate remote user would: opening applications, reading files, and changing security settings, as Ars Technica reported.

What the Screen Sharing Bug Actually Does

CVE-2026-65400 is an authentication bypass. Apple attributes it to a state management error, the part of the daemon that tracks what has happened in a session and what the caller is allowed to do next. Because the bypass happens before the service reaches its authentication checks, it is a pre-authentication flaw. An attacker on the network path does not guess or steal a password; the daemon simply treats the connection as an authenticated account and hands over a session.

Security firm Huntress, which published a technical breakdown, tied the issue to the same Screen Sharing surface Apple hardened in its August updates, alongside a separate remote code execution bug, CVE-2026-43760, patched in the same cycle. The authentication bypass is the one being fired in the wild, and its practical result is the phrase in every headline: full remote control of the Mac, no password required.

Apple Already Patched It, Which Changes the Playbook

This is not an unpatched zero-day, and that distinction matters for how you respond. Apple released the fix on August 6 across three supported lines at once: macOS Tahoe 26.6.1, macOS Sequoia 15.7.9, and macOS Sonoma 14.8.9, as 9to5Mac documented. The active exploitation followed the patch rather than preceding it, which tells you the exposure is now an n-day problem: the fix exists, and the risk sits entirely with machines that have not applied it and still expose the service.

That pattern, real-world attacks landing on unpatched systems days after a disclosure, is becoming the rule this month rather than the exception. We saw it with VMware vCenter and SharePoint flaws that came under attack inside a week of their fixes, and with an unpatched GeoServer zero-day feeding remote code execution. The macOS case fits the same shape: publish, patch, and race the attackers to the update. The window between a fix and its abuse keeps shrinking, so the machines that lag on updates are the ones that get taken.

Why the Usual Screen Sharing Hardening Does Not Help

The uncomfortable detail for defenders is that most of the familiar Screen Sharing knobs do nothing against this bug. Because the bypass fires before authentication, rotating the VNC password, turning off legacy VNC password access, and removing approved Screen Sharing users all have zero effect on CVE-2026-65400. The daemon never reaches the point where those settings apply. The two controls that actually matter are binary: apply the patch, and stop exposing TCP port 5900 to the internet.

The exploitation reports make that concrete. According to the Dutch National Cyber Security Centre, as relayed by BleepingComputer, every compromised Mac it observed had port 5900 open to the internet. In each case the attackers gained root and installed a Monero cryptocurrency miner, quietly turning the machine's processor into a mining rig. Monero's proof-of-work algorithm favors general-purpose CPUs, which makes an ordinary Mac worth hijacking without any specialized hardware, and it explains why opportunistic crews scan for exposed 5900 in the first place.

From 7.1 to 9.8: How the Severity Estimate Moved

When the fix first shipped, the flaw carried a CVSS base score of 7.1, a serious but not emergency rating. That changed once exploitation started. On August 14, U.S. authorities raised the score to 9.8, near the ceiling of the scale, reflecting a network-reachable, pre-authentication path to root that was being used in real attacks, as Tom's Hardware noted. The jump is a useful signal on its own: the same bug can look moderate on paper and critical in practice, and the deciding factor is whether anyone is actually firing it. A score is a snapshot, not a verdict.

How to Tell If a Mac Is Exposed

Exposure here has two ingredients, and you can check both quickly. First, patch state: on any Mac, open System Settings, go to General, then Software Update, and confirm the build is at or beyond the August 6 releases for its line. Second, reachability: Screen Sharing listens on TCP port 5900, so the risk only exists if that port is reachable from an untrusted network. A Mac behind a home router with no port forwarding, or inside a corporate network with 5900 blocked at the edge, is not the target profile. A Mac with a public IP or a forwarded 5900, common on cloud-hosted Macs, build agents, and remote-access setups, is exactly what the scanners are looking for.

For fleets, the fastest read comes from two questions. Does the MDM show every Mac on a patched build, and does an external scan of your address space find any host answering on 5900? If the answer to the first is yes, the flaw is closed regardless of the port. If the answer to the second is no, the attack path is cut even on a machine that has not updated yet. Treat any unexplained, sustained CPU load on a Mac as a possible cryptominer worth investigating rather than a performance quirk.

My Read

The scary framing, full control of a Mac with no password, is accurate, but the fix is unusually clean, and that is the part defenders should hold onto. This is not a stealthy chained exploit that survives patching or hides in memory. It is a single pre-authentication bug with an official update already available and one clear network precondition, an exposed port. If your fleet is patched to the August 6 builds, or if no Mac is answering on port 5900 from the internet, this campaign has nothing to grab.

The population at real risk is narrow and predictable: home users and small shops who turned on Screen Sharing for convenience and left it reachable, plus forgotten Macs running as build agents, media servers, or cloud instances with remote access wide open. For enterprise teams, the job is inventory and confirmation, not alarm. Verify patch levels through the MDM, hunt for any device exposing 5900, and watch for the cryptominer tell of steady CPU load. The move from 7.1 to 9.8 is the lesson worth keeping past this one bug: severity is not fixed at disclosure, and a flaw's real weight is set by whether it is being used against people right now.

Primary Documents

• Ars Technica: Vulnerability giving attackers full control of Macs is under active exploitation
• 9to5Mac: Apple's latest macOS updates address a serious Screen Sharing vulnerability
• BleepingComputer: Hackers exploit macOS Screen Sharing flaw to deploy Monero miner
• Huntress: From screen share to root access, breaking down the macOS Screen Sharing flaws
• Tom's Hardware: macOS Screen Sharing flaw exploited to root Macs and plant Monero miners