A CVSS 9.8 macOS Bug Is Being Used Right Now to Root Internet-Exposed Macs and Mine Monero. Rotating Your VNC Password Does Nothing.
The Dutch national cyber security centre reported on August 12 that attackers are actively exploiting CVE-2026-65400, an authentication bypass in macOS Screen Sharing, against Macs with port 5900 reachable from the internet. In every case reported to the agency, the attacker got root and installed a Monero miner. The flaw carries a CVSS score of 9.8, and Apple shipped an emergency patch on August 6.
The detail that made me write this rather than skip it: the mitigations you would reach for first do not work. Removing approved Screen Sharing users, disabling legacy VNC password access, rotating the VNC password. All of them operate downstream of the authentication path the bug defeats. You can do all three and remain fully exploitable.
Why this one is different from the usual Apple CVE
Most macOS vulnerabilities that get a scary number require something from the victim. Open a file, visit a page, run a binary, already be on the machine. This one requires that your Mac is listening on 5900 and reachable, and that is the whole precondition.
The bug lives in screensharingd, the daemon behind macOS's built-in remote desktop. It is an authentication issue, which is the polite phrasing for "an attacker can authenticate without valid credentials." CISA raised the severity to 9.8 after exploitation reports came in, which is the range reserved for remote, unauthenticated, full-compromise bugs.
Root plus a cryptominer is the low-imagination payload. It is also the one you notice, because your fans spin up. The thing worth sitting with is that anyone who got root on that machine had root on that machine, and mining was a choice. Your SSH keys, your .env files, your unlocked git credentials and your npm token were all equally available.
Who actually has this exposed
Nobody sets out to put a VNC port on the public internet. Here is how solo operators end up there anyway, and I recognise at least two of these from my own history.
You have a Mac mini running builds, CI, or a self-hosted service, and you turned on Screen Sharing so you could fix it without walking over. Then at some point you set up port forwarding on the router so you could reach it from a coffee shop, and never removed the rule.
You have an older iMac or MacBook acting as a home server for backups or media. Screen Sharing went on during setup and stayed on because it is a checkbox in System Settings that nothing ever prompts you to revisit.
You are on a network you do not fully control. A coworking space, a hackerspace, a shared office, a landlord-provided router with UPnP enabled. UPnP is the quiet one here, because an application can open a port outward without you doing anything deliberate.
Or you did it on purpose two years ago behind what you considered adequate protection, which for VNC usually means a password, and that password is now irrelevant.
The check, which takes about ten minutes
No security tooling required.
Start on the machine. Open System Settings, go to General, then Sharing, and look at Screen Sharing. If it is off, this bug cannot reach you and you can stop worrying about this specific issue. If it is on, keep going.
Check your macOS version in System Settings under General, then About. The fixed builds are macOS Tahoe 26.6.1, Sequoia 15.7.9, and Sonoma 14.8.9. If you are on an older build of any of those lines, you are unpatched. If you are on something older than Sonoma, there is no fix for you and Screen Sharing needs to go off.
Then check reachability, which is the part people skip and the part that decides whether this is urgent or theoretical. From a network that is not your own, meaning phone tethering rather than your home wifi, try to reach port 5900 on your public IP. If a connection opens, you are in the exposed group. If it refuses or times out, your router is not forwarding and your exposure is limited to your local network.
While you are in the router, look at the port forwarding table generally, and turn UPnP off unless you know you need it. The reason I suggest this is that the forwarding rule I found on my own router was for a game from 2019 and I had no memory of creating it.
What to actually do, in order
If Screen Sharing is on and you do not use it: turn it off. This is the whole fix and it costs nothing. Most people in this situation are here by accident and turning it off has no downside.
If you use it and the machine is patched: you are fine on this specific bug, but remove the port forward anyway and reach the machine over Tailscale, WireGuard, or your VPN of choice. A VNC port on the public internet is a bad position independent of any single CVE, because the next authentication bug in that daemon will find you the same way.
If you use it and the machine is unpatched: patch now, then do the previous paragraph. Do not patch and consider it handled.
If the machine was exposed and unpatched for any length of time: assume compromise rather than hoping. Rotate anything that machine had access to, which realistically means SSH keys, cloud provider credentials, npm and PyPI tokens, and any long-lived API keys sitting in a .env file. Check for unfamiliar login items and launch daemons. This is tedious and I understand why nobody wants to do it, but "root access in every reported case" is not a sentence you can partially believe.
The honest take
The security advice aimed at indie developers is almost entirely about dependencies now. Audit your npm tree, check your lockfile, watch for postinstall scripts. That advice is correct and I have written some of it.
But the machine sitting under your desk is a much older and much simpler failure. It has a service you turned on, a port your router forwarded, and a version of macOS that updates when you get around to it. There is no dependency graph to reason about. There is a checkbox and a router rule, and both of them are things you did once and stopped thinking about.
Where I could be wrong: I am assuming the ten-minute check is proportionate, and for most readers it will find nothing. If you run every machine behind a properly configured firewall with no inbound forwarding, none of this applies to you and I have cost you ten minutes. I still think the base rate of accidental port exposure among solo operators is high enough to justify that, mostly because of UPnP and old router rules, which are exactly the kind of thing you cannot rule out by remembering carefully. You have to go look.
Author
Lukas
@lukcombinator