I still remember the first time I heard about a Mac getting quietly turned into a mining rig. It felt almost unreal. Apple machines have long carried this reputation for being harder to compromise than the average Windows box. Yet here we are again, watching a critical flaw in Screen Sharing get used in the wild to grab root access and start pulling Monero. The latest reports make one thing clear: the attackers did not need sophisticated zero-days or social engineering tricks. They simply found machines sitting on the open internet with port 5900 exposed and walked right in.
What Actually Happened With This macOS Screen Sharing Flaw
In early August, Apple released security updates for macOS Tahoe, Sequoia, and Sonoma that closed a serious authentication weakness. The bug, tracked as CVE-2026-65400, allowed an attacker on the same network to convince the Screen Sharing service that an unauthenticated connection was already legitimate. Once that happened, the attacker could obtain privileged access without ever supplying valid credentials.
Security researchers later confirmed that the issue lived inside the Secure Remote Password authentication process. By manipulating the state of the connection at the right moment, an outsider could force the service into treating them as an authorized user. That is the kind of flaw that keeps system administrators awake at night, especially when the machines in question are rented bare-metal Macs sitting in data centers with Screen Sharing left enabled by default.
The Netherlands National Cyber Security Centre updated its advisory after confirming active exploitation. In every case they examined, the attackers went straight for root access and then installed Monero mining software. No reports of wallet theft or data exfiltration appeared in the initial disclosures. This was pure cryptojacking, using the Mac’s CPU cycles to generate privacy-focused coins for someone else’s profit.
Why Changing Passwords Was Never Enough
One of the more frustrating details for IT teams is that traditional hardening steps offered little protection. Changing the Screen Sharing password, turning off legacy VNC authentication, or removing authorized user accounts did nothing to stop the exploit. The attack happened before normal authentication checks could even run. That reality forced many administrators to confront an uncomfortable truth: the only reliable fix was either installing Apple’s August 6 updates or completely disabling Screen Sharing until the machines could be patched.
I’ve seen similar situations before where people assume a strong password will save them. In this case it simply did not matter. The authentication logic itself was broken. Once an attacker reached the vulnerable service, the door was already open.
How Widespread Was the Exposure
Researchers scanning the public internet found tens of thousands of potentially vulnerable hosts. That number does not equal confirmed compromises, of course. Many of those machines may never have been reached by the attackers. Still, the sheer volume of exposed systems is hard to ignore. Hosted Mac minis and other bare-metal Apple hardware proved especially attractive targets. Some cloud providers spin up new machines with Screen Sharing enabled by default, creating a brief but dangerous window before the latest patches land.
The risk profile changes dramatically when a Mac sits behind a carefully locked-down network versus when it faces the open internet on port 5900. The latter group faced the clearest danger, and the Dutch reports focused exclusively on those internet-facing systems.
The Severity Score Jumped Dramatically
Originally the vulnerability received a lower severity rating. After further analysis, the score climbed to 9.8 critical under the current assessment. No privileges required. No user interaction needed. An attacker only had to reach the service over the network. That combination explains why the issue moved so quickly from theoretical risk to confirmed exploitation.
When a flaw scores that high, organizations cannot treat the update as optional. Yet many Macs, especially those used for continuous integration, media rendering, or remote development workloads, sit in environments where updates sometimes lag. The gap between patch release and actual deployment often becomes the window attackers exploit.
Monero as the Preferred Mining Target
Why Monero again? The coin has appeared in cryptojacking campaigns for years because it remains mineable on ordinary CPUs without specialized hardware. Attackers who seize control of a Mac do not need to install complex GPU drivers or risk drawing attention with unusual power draw patterns associated with high-end graphics cards. They simply run a miner and let the system do the work.
In this campaign the attackers appeared focused solely on generating coins rather than stealing existing crypto holdings or installing more persistent backdoors. That does not make the intrusion harmless. Root access means they could have done far worse. The fact that they chose mining suggests either a financially motivated group looking for steady returns or a test run for larger operations.
Monero’s privacy features also make it harder to track the proceeds once the coins leave the mining pool. That anonymity layer continues to attract both legitimate privacy advocates and less legitimate operators.
What Administrators Should Do Right Now
The practical steps remain straightforward even if the situation feels urgent.
- Install the latest security updates for macOS Tahoe 26.6.1, Sequoia 15.7.9, or Sonoma 14.8.9 without delay.
- If immediate patching is not possible, disable Screen Sharing entirely until the update can be applied.
- Audit any internet-facing Macs for open port 5900 and restrict access behind a VPN or firewall where possible.
- Review recently provisioned bare-metal Macs in hosting environments for unexpected mining processes or elevated CPU usage.
- Check system logs for unusual authentication attempts around the period before the August 6 patches.
Even machines that administrators believe have Screen Sharing turned off should receive the update. Configuration drift happens more often than people like to admit, and a single overlooked setting can leave a system exposed.
The Broader Pattern of Crypto-Related Mac Attacks
This incident fits into a longer pattern. Apple devices have faced multiple campaigns aimed at crypto users and infrastructure in recent years. Some involved malware delivered through fake meeting invitations or malicious software updates. Others targeted developers working on blockchain projects. The common thread is that attackers increasingly treat Macs as valuable computing resources rather than just personal devices.
When a Mac sits in a data center running continuous workloads, its steady power supply and relatively strong single-thread performance make it an attractive mining target. The same qualities that make it useful for legitimate rendering or compilation work also make it useful for generating Monero.
I’ve noticed that many teams still treat Mac security as a secondary concern compared with Windows or Linux servers. That attitude is becoming harder to justify. As more organizations rely on Mac hardware for specialized tasks, the attack surface expands accordingly.
How Cryptojacking Differs From Other Crypto Threats
Cryptojacking sits in a different category from ransomware or direct wallet theft. The attacker does not necessarily encrypt files or demand payment. Instead they quietly consume resources over weeks or months. Victims often notice the problem only when electricity bills rise, fans run constantly, or system performance drops during normal work.
In some ways that subtlety makes cryptojacking more dangerous for organizations that lack strong monitoring. A ransomware attack announces itself. A mining process can hide inside legitimate-looking processes for a long time, especially on machines that already run heavy computational loads.
The Dutch cases showed root-level access, which means the miners could have installed additional tools if they chose. The decision to stick with mining may reflect a preference for low-profile income rather than high-risk data theft. Still, any organization that discovers unauthorized mining should assume the machine is fully compromised and respond accordingly.
Lessons From the Exposure Numbers
Tens of thousands of potentially vulnerable hosts is a large number, yet it represents only the systems that appeared reachable from the public internet at the time of the scan. Private networks, machines behind corporate firewalls, and systems that never enabled Screen Sharing fall outside that count. The real lesson is that any service left exposed to the internet becomes a potential entry point the moment a flaw appears.
Bare-metal Mac hosting environments face particular pressure. Customers often request remote desktop access for convenience. Providers sometimes enable Screen Sharing by default to reduce support tickets. That convenience creates risk when a vulnerability surfaces. Better defaults, automatic patching, and forced VPN access would reduce the attack surface significantly.
Perhaps the most interesting aspect is how quickly the severity assessment rose after initial analysis. Early scores sometimes understate the real-world impact until researchers demonstrate practical exploitation paths. Once those paths become clear, the score jumps and the urgency follows.
What We Still Do Not Know
Several important details remain missing. The number of confirmed compromised machines has not been disclosed. The specific mining software, pool addresses, and attacker wallets stay private for now. Attribution remains absent as well. Without those pieces it is difficult to judge whether this was a small opportunistic campaign or something larger that simply preferred Monero mining as its payload.
Further disclosures from incident response teams could still expand the picture. Indicators of compromise, if released, would help organizations search their own logs more effectively. Until then, the safest assumption is that any internet-facing Mac running an unpatched version of the affected operating systems should be treated as potentially compromised.
Practical Monitoring Tips Going Forward
Even after patching, a few ongoing practices help reduce future risk.
- Monitor CPU usage baselines and alert on sustained high utilization outside normal work hours.
- Restrict Screen Sharing and other remote management tools to VPN-only access whenever possible.
- Keep an inventory of all Macs that have remote access services enabled and review that list regularly.
- Apply security updates on a predictable schedule rather than waiting for a crisis.
- Consider endpoint detection tools capable of spotting unusual process trees or network connections to known mining pools.
None of these steps are revolutionary. They simply represent basic hygiene that becomes more important as Macs move from personal devices into infrastructure roles.
The Human Factor Behind Delayed Patching
Why do machines remain unpatched even after a critical update drops? Sometimes the answer is pure operational friction. A Mac used for continuous integration may require careful testing before the update is allowed into production. Other times the machine sits in a remote location with limited remote management. In still other cases, the person responsible simply did not see the advisory.
I’ve found that the organizations that handle these situations best treat security updates as part of normal change management rather than emergency fire drills. They already have processes for testing and rolling out patches. When a high-severity issue appears, those processes accelerate instead of starting from zero.
For smaller teams without formal change management, the practical advice is simpler: enable automatic updates where possible, and treat any remote management service as high risk until proven otherwise.
Looking Ahead at Mac Security Trends
Apple continues to harden its platforms with each major release, yet remote access features will always carry residual risk. Screen Sharing exists for legitimate reasons. Developers, designers, and support teams rely on it daily. Completely removing the feature is not realistic for many workflows. The challenge becomes ensuring that authentication logic remains airtight and that exposure to the public internet stays tightly controlled.
Cryptojacking will likely remain attractive as long as Monero and similar coins can be mined profitably on general-purpose hardware. Attackers will keep looking for any unattended computing resources they can seize. Macs that sit online with weak remote access controls will continue to appear on their target lists.
The current incident serves as a useful reminder rather than an isolated surprise. The combination of an authentication bypass, internet-facing services, and a profitable mining payload created the conditions for real-world exploitation. Apple closed the technical hole. The remaining work belongs to everyone who runs Macs in networked environments.
Final Thoughts on Response Priority
If you manage any Macs that have ever had Screen Sharing enabled, the priority is clear. Install the relevant security updates. Confirm that remote access is no longer reachable from the open internet. Watch for unusual CPU behavior in the days that follow. Those three steps close the known risk from this particular flaw.
Beyond that, the episode reinforces a broader principle. Any service that accepts network connections can become an entry point when its authentication logic fails. Reducing the number of services exposed to the internet remains one of the highest-leverage defensive moves available. Convenience often argues for leaving ports open. Security argues for the opposite.
In my experience the teams that sleep best are the ones that treat remote management as a privilege rather than a default. They require deliberate decisions to enable it, they restrict it behind stronger controls, and they keep the systems that use it fully patched. That approach would have limited the impact of this particular Screen Sharing weakness considerably.
The Monero miners have already moved on to the next opportunity. The question for the rest of us is whether the next vulnerability finds our systems still exposed or already locked down. The choice, as usual, sits with the people who manage the machines.
