A Mac with Screen Sharing on the internet is now a mining rig
CVE-2026-65400 lets an attacker authenticate to macOS Screen Sharing with no credentials. Exposed Macs are being rooted and turned into Monero miners.
Researched and drafted with AI assistance, then reviewed and edited by Shreyas Lipare before publication. Every source below was checked against the original.
Apple shipped an emergency update on August 6, 2026. Within a week the flaw it fixed was being used against Macs that never got it, and ten days on they are still being found.
The pattern is the one this blog covered on August 15, in a completely different setting. A service that was never meant to face the internet is facing the internet, something reaches it, and the fix is the same in both cases: stop answering strangers.
Last time it was water utility controllers. This time it is somebody’s Mac.
What happened
CVE-2026-65400 is an authentication flaw in macOS Screen Sharing. Apple gives it two lines. The impact: an attacker on the network may be able to authenticate to Screen Sharing without valid credentials. The description: an authentication issue was addressed with improved state management [1].
NVD scores it 9.8, network reachable, low complexity, no privileges required, no user interaction, with full impact on confidentiality, integrity and availability. The weakness class is CWE-287, improper authentication [2].
Apple fixed it in macOS Tahoe 26.6.1, macOS Sequoia 15.7.9 and macOS Sonoma 14.8.9, all released August 6, 2026, and credits the finding to Alfredo Pesoli via Bynario Atlas [1].
Then it started being used. The Netherlands National Cyber Security Centre updated its advisory to report active abuse across multiple systems where port 5900 was reachable from the internet, and stated that in all of those cases root had gained access to the machine and a Monero cryptocurrency miner was placed [3].
One caveat on that last paragraph. I could not open the NCSC advisory itself: the page loads as an empty JavaScript shell. The wording above comes from reporting that quotes it directly, which is a weaker link in the chain than I would like, and worth knowing when you weigh the claim.
Why this matters
The payload is the least interesting part. A miner is what the access was spent on, not what it was capable of. Root on a Mac means files, keychains, browser sessions, SSH keys, and whatever else that machine can reach on the network it sits on. Mining is simply the option that converts access into money without needing a human to do anything clever.
So the correct reading of “we found a miner” is not “we got off lightly.” It is “somebody reached this machine without credentials and ended up with root, and here is the one thing we can see they did with it.”
The targeting is nobody’s targeting. Cryptomining at this scale is opportunistic and automated. Nobody chose these Macs. Something scanned for a port answering on 5900 and took what answered. That is a different threat model from the one most people carry around: there is no reason you would be interesting, and it does not matter.
Exposed services are not a Windows problem. The instinct in a lot of security programmes is to inventory servers and Windows estates and treat macOS as an endpoint that lives behind something. A Mac with Screen Sharing enabled and a port forward in front of it is a remote access service on the public internet, and it should be inventoried like one.
Technical breakdown
The flaw sits in how the Screen Sharing service handles authentication state. Apple’s own phrasing, “improved state management”, points at the shape of it: the service could end up treating a connection as authenticated when the authentication had not actually completed [1]. The route is described here so you can recognise and interrupt it; no request or exploit detail is reproduced.
- ReconnaissanceScans the public internet for hosts answering on port 5900, the Screen Sharing service
BREAK THE CHAIN HERE
Do not expose 5900 to the internet. Remote access to a Mac belongs behind a VPN or a broker, not on a port forward. Detection: scan your own public ranges for 5900 answering, and treat any hit as an inventory finding to close today. - Initial accessReaches the service and is treated as authenticated without ever presenting valid credentials
BREAK THE CHAIN HERE
Update to macOS Tahoe 26.6.1, Sequoia 15.7.9 or Sonoma 14.8.9. If you cannot patch now, turn Screen Sharing off in System Settings, which removes the listener entirely. Detection: review Screen Sharing connection logs for sessions from addresses outside your own ranges. - PrivilegeRoot access on the machine follows. The reporting states root was obtained but not whether this flaw grants it directly or a further step is involved
- ExecutionA Monero mining binary is placed and started
- ImpactThe machine spends its CPU on somebody else's mining, which is the visible symptom and the reason anyone noticed
- ResidualRoot access means the miner was a choice rather than a limit, and everything else on the machine was reachable
BREAK THE CHAIN HERE
Treat a mined machine as fully compromised: rotate credentials stored on it, revoke its sessions and tokens, and rebuild rather than clean. Detection: hunt for root-owned launch items and processes you did not create, and outbound connections to mining pools.
Three of those carry a break, and the ordering matters. Patching fixes this flaw. Not exposing the service fixes this flaw and the next one, which is why it is listed first even though it is the harder ask.
The last break is the one people skip. Removing a miner feels like remediation because the CPU graph goes flat, and it is not. The miner is evidence of access, and the access is the incident.
What defenders should do Monday morning
Immediate, today. Find out whether any Mac you are responsible for has Screen Sharing enabled, and whether anything reaches it from outside. Do not answer from the asset register; scan your own public addresses for 5900. Patch every Mac to macOS Tahoe 26.6.1, Sequoia 15.7.9 or Sonoma 14.8.9 [1]. Where you cannot patch immediately, disable Screen Sharing, which removes the listening service rather than merely protecting it.
Near term, this week. For any Mac that was exposed and unpatched between August 6 and now, assume access happened rather than waiting for proof. Rotate credentials that lived on it, revoke sessions and tokens, and check for root processes and launch items nobody created. Put remote access behind a VPN or a brokered gateway so port 5900 is never reachable from the internet again.
Structural, this quarter. Add macOS to whatever inventory drives patching and exposure review, with the same seriousness as servers. Establish who is allowed to enable remote access on a company machine and how that gets recorded, because these services are almost always switched on by someone solving a real problem in a hurry.
Checklist
- Scan your own public IP ranges for port 5900 answering.
- Patch to macOS Tahoe 26.6.1, Sequoia 15.7.9 or Sonoma 14.8.9.
- Disable Screen Sharing anywhere it is not genuinely needed.
- Move any legitimate remote access behind a VPN or gateway.
- For exposed and unpatched Macs, assume compromise rather than awaiting proof.
- Rotate credentials, tokens and keys that lived on those machines.
- Hunt for root-owned launch items and processes nobody created.
- Add macOS to the inventory that drives patching and exposure review.
The part that generalises
Two posts in two days, one about industrial controllers running a water system and one about a laptop on somebody’s desk. Nothing links them technically. The route in was identical: a service was reachable that should not have been, and something automated found it.
The controllers had no exploit at all, just default credentials. This one had a 9.8 authentication bypass. From the attacker’s side that difference barely mattered, because both were found the same way, by scanning for a port that answered.
Patch this one quickly. Then go and find out what else of yours is answering.
FREQUENTLY ASKED
- I have Screen Sharing off. Am I affected?
- Then the service is not listening and this specific flaw has nothing to answer on. The population at risk is Macs with Screen Sharing enabled and reachable from the internet on port 5900. Patch anyway, because the next person to enable it for a legitimate reason should not inherit the bug.
- It is only a cryptominer. How bad is that really?
- The miner is what they chose, not what they were limited to. Access was at root, which means anything on that machine was available: files, keys, browser sessions, anything the Mac could reach on the local network. Treat a mined machine as fully compromised, not as an annoyance that stole some CPU.
- Why would a Mac be on the internet with Screen Sharing open?
- Usually because someone needed remote access and enabled the simplest thing that worked, often on a home network with port forwarding, a small office, or a cloud-hosted Mac used for builds. Very few of those setups were reviewed afterwards. That is the same pattern behind most exposed-service compromise.
- How would I know if it happened to me?
- The obvious signal is sustained high CPU with no explanation, since a miner has to actually mine to be worth anything. Better signals are new root-owned processes or launch items you did not create, and outbound connections to mining pools. Absence of a miner does not prove absence of access.
REFERENCES
BEFORE YOU GO
Was this useful?
Tell me what you'd change, what was unclear, or what you'd want covered next. Replies shape what gets written.
SEND FEEDBACK ↗