You’ve probably heard the advice before: “Don’t click suspicious links,” “Don’t enter your password on sketchy websites,” “Be careful what you download.” But what if none of that matters? What if an attacker could compromise your Mac without you clicking a single thing, without entering a password, without any interaction from you at all?
That’s the reality of CVE-2026-65400, a critical authentication bypass vulnerability in macOS Screen Sharing that is now being actively exploited in the wild .
What Makes This Vulnerability Different
CVE-2026-65400 affects screensharingd, the daemon that powers macOS’s built-in Screen Sharing and Apple Remote Management features . The vulnerability allows an attacker on the network to authenticate to Screen Sharing without valid credentials .
Here’s what that means in plain English:
No phishing required. The attacker doesn’t need to trick you into clicking anything or revealing a password.
No valid account needed. The attacker doesn’t need a macOS username or password.
No user interaction. You don’t need to be at your computer or approve anything.
The flaw sits in the authentication state machine. During the SRP (Secure Remote Password) handshake, screensharingd’s frame-length validator can return a stale “success” status, marking a connection as authenticated before any credential has actually been proven . Once past that gate, the session continues in cleartext, and the privileged file-copy helpers hold Full Disk Access, yielding pre-authentication arbitrary file read and write as root .
The Attack in Action: What Happens When a Mac Is Compromised
The Netherlands’ National Cyber Security Centre (NCSC-NL) first flagged the vulnerability on August 7, 2026, a day after Apple’s patch. By August 12, the agency updated its advisory: active exploitation had been observed .
The attacks target Macs with TCP port 5900 (the Screen Sharing port) exposed directly to the internet . In every case documented by NCSC-NL, attackers achieved root access and installed a Monero cryptocurrency miner .
Attackers have been observed:
Adding SSH public keys for persistent remote access
Clearing logs and shell history to cover their tracks
Modifying packet filter rules (/etc/pf.conf)
Deploying XMRig 6.26.0, a Monero miner, as a hidden .config/sysmond binary masquerading as com.apple.airportd via a KeepAlive LaunchDaemon
Researchers scanning for exposed hosts found roughly 40,000 Macs with Screen Sharing reachable from the internet - nearly half of them in the United States, spanning residential connections, university networks, and corporate servers .
“Improved State Management” - Apple’s Fix
Apple patched CVE-2026-65400 on August 6, 2026 in an out-of-band update :
Apple’s advisory describes the fix as “improved state management” during authentication . The patch shipped outside Apple’s normal release cycle - a strong signal that the company considered this critical .
A separate but related issue, CVE-2026-43760, was also patched in the same update cycle. Unlike CVE-2026-65400, it required an attacker to already hold valid legacy VNC credentials . Organizations patching one should patch both, since a single update train addresses them together .
A Patch Race We’re Losing
A week after Apple shipped the fix, attackers were already exploiting it. Here’s the timeline:
July 29, 2026: Researcher Alfredo Pesoli (Bynario Atlas) discloses the pre-authentication bug
August 6, 2026: Apple patches CVE-2026-65400
August 12, 2026: NCSC-NL reports active exploitation in the wild
August 14, 2026: CISA rescored the vulnerability from 7.1 to 9.8 (Critical)
August 18, 2026: CISA adds CVE-2026-65400 to the Known Exploited Vulnerabilities (KEV) catalog
The Four-Hour Exploit
Security firm Calif reverse-engineered Apple’s out-of-band update and used an AI agent to produce a working exploit. It took four hours . The researchers described the underlying bugs as “simple logic errors - no memory corruption, no exploitation trickery, no race condition to win” .
The takeaway: the gap between a patch being released and a working exploit being available is shrinking rapidly. And when AI can build the exploit in an afternoon, the window for patching effectively disappears .
What You Need to Do Now
1. Update Your Mac Immediately
Check your macOS version:
Apple menu → About This Mac
You’re protected if you’re running:
macOS Tahoe 26.6.1 or later
macOS Sequoia 15.7.9 or later
macOS Sonoma 14.8.9 or later
If you’re on an earlier version, update now.
2. Turn Off Screen Sharing Unless You Actually Need It
Screen Sharing is not enabled by default, but it may be activated on remotely managed workstations, development systems, or Macs used as servers .
To disable Screen Sharing:
System Settings → General → Sharing → Uncheck “Screen Sharing”
3. Don’t Expose Port 5900 to the Internet
Having Screen Sharing enabled does not automatically expose your Mac to the internet. Your router’s firewall normally blocks unsolicited inbound connections. However, if you’ve set up port forwarding or other firewall rules that expose TCP 5900, close that port immediately .
4. Look for Signs of Compromise
If your Mac may have been exposed, check for these indicators :
Sustained or unexplained high CPU usage
Unknown processes or startup items
Connections to cryptocurrency-mining pools (e.g., auto.c3pool.org:443)
Unexpected Screen Sharing sessions associated with root
Newly created LaunchDaemons or modified shell startup files
Unexplained changes to firewall or remote-access settings
Specific IOCs identified by Microsoft Threat Intelligence :
/private/var/root/.config/sysmond (hidden path used for the customized miner)
/Library/LaunchDaemons/com.xmr.miner.plist (malicious persistence)
exec -a com.apple.airportd (command-line masquerading)
Unauthorized SSH keys in /root/.ssh/
5. If Your Mac Was Exposed, Assume Compromise
If you had Screen Sharing enabled and port 5900 exposed to the internet, the fact that you haven’t seen a Monero miner doesn’t mean you’re safe. Root access gives an attacker full control - they could have installed backdoors, stolen credentials, or established persistence that survives the update .
If you’re in this situation, consider the system fully compromised. Best practices include changing all passwords and keys on the affected system and any other systems where the same credentials were used .
Why This Matters Beyond Cryptomining
Monero miners are the visible payload, but they’re the least of the problem . Cryptojacking quietly consumes CPU power, but root access is fundamentally worse.
With root access, attackers can:
Steal files, credentials, and personal documents
Install additional malware or backdoors
Tamper with security tools
Use the compromised Mac as a foothold to attack other devices on your network
Install ransomware
As one analysis put it: “A Monero miner is the visible damage. It is also the least of it. Nothing stops an attacker holding root from installing something that steals credentials instead” .
Sources
Canadian Centre for Cyber Security (2026, August 18). Apple security advisory (AV26-823) - Update 1. www.cyber.gc.ca - Official government confirmation of CISA KEV addition
Tanium (2026, August 19). Critical macOS Screen Sharing Authentication Bypass - Under Active Exploitation (CVE-2026-65400). www.tanium.com - Best summary of IOCs, attack patterns, and CVSS rescoring
The Hacker News (2026, August 14). Apple macOS Screen Sharing Flaw Exploited on Internet-Exposed Macs to Install Monero Miner. thehackernews.com - Confirmed active exploitation and the 40,000 exposed hosts statistic
SK-CERT (2026, August 16). SK-CERT Bezpečnostné varovanie V20260817-02. www.sk-cert.sk - Specific detection recommendations including SSFileCopySender events and root authentication monitoring
The Next Web (2026, August 16). An AI agent built a working exploit for this macOS flaw in four hours. thenextweb.com - Calif’s four-hour AI exploit development story
GitHub - panchocosil/CVE-2026-65400-poc (2026, August 20). Read-only PoC for CVE-2026-65400. github.com - Technical accuracy on the bug mechanism and detailed timeline
This one genuinely stopped me mid-scroll.
The framing of AI agents as non-human identities rather than just features or tools is such a necessary shift and I hadn't thought about it quite this clearly before. The point about eight out of ten agentic threats being identity and authorization failures not hallucination, not model errors, just identity, that reframed the whole conversation for me.
The question "how many agents are actually running, not how many you approved" is the kind of thing that sounds simple until you realise most organisations genuinely cannot answer it. That's not a technical gap. That's a governance gap wearing a technical mask.
Really appreciate how accessible this was Marc, without losing any of the depth. Looking forward to other articles.