SURIQ
A logic bug does not need a genius to weaponize it. That is the real lesson of CVE-2026-65400, an authentication bypass in macOS Screen Sharing that Apple fixed on August 6, 2026. Within about two weeks the Netherlands' national cyber agency was reporting active abuse against Macs with the service exposed to the internet, and a security firm says it rebuilt a working exploit in roughly four hours using an AI coding agent. Patching closes the hole. The gap between the fix and mass opportunistic exploitation is now measured in days, and this bug shows why.
What CVE-2026-65400 actually does
Screen Sharing is Apple's built-in remote-desktop service. It speaks the VNC protocol and listens on TCP port 5900. The flaw is an authentication bypass: according to reporting from Security Affairs, the service mishandles how it tracks login state, so an attacker on the network can finish the handshake and be treated as logged in without ever supplying a valid credential. Security Affairs puts the severity at CVSS 9.8. In every case documented so far the attacker lands with root, the highest level of access on the machine.
There is no memory corruption here, no race condition to win, no exploit primitive to develop. It is a logic error in how the service tracks authentication state. That distinction is not academic. It is the reason this went from patch to in-the-wild abuse so fast.
Why it was weaponized in an afternoon
The security firm Calif reported building a functional exploit in about four hours with an AI coding agent. That number is believable precisely because of the bug class. Memory-corruption exploits take skill and time: you fight address randomization, you win a race, you build a chain. A state-management auth bypass just needs someone to replay the handshake in the right order, which is exactly the kind of well-specified, mechanical task an AI agent handles well. We have watched exploits land within hours of a public writeup already this year, and AI tooling keeps compressing the window between a patch and a working attack. Here the bug class removed the last bit of friction.
The exposure most teams are not scanning for
Researcher @osxreverser counted roughly 40,000 Macs with Screen Sharing reachable from the internet, nearly half of them in the United States, spread across home connections, universities, and corporate servers. The NCSC said abuse was observed on multiple systems where port 5900 was reachable from the internet. Macs are a blind spot in a lot of vulnerability-management programs. Teams scan for exposed SSH and RDP by reflex; a Mac quietly advertising VNC on 5900 often is not in scope at all, and that is the gap attackers are scanning for right now. It is the same lesson as the tens of thousands of management interfaces sitting open on the internet: the thing you never meant to expose is the thing that gets hit.
The Monero miner is the floor, not the ceiling
Every reported case ended with the attacker installing a miner for the Monero cryptocurrency, and the pattern looks opportunistic rather than targeted: scan the internet, hit whatever answers on 5900, drop the payload. It is tempting to file that under nuisance. Do not. A miner is the least imaginative thing an attacker does with root. The same unauthenticated root access supports credential theft, persistence, and pivoting into whatever the Mac can reach. macOS is squarely in attackers' sights now, from live browser-session theft to signed-but-malicious tooling. If you find the miner, assume the box was fully owned and open an incident, not a cleanup.
What to do now
-
Patch. Apple shipped the fix on August 6. On macOS Sonoma, update to
14.8.9; on Sequoia, to15.7.9; on Tahoe, to26.6.1. Anything below those builds is exposed. -
Turn Screen Sharing off if you do not use it. In System Settings, under General then Sharing, disable Screen Sharing. If you cannot patch right away, this closes the exposure.
-
Get port
5900off the internet. Remote desktop belongs behind a VPN or an IP allowlist, never open to the world, patched or not.
How would you know you were hit?
Look for inbound connections to 5900 from addresses you do not recognize, sustained high CPU or fan activity from an unfamiliar process, and any new process running as root that you did not install. On a shared or corporate fleet, an unexpected VNC session is the signal to pull the machine and investigate, not to kill the process and move on.
Expect more of this shape: a clean logic bug, a public fix that doubles as a blueprint, and an AI agent that turns the blueprint into an exploit before most teams finish their change window. The durable defense is not faster patching. It is not putting a management interface on the internet in the first place.