CRITICAL: Apple macOS Screen Sharing CVE-2026-65400 Exploited for Root Access

Apple does not ship out-of-band patches because it enjoys the attention. When a fix lands on a Thursday in August with no event, no keynote, and no accompanying press release, it usually means somebody in Cupertino had a very bad week. That is exactly what happened on August 6, when Apple quietly pushed macOS Tahoe 26.6.1, macOS Sequoia 15.7.9, and macOS Sonoma 14.8.9 to close an authentication bypass in Screen Sharing. Eight days later CISA rescored the same bug from a fairly polite 7.1 to a full 9.8 and dropped it into the Known Exploited Vulnerabilities catalog alongside actively exploited flaws in SharePoint, VMware vCenter, and Microsoft's IKE service.

That rescoring is the part worth paying attention to. Agencies do not double a severity rating on a hunch. They do it when the real world demonstrates that the theoretical impact was badly underestimated, and in this case the real world was already several days ahead of the paperwork.

The bug is CVE-2026-65400, and it is about as bad as a network facing flaw gets. An attacker who can reach a Mac's Screen Sharing port can authenticate without credentials, land on the machine with root privileges, and read and write arbitrary files. No phishing lure, no user interaction, no stolen password, no clever chain of three other vulnerabilities to make it work. Just a TCP connection and a handshake that forgets to check whether anybody actually proved who they were.

What actually breaks

macOS Screen Sharing supports Secure Remote Password as its modern authentication method. SRP is genuinely good cryptography, designed so that a password never crosses the wire and so that anyone watching the exchange learns nothing they can replay or crack offline. The problem here is not the mathematics, it is the plumbing wrapped around it.

The screensharing daemon validates the length of incoming protocol frames as they arrive. Under the right conditions that validator returns a stale success status left over from an earlier stage of the exchange. The daemon reads that status, concludes the handshake completed successfully, and carries on with its day. The connection is now treated as authenticated even though the client never demonstrated knowledge of any credential, and because the SRP exchange never actually ran to completion, the session that follows is not encrypted either. An authentication bypass and a confidentiality failure for the price of one.

From that point it stops being an authentication problem and becomes a filesystem problem. The attacker inherits access to the privileged helper processes that Screen Sharing uses to move files around, namely SSFileCopySender and SSFileCopyReceiver. Those helpers carry Apple signed entitlements, which means they sail straight past Transparency, Consent, and Control, the framework that normally stops a process from wandering into your Documents folder or your Photos library without a permission prompt. Arbitrary file read and write, running as root, with TCC entirely out of the picture, is a full compromise wearing a very thin disguise.

Turning that into code execution is not a research project. Analysts at Huntress documented the obvious routes, and none of them are exotic. Write a LaunchDaemon property list and a reverse shell fires on the next reboot. Append a few lines to a user's .zshenv and the payload runs the next time that person opens a terminal. On machines where System Integrity Protection has been switched off, and there are far more of those in the wild than anyone in IT wants to admit, cron opens up as a persistence mechanism too.

It is worth separating this from its sibling. CVE-2026-43760 also lives in Screen Sharing and was also patched, but that one is a local privilege escalation that requires an attacker to already hold valid credentials via the legacy VNC authentication path. It matters, and you should patch it, but it belongs to a different weight class. CVE-2026-65400 requires nothing at all. That distinction is precisely why one of them ended up in the KEV catalog with a federal deadline attached and the other did not.

What exploitation looks like in the wild

The Dutch National Cyber Security Centre raised the alarm on August 12, reporting active exploitation against Macs with port 5900 exposed to the internet. In every single incident reported to NCSC-NL, the outcome was identical. The attackers obtained root, and then they installed a Monero cryptocurrency miner.

Cryptomining is the least imaginative thing you can do with root on somebody else's Mac, which is exactly why it should worry you rather than reassure you. Nobody burns a pre authentication remote root bug on Monero because mining is the goal. They do it because mining is the fastest way to monetize a wide, indiscriminate internet scan while the window is still open. Whoever is running these campaigns is spraying the address space looking for exposed port 5900 and cashing in with the laziest payload available. The capability they are holding is root level arbitrary file write on macOS. Today it funds a mining pool. That same access, sold to somebody with a ransomware affiliate program and more ambition, looks very different next month.

The genuinely uncomfortable detail for anyone hoping to configure their way out of this is that configuration does not save you. Disabling local user accounts does not help. Turning off VNC authentication does not help. Setting a forty character password does not help, because the flaw sidesteps the credential check entirely rather than guessing its way through it. There is no clever plist tweak that closes this one. You either install the patch or you remove the network path, and those are the only two options on the table.

Internet exposure defines the highest risk group, not the only one. A Mac sitting on a flat internal VLAN with Screen Sharing enabled is one compromised laptop away from the same outcome, and Screen Sharing is exactly the kind of service that gets switched on for a legitimate reason in 2019 and then never switched off again. Design studios, video production teams, university labs, and developer fleets are all classic offenders. So is any environment where somebody enabled Remote Management for a support session years ago and nobody ever revisited the decision.

What to do about it

Patch, and patch this week. macOS Sonoma is vulnerable before 14.8.9, macOS Sequoia is vulnerable before 15.7.9, and macOS Tahoe is vulnerable before 26.6.1. All three fixes shipped on August 6 and are available through the normal Software Update channel under System Settings and then General. Federal civilian agencies were given until August 21 under BOD 26-04 to remediate this one, which for the rest of us serves as a useful gut check on how seriously the government is treating it.

If you cannot patch a machine immediately, kill the network path instead. Screen Sharing and Remote Management both live under System Settings and then General and then Sharing, and both should be off unless somebody can articulate why they are on. Then go audit your perimeter for port 5900 rather than assuming you already know the answer, because the exposed Mac is almost never the one you expected. A quick external scan of your public ranges takes minutes and tends to produce at least one surprise per client.

For detection, guidance from Huntress points at Screen Sharing attach events showing an authentication type of SRP, and at sessions running with a session username of root. Either one on a machine where nobody was legitimately screen sharing is worth a phone call. Beyond that, look for recently created LaunchDaemon property lists, unexpected modifications to shell startup files like .zshenv, sustained CPU consumption on machines that should be sitting idle, and outbound connections to known mining pool infrastructure. The Monero payload is noisy by nature, which is the one piece of good news in this entire story. A compromised Mac running a miner is far easier to spot than a compromised Mac running a patient, quiet backdoor, and you should assume both are possible from the same initial access.

One more thing worth saying out loud, because it keeps coming up in post incident conversations. The persistent belief that Macs sit somewhere outside the threat model is doing real damage to real networks. This is a pre authentication remote root vulnerability in a default macOS service, exploited in the wild within days of the patch, sitting in the KEV catalog at 9.8. If your endpoint detection coverage, your patch compliance reporting, and your vulnerability scanning all quietly stop at the edge of the Windows fleet, you have a blind spot that somebody else found before you did.

The MSP angle

This is a clean, non hypothetical reason to open the macOS coverage conversation with every client who has ever waved off Mac management as unnecessary. A short exposure report showing which of their Macs are unpatched and whether port 5900 is reachable from outside turns an abstract argument into a specific finding with a CVE number and a federal deadline attached, and that tends to close considerably faster than a generic security assessment pitch.

Package it as recurring revenue rather than a one time project. Mac patch management, external attack surface monitoring for exposed remote access ports, and endpoint detection coverage that genuinely extends to macOS are three separate line items that this single vulnerability justifies, and the KEV listing gives you the third party validation to point at when procurement asks whether any of it is really necessary.