Zerodayhub

TL;DR — The macOS Screen Sharing vulnerability tracked as CVE-2026-65400 lets an attacker authenticate to a Mac’s remote desktop service without a password and act as root. Apple shipped an emergency fix on 6 August; Dutch authorities then found it being used to install cryptocurrency miners on internet-exposed Macs. If Screen Sharing is off, you are not exploitable — but patch anyway.

What Is the macOS Screen Sharing Vulnerability?

Screen Sharing is macOS’s built-in remote desktop service. It speaks VNC, listens on TCP port 5900, and is handled by a daemon called screensharingd. Turn it on in System Settings and another Mac can view and control the machine.

The macOS Screen Sharing vulnerability is a pre-authentication flaw in that daemon. An attacker who can reach port 5900 authenticates without valid credentials and then, in Apple’s own framing, reads and writes files as root — which is full remote code execution in everything but name.

Apple patched it in an emergency out-of-band update on 6 August 2026: macOS Tahoe 26.6.1, Sequoia 15.7.9 and Sonoma 14.8.9. Apple describes the fix as improved state management, and credits researcher Alfredo Pesoli of Bynario.

The scoping detail matters and is genuinely good news: if Screen Sharing is disabled, this vector is not exploitable even on an unpatched Mac. The vulnerable code remains present until you update, but nothing is listening. That makes “is Screen Sharing on, and is 5900 reachable?” the first question to answer, not the version number.

How the macOS Screen Sharing Vulnerability Works

Apple’s advisory language — an authentication issue addressed with improved state management — is terse, but researchers have described the shape of it, and it is a nice illustration of how authentication logic fails.

During the authentication exchange, a length check rejects an oversized frame and bails out early. The problem is what it returns: a value that happens to match the success code from the read operation immediately before it. The caller cannot tell the difference. It interprets that return as “this authentication step passed” and advances the state machine.

This is CWE-287, improper authentication. The single precondition is that the attacker must name a valid account on the target, which is a mild constraint — usernames are not secrets, and common ones are guessable. No password is required at any point.

There is a detail worth getting right, because reporting has conflated two bugs. A separate pre-authentication flaw in the same source file was fixed in macOS 26.6, and was publicised by a different researcher. That earlier one is a stale return value; this one is a state machine desync. Same file, different bugs, different patches. If you have seen both described interchangeably, they are not the same issue.

Reading the CVSS Score

The scoring history here is unusual and worth explaining, because you will find both figures in circulation.

The CVE was originally scored 7.1. On 14 August, following reports of active exploitation, CISA rescored it to 9.8 and assessed it as automatable. That is a substantial revision, and it reflects reality catching up with the paperwork: an initial assessment that treated the flaw as constrained met evidence of attackers using it to take root on internet-facing machines.

The 9.8 vector is the familiar maximal one — network reachable, low complexity, no privileges, no interaction, all three impacts High. If your vulnerability management tooling cached the 7.1 before 14 August, this flaw is sitting in your backlog with the wrong priority. That is worth checking today, and it generalises: scores are revised, and a stale severity is a silent risk.

Active Exploitation of the macOS Screen Sharing Vulnerability

The exploitation reporting comes from NCSC-NL, the Dutch national cyber security centre, which updated its advisory to say it had received reports of active abuse across multiple systems with port 5900 reachable from the internet.

What the attackers did with root access is almost mundane, and instructive for that reason: they installed Monero cryptocurrency miners. No espionage, no ransomware, no data theft — just opportunistic monetisation of machines that were easy to reach. That pattern usually signals broad, indiscriminate scanning rather than targeted operations, and it means the selection criterion was simply “port 5900 answered.”

It also means a compromised Mac may look unremarkable in security tooling while behaving oddly to its user. What to hunt for:

• Sustained high CPU usage with no user-facing cause — the loudest symptom of a miner, and often the first thing a user reports
• Connections to known mining pool addresses, or persistent outbound traffic from a Mac to destinations nothing on it should be calling
• Screen Sharing sessions in the logs that no administrator or user initiated
• Unexpected launch daemons or launch agents, and new root-owned files outside normal locations
• Any Mac answering on TCP 5900 from outside your network — that is the exposure, and finding it is the highest-value scan you can run today

Remediation & Mitigation: Patching macOS

Update to macOS Tahoe 26.6.1, Sequoia 15.7.9 or Sonoma 14.8.9 or later. These have been available since 6 August.

Unusually, there is also a complete mitigation that does not require the update: turning Screen Sharing off closes the vector entirely.

# Is Screen Sharing running on this Mac?
sudo launchctl list | grep -i screensharing
# Is anything listening on 5900?
sudo lsof -iTCP:5900 -sTCP:LISTEN
# Disable Screen Sharing (interim mitigation where it is not needed)
sudo launchctl disable system/com.apple.screensharing

• Patch every Mac, including the ones outside MDM. Personal machines used for work are the usual blind spot, and this was exploited against internet-exposed hosts.
• Disable Screen Sharing where it is not needed. Complete mitigation, immediately available, and worth keeping off permanently on machines that never use it.
• Find anything answering on 5900 from the internet. A remote desktop service should not be publicly reachable under any circumstances; put it behind a VPN.
• Recheck your severity data. If your tooling ingested the original 7.1, requeue this at 9.8 — the rescore was on 14 August.
• Hunt on exposed machines before you close the ticket. Root access was achieved; patching does not remove a launch daemon someone left behind.

Two broader points. The first is about remote desktop generally: VNC, RDP, Screen Sharing and their cousins are among the most consistently attacked services on the internet, because they hand over an interactive session rather than a foothold. None of them belongs on a public interface, regardless of how current the patch level is.

The second is about Macs in the security programme. Fleet-wide patching, exposure scanning and endpoint monitoring are frequently Windows-shaped, with macOS covered more loosely on the assumption that it is a smaller target. This CVE is a reminder that attackers scan by port, not by operating system.

Related ZeroDayHub Coverage

Authentication logic keeps failing in instructive ways: the SharePoint JWT authentication bypass, where a validator trusted what the token claimed, and the N-able N-central authentication bypass.

Sources & Further Reading

• CISA Known Exploited Vulnerabilities Catalog
• NVD — CVE-2026-65400
• Apple — Security advisory and affected versions
• The Hacker News — NCSC-NL exploitation reports and Monero miners
• Tanium — Rescoring timeline and exposure guidance
• runZero — Finding affected and exposed assets
• The Hacker News — The 18 August KEV additions in context